[06:34] <lordievader> Good morning
[10:42] <braingain> Hi I'm on 16.04 trying to make use of systemd-run to start one-time jobs
[10:43] <braingain> I get a message that timer and service get created but systemctl tells me there is no .timer or .service-unit
[10:43] <braingain> it works fine in centos and debian
[10:51] <Pugs> one time only ?
[10:52] <tomreyn> braingain: show your logs and unit + timer (use a !pastebin), discuss your ubuntu version. if you cannot share those details, create a simplified example where you can show details, see if this runs properly, if not, show the same for this one.
[10:52] <Pugs> Have you tried Type=oneshot
[10:55] <braingain> hmm after update from 16.04.4 to 16.04.6 now it seems to work. I was puzzled as to why I couldnt await the output with journalctl -f -u
[10:55] <braingain> output just shows with journalctl -u, not -f
[11:00] <tomreyn> point proven: using readily available bug fixes can help!
[11:00] <tomreyn> plus you got free security patches for free, too
[11:01] <braingain> still unsure I should use this atd replacement productively
[11:18] <TJ-> strange issue; on 18.04 trying to figure out when unattended-upgrades last ran but due to the systemd timers/services and so on it's proving difficult. E.g. on the 'problem' system there's no update to /var/log/apt/history.log since July 1st but /etc/apt/apt.conf.d/50unattended-upgrades is correct
[11:19] <tomreyn> do you not have /var/log/unattended-upgrades there?
[11:23] <TJ-> tomreyn: yes, but that is only used by the shutdown service (by default u-a is not configured to log - it does have an option to log to syslog but that's not set by default)
[11:24] <TJ-> the only file there is unattended-upgrades-shutdown.log (0 bytes - because being a server it is never shut down)
[11:24] <TJ-> The systemd timers for apt-daily and apt-daily-upgrade are triggering correctly so trying to figure out why u-a hasn't been applying -security upgrades
[11:24] <tomreyn> hmm weird, i'm on 18.04, too, and have more logs in /var/log/unattended-upgrades
[11:25] <tomreyn> https://paste.ubuntu.com/p/Jm4prKcDRB/
[11:26] <tomreyn>  /etc/apt/apt.conf.d/50unattended-upgrades  https://paste.ubuntu.com/p/4PvRvP7RCT/
[11:28] <tomreyn> but i do indeed have records about unattended-upgrades in /var/log/apt/history.log as well, so this is probably irrelevant and just leading away from your inital question - sorry.
[11:29] <TJ-> ooooo! checking "dpkg -L unattended-upgrades" there's a "/usr/share/unattended-upgrades/20auto-upgrades" but that isn't in /etc/apt/apt.conf.d/
[11:30] <TJ-> hmmmm, this was working until the end of June so did something remove that ?
[11:33] <tomreyn> cat /usr/share/unattended-upgrades/20auto-upgrades; echo ···; cat /etc/apt/apt.conf.d/10periodic | pastebinit     ->   http://paste.ubuntu.com/p/WtCdM9KwyD/
[11:34] <tomreyn> actually this is the output produced by this:   pastebinit < <(cat /usr/share/unattended-upgrades/20auto-upgrades; echo ···; cat /etc/apt/apt.conf.d/10periodic;)
[11:35] <tomreyn> i remember i needed to change *something* about unattended-upgrades to make them work again a while ago, too. sadly forgot all the details.
[11:37] <TJ-> hmmm, after reading the .postinst file I checked debconf and it reports "unattended-upgrades/enable_auto_updates: false"
[11:43] <tomreyn> i just ran this on my 2 18.04 server VMs, which were both installed using the 18.04.2 server live installer, i think: grep -B1 bin/unattended /var/log/apt/history.log | tail -n20
[11:43] <tomreyn> both list multiple runs in july
[11:44] <tomreyn> i don't have those VMs running constantly, though - so these runs may have been a result of booting those VMs on those days.
[11:45] <TJ-> ahh, "dpkg-reconfigure unattended-upgrades"
[11:46] <TJ-> not sure how it got disabled but there was a lot of tweaking going on in June
[11:47] <tomreyn> both VMs return     unattended-upgrades/enable_auto_upgrades: true    when quries using     debconf-show unattended-upgrades    and i did most likely not run dpkg-reconfigure against those. but may have chosen this during installation, if there was a prompt.
[11:48] <tomreyn> s/quries/queried/
[11:49] <TJ-> the .postinst isn't entirely clear but it looks like it reads the debconf via db_get to determine whether to enable on 'configure', so maybe there was something weird there
[12:37] <JustJohnny> what are the recomended options to implement bare metal backup in CLI-only ubuntu server?
[12:46] <blackflow> JustJohnny: ZFS filesystem + snapshots w/ send|recv offsite
[12:53] <JustJohnny> that would require to reinstall and reconfigure the servers, I'm afraid
[12:56] <tomreyn> i wouldn't say that ZFS is a general recommendation for ubuntu there.
[13:01] <tomreyn> lvm snapshotting would be the more traditional route, doesn't depend on out of tree modules. i agree zfs can be the better option while support and performance last.
[13:02] <JustJohnny> I just read about timeshift but it comes with GUI and this is a CLI-only enviroment
[13:19] <tomreyn> timeshift uses btrfs snapshotting, that's also an option if you consider the btrfs features you'll use to be sufficiently stable.
[13:20] <TJ-> backup != snapshot, sounds like a job for rsync/bacula or similar
[13:31] <blackflow> tomreyn: why wouldn't be ZFS recommended? Ubuntu is officially supporting ZFS and the next LTS installer is supposedly getting support for it as well.
[13:31] <blackflow> TJ-: backup = snapshot + offsiting
[13:33] <blackflow> even without offsiting it's a form of backup. backup fs state before a change is made. one that you can revert to. it's a backup alright.
[13:34] <tomreyn> blackflow: i'm just saying IMO it's not *the* generic recommendation. you know why: possibly degrading performance and supportability as a result of license incompatibilies / linux dev's interest in supporting it. btrfs is also supported by the installer, i would still not *generally* recommend it for production.
[13:34] <blackflow> that's a load of BS. there is no single "the" generic recommendation.
[13:35] <rbasak> I had a btrfs filesystem fail to mount and fail to fsck the other day, though it's a very old one (from 2012 ish)
[13:35] <rbasak> Had to restore from backup
[13:35] <blackflow> btrfs is a valid alternative to ZFS, yes I agree.
[13:35] <blackflow> I personally recommend ZFS because I've got a metric ton of experience with it, on and off Ubuntu.
[13:36] <blackflow> and lol the OP quit before they saw all this..... _neway_ I was about to recommend rsnapshot if fs choice is unfeasible. it's fs agnostic, works with hardlink based snapshots and rsync. I used it for years before I started using ZFS.
[13:37] <blackflow> "snapshots" .... as atomic as it gets with rsync, which is not too much... but still.
[13:49] <TJ-> the number of outstanding defects in ZoL wouldn't make me confident to rely on it, in the same way that BTRFS is suspected due to its issues.
[13:50] <TJ-> many of those in the send|resume component too
[13:52] <blackflow> well, I'm using it on a fleet of debian and ubuntu servers (the kind of servers that keep food on my table), some freebsd still, for years now. so I'm confident to recommend it.   on the other hand, somethign as mature as ext4 _still_ in 2018 had data corrupting bugs...
[13:54] <blackflow> at the storage scale we use, which is a lot or nothing much, depending whom you ask, I've seen bitrot and I've seen ZFS in action auto-correcting it. I'd never use anything other than ZFS.
[14:17] <TJ-> it's often corner-cases that catch folks out. This is what I am referring to: https://github.com/zfsonlinux/zfs/issues?q=is%3Aissue+is%3Aopen+label%3A%22Type%3A+Defect%22
[14:30] <smoser> hey. it'd be nice if someone on ubuntu server team reviewed this
[14:30] <smoser>  https://code.launchpad.net/~smoser/cloud-utils/+git/cloud-utils/+merge/370135
[14:30] <smoser> and even merged it... jsut to have one of you all in the flow there.
[14:30] <smoser> powersj: ^
[16:32] <supaman> hey, I have several websites and running apache virtual hosts, I have all the websites on an NFS host and the webserver mounts the websites from there, the logs for each website goes to the path /var/www/website/logs (not /var/log)
[16:33] <supaman> the logs seem to be updated (not rotated) monthly but some don't get cleared correctly and get filled up with empty space in the beginning
[16:33] <supaman> so I end up with 4GB logs that are 90% or more just empty space
[16:34] <supaman> I want to find out what is handling these logs but can't find anything in cron or systemd timer
[16:34] <supaman> any idea?
[16:34] <lordcirth> supaman, are they sparse files?
[16:34] <sdeziel> supaman: check logrotate maybe?
[16:35] <supaman> lordcirth: sparse files? ... don't think so, how do I find out?
[16:35] <lordcirth> supaman, compare ls -l to du
[16:35] <supaman> sdeziel: can't find anything in logrotate
[16:37] <supaman> lordcirth: aha, ls -l gives 5700115704 but du gives 124440
[16:37] <lordcirth> called it. So I bet the application is writing to the new file at the old offset, instead of starting over
[16:37] <lordcirth> So it gets created sparse.
[16:38] <supaman> ok, but that doesn't really solve my question of "what is handling this" :-)
[16:38] <supaman> some log files for other websites are just fine, no empty space in the beginning, and they all start at the beginning of the month
[16:39] <supaman> so something is doing something to those logfiles
[16:39] <supaman> :-)
[16:39] <lordcirth> on the bright side, at least it's not filling your disk
[16:39] <supaman> true :-)
[16:40] <lordcirth> supaman, so, you are running what Ubuntu version? Apache installed from repos? How did you configure Apache?
[16:41] <supaman> lordcirth: Ubuntu 18.04 with apache from Ubuntu repo
[16:42] <supaman> versoin 2.4.49 of apache
[16:43] <supaman> I don't know how Apache was configured in the beginning, this is not a system I set up
[16:43] <lordcirth> supaman, ok, well, start going through /etc/apache2 I guess?
[16:44] <supaman> yeah, any hint on what I should be looking for (not that familiar with apache)
[16:46] <lordcirth> supaman, Well, I would look in /etc/apache2/sites-enabled first. See if there is anything in there overriding logging settings. Otherwise, look in apache.conf
[16:47] <lordcirth> conf-enabled/ is also a good place to putting logging config
[16:51] <supaman> ok, looking at a sites-enabled for one of the sites shows nothing unusal, ServerName, ServerAlias, ServerAdmin, DocumentRoot, ErrorLog (and path to it), SetEnvIf Request_URI "^/check\.txt$" dontlog, Customlog /path/to/log combined env=!dontlog and then finishes off with https rewrite
[16:52] <lordcirth> supaman, alternatively, just grep -r for the unusual log path
[16:54] <smoser> rharper: i suspect there is no autolander at https://code.launchpad.net/~smoser/cloud-utils/+git/cloud-utils/+merge/370135
[16:54] <smoser> but autolanders are nice. so... if that was configured, that'd be nice.
[16:54] <smoser> i'm going to land that manually.
[16:59] <rharper> smoser: right, we could set up the autolander to look at cloud-utils
[17:00] <supaman> lordcirth: not finding anything
[17:01] <lordcirth> supaman, grep -r all of /etc? I've found things that way before :P
[17:08] <supaman> ah well ... I give up on this, will just monitor the system during next end of month and see if I can catch the culprit ;-)
[17:10] <supaman> lordcirth: thanks for assist though
[17:32] <lordcirth> supaman, np, it's an odd one
[17:32] <lordcirth> Picking up other people's servers is the worst sometimes
[21:44] <sxclimax> I have a home server running lubuntu. I have a hitron CGN3U router. I have things set up to the point that I can access my server's website remotely (e.g. website.noip.me) and the correct page displays, but when I try to ssh into website.noip.me I cannot get in. When I type in my local ip address for the network (192.168.X.X) I can access both the html and ssh. What am I missing? Is this in the router settings? Is this a port issue?