[00:41] <pepperhead> Anyone alive out there? Trying to install SabNZBD to ubuntu server 18.04, it is refusing connections
[00:41] <pepperhead> Status says it is active and running
[00:44] <tomreyn> !info sabnzbdplus
[00:45] <tomreyn> use netcat -vv to connect to its default port and see whether the connection is exatblished successfully.
[00:46] <tomreyn> do this locally on the server first of all, to work around firewalling and NAT issues, then do it from remote.
[00:46] <pepperhead> netcat?
[00:46] <pepperhead> Appreciate the reply BTW
[00:47] <pepperhead> My server is headless, will it require a GUI?
[00:50] <pepperhead> So like "netcat -v 127.0.0.1 8080"?
[00:51] <pepperhead> Returns: netcat: connect to 127.0.0.1 port 8080 (tcp) failed: Connection refused
[00:53] <pepperhead> same for "netcat -v 192.168.1.241 8080"
[00:57] <pepperhead> shouldnt be any NAT, so maybe a firewall thing?
[01:01] <sarnold> connection refused could be firewall or it could be the application isn't listening on the port
[01:01] <sarnold> you can check what ports it is listening on with netstat -tlnp or ss
[01:02] <tomreyn> or lsof -i :8080
[01:02] <tomreyn> make sure the port number is correct, too
[01:02] <tomreyn> pepperhead ^
[01:02] <sarnold> woah
[01:02] <sarnold> tomreyn: that's handy
[01:02] <sarnold> way less typing :)
[01:02] <tomreyn> :)
[01:03] <pepperhead> HAH!
[01:04] <pepperhead> You guys are awesome
[01:04] <pepperhead> I ASSUMED it defaulted to 8080 so I didnt set the port in the service configuration as it said (optional)
[01:05] <pepperhead> Set it to 8080 and restarted the service...POOF
[01:06] <tomreyn> \o/
[01:06] <sarnold> nice :)
[01:11] <pepperhead> I was going to run these in docker containers, but that was totally not happening
[01:12] <pepperhead> Two down(Plex/Sab), one to go (Radarr)
[01:13] <sarnold> pepperhead: give lxd a quick look, I think it's easier to work with than docker
[01:14] <sarnold> docker feels like "here's a tarball of stuff I don't want to understand, give it a socket please" and lxd feels like "I'd like a bunch of systems that appear to be clean slates but with less overhead than qemu"
[01:15] <tomreyn> :) ^this
[01:15] <pepperhead> I started down that road, but ran into networking issues with the LXC to host thing. I may go back to it once I know the apps better.
[01:16] <pepperhead> The firewall tweeks are easier here, and on less thing to work on with LXC
[01:16] <pepperhead> I have LXC installed
[01:16] <tomreyn> s/lxc/lxd/
[01:17] <pepperhead> I like lxc/lxd, I am more familiar with freebsd jails
[01:17] <pepperhead> so might be easier to pick up
[01:18] <sarnold> I enjoyed reading https://blog.ubuntu.com/2016/04/07/lxd-networking-lxdbr0-explained
[01:18] <sarnold> wow, that's from 2016? it felt newer than that.. heh
[01:19] <pepperhead> lol
[01:19] <sarnold> so, uh, maybe take anything in there with a big-ass grain of salt :)
[03:15] <l4m8d4> Is there a reason why tasksel is not installed by default on ubuntu server 18.04? Are we supposed to use something else instead of it? Is there a more modern replacement or has everyone started to just install metapackages for what they need?
[03:16] <l4m8d4> I remember that back in the old days it was used by the installer so one could choose if they wanted ssh server, lamp stack, mail server etc.
[04:53] <cpaelzer> moin
[05:04] <shahrokh> I install ubuntu server 18.04 on virtualBox but dont working network. virtualbox netconfiguration is NAT and Hosy-only(192.168.56.1)
[05:11] <shahrokh> Do you have idea?
[05:13] <ChmEarl> shadoxx, do you have any /etc/netplan/*.yml ? and does it use dhcp?
[05:17] <ChmEarl> shadoxx, you may need to rewrite that *.yaml file for a static config that uses gateway 192.168.56.1
[05:18] <shahrokh> chmearl, yes i have 2 *.yaml config
[05:21] <shahrokh> https://gist.github.com/shahroukh/7ffc516ffbf606a5f7171b392038b7f5
[05:22] <ChmEarl> connect at 192.168.56.103
[05:22] <ChmEarl> shahrokh, can you ping or ssh to that IP from host?
[05:23] <shahrokh> i connect to 192.168.56.103 with ssh but dont have ping to google ot 8.8.8.8
[05:25] <shahrokh> result of networkctl: https://gist.github.com/shahroukh/7ffc516ffbf606a5f7171b392038b7f5#gistcomment-2632154
[05:26] <shahrokh> networkctrl status ofcource
[05:28] <ChmEarl> shahrokh, in the *.yaml, add 10.0.2.3 to the 2 other nameserver addresses
[05:29] <ChmEarl> then `netplan apply`
[05:29] <shahrokh> netplan apply result: Error in network definition //etc/netplan/01-netcfg.yaml line 8 column 19: address '10.0.2.3' is missing /prefixlength
[05:32] <ChmEarl> no , add it here: addresses: [8.8.8.8, 8.8.4.4]
[05:32] <ChmEarl> line 8 is wrong place
[05:38] <shahrokh> i dont understant, is correct?: https://gist.github.com/shahroukh/7ffc516ffbf606a5f7171b392038b7f5#file-01-netcfg-yaml
[05:39] <ChmEarl> yes, 02-netcfg looks better, might work, unless a route is needed too
[05:41] <ChmEarl> shahrokh, you still have an error in 01-netcfg
[05:41] <shahrokh> yes
[05:42] <ChmEarl> remove  addresses: [10.0.2.3] from 01-netcfg... you added there earlier
[05:42] <ChmEarl> remove  `addresses: [10.0.2.3]` from 01-netcfg... you added there earlier
[05:43] <shahrokh> comment addresses and gateway in 01-netcfg.. but netplan result: Error in network definition //etc/netplan/01-netcfg.yaml line 10 column 19: address '8.8.8.8' is missing /prefixlength
[05:43] <shahrokh> :-D
[05:46] <ChmEarl> should be no extra 10.0.2.3 in 01-netcfg
[05:47] <ChmEarl> no changes to original 01-netcfg are needed. Only change 02-netcfg
[05:52] <shahrokh> commnet nameservers in 01-netcfg and netplan apply restault is ok
[05:53] <shahrokh> what am i doing??
[05:54] <shahrokh> dont ping 8.8.8.8
[05:58] <shahrokh> @ChmEarl
[05:58] <ChmEarl> shadoxx, you started out showing me 02-netcfg, then you made mods to 01-netcfg too, why?
[05:59] <lordievader> Good morning
[06:00] <ChmEarl> sorry, meant for shahrokh , not shadoxx
[06:01] <shahrokh> what do you mean? start by 02 but made mode 01? i dont understand
[06:01] <shahrokh> no problem my dear :-D shadoxx or shahrokh
[06:02] <ChmEarl> shahrokh, your edits are track in github, so use the features and back out the change to 01-netcfg
[06:04] <shahrokh> do you edit code in my github link?
[06:05] <shahrokh> i have 2 files for any ethernet
[06:06] <shahrokh> https://gist.github.com/shahroukh/7ffc516ffbf606a5f7171b392038b7f5
[06:20] <shahrokh> ChmEarl
[06:52] <shahrokh> do have any idea for my use case?
[07:06] <oe1skw> good morning
[08:49] <trippeh_> hum. Network Manager is refusing to manage any ethernet interfaces
[08:49] <trippeh_> enp5s0  ethernet  unmanaged  --
[08:49] <trippeh_> nmcli dev set enp5s0 managed yes -> succeeds
[08:49] <trippeh_> still unamanged
[08:52] <trippeh_>  unmanaged-devices=*,except:type:wifi,except:type:wwan
[08:52] <trippeh_> ha wow
[08:52] <lordievader> trippeh_: Is the interface defined in `/etc/network/interfaces`?
[08:52] <trippeh_> nope.
[08:52] <trippeh_> not in networkd or "netplan" either
[08:53] <trippeh_> but I think I figured it out now. ubuntu has started blacklisting all non-wifi/wwan devices.
[08:53] <lordievader> Err, does the * in `unmanaged-devices` not match the ethernet adapter?
[08:55] <trippeh_> lordievader: yes, it matches, it is a blacklist.
[08:57] <lordievader> So, that is why the ethernet device keeps being unmanaged?
[09:00] <trippeh_> yup.
[09:00] <trippeh_> this also broke usb ethernet dongles on my laptop. so has been a long running annoyance.
[09:01] <lordievader> Does this mean your issue is solved?
[09:02] <trippeh_> yes, by touch /etc/NetworkManager/conf.d/10-globally-managed-devices.conf to override the ubuntu shipped configuration.
[09:02] <lordievader> Ok, good to hear 👍
[09:17] <trippeh_> surprise, now my VPNs work too ;)
[12:38] <cyphermox> trippeh: fwiw, when you set 'renderer: NetworkManager' in netplan when you configure network devices there, it does set things to be managed by NM (ie. touching /run/NetworkManager/conf.d/10-globally-...)
[12:39] <cyphermox> desktop installs ship a file that make sure NetworkManager manages everything: https://netplan.io/examples#network-manager
[12:40] <trippeh_> netplan is not installed
[12:40] <cyphermox> trippeh_: if you have a server on which you install NetworkManager, and then use it to manage VPN and whatnot, then it will indeed explain why these devices did not work. by default, only wifi/wwan are managed by NM, as networkd can't do them well
[12:41] <cyphermox> netplan.io is installed everywhere. if you remove it yourself, you are still left with distro defaults that may be installed, such as that 10-globally- file.
[12:49] <trippeh_> supposedly the file is set on upgrades as well, but that had not happened here for whatever reason
[12:49] <trippeh_> maybe some fallout from running betas.
[12:56] <rbasak> cpaelzer or ahasenack: would you mind reviewing https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/347299 for me please?
[12:56] <rbasak> It's fairly trivial.
[13:01] <cpaelzer> rbasak:  looking
[13:03] <cpaelzer> rbasak: did you see the call for mysql migration assitance?
[13:03] <cpaelzer> I did not yet get to it today
[13:04] <rbasak> Yeah but it didn't seem immediately actionable to me. doko had already uploaded a no change rebuild and it was still building
[13:05] <cpaelzer> ok
[13:05] <trippeh_> cyphermox: network manager still failing silently after purge and reinstall was very confusing until I found that file. :)
[13:06] <trippeh_> no hints in logs or anything.
[13:33] <rbasak> cpaelzer: I didn't think a re-raise was needed because that's exactly what the stack trace is for. Given that all the re-raise would do is say "it was re-raised from _here_".
[13:45] <cpaelzer> rbasak: so you want it explicitly uncatched to get the builtin stacktrace - I see that
[13:45] <cpaelzer> but I wanted the log message before the trace
[13:46] <cpaelzer> that is what I thought to achive by the re-raise
[13:46] <cpaelzer> if the original trace is lost by the re-raise the log message isn't worth it
[13:49] <rbasak> We can log and reraise if we want.
[13:50] <rbasak> But what would that really achieve?
[13:50] <rbasak> 'Cannot get all versions from changelog' doesn't tell us any more than the knowledge that we're in a function called get_all_changelog_versions_from_treeish, and that knowledge is provided by the stack trace.
[14:00] <cpaelzer> rbasak: one day there will be two checks in there
[14:00] <cpaelzer> and then you'll be happy to see immediately which one triggers
[14:01] <cpaelzer> rbasak: but this is rather soft feedback, you had no real issues - so feel free to commit as is if you prefer otherwise
[14:04] <rbasak> OK. Thank you for the review!
[14:44] <njbair> i'm having the hardest time getting conjure-up to work. it keeps timing out at different points during the build while trying to access api.jujucharms.com, but every time i try the timeout happens at a different point in the process
[14:44] <njbair> seems like intermittent network trouble, but i'm not sure if it's on my end or a known issue with the api?
[17:38] <ahasenack> rbasak: hi, if you are still around, could you please push the upload tag for this mp? https://code.launchpad.net/~ahasenack/ubuntu/+source/apache2/+git/apache2/+merge/348632
[17:38] <ahasenack> rbasak: I couldn't find the right Author, so I'm going with just Origin in the dep3 header
[17:38] <Ussat> in 16.04 wgat version of cacti is there ?
[17:39] <ahasenack> Ussat: "rmadison cacti" tells me it's 0.8.8f+ds1-4ubuntu4.16.04.2
[17:40] <Ussat> wow....big jump from 16 to 18.04
[17:41] <Ussat> what is rmadison ?
[17:41] <nacc> !info cacti xenial
[17:41] <nacc> ahasenack: --^ fyi you can do that :)
[17:41] <Ussat> I did not know, thanks
[17:41] <ahasenack> figured :)
[17:41] <Ussat> appreciated
[17:43] <Ussat> the cacti 1.1.38 in 18.04 wont graph at all.....known issue with that version of cacti according to the forums and some emails
[17:43] <nacc> Ussat: rmadison is the archive database available over the network
[17:43] <nacc> s/is/queries/
[17:43] <Ussat> ahh
[17:44] <Ussat> !info cacti-spine xenial
[17:44] <nacc> Ussat: is there an ubuntu bug filed?
[17:44] <Ussat> I have not had time to take a proper dump, let alone fikle a bug...its on my todo list
[17:45] <Ussat> sorry so short...shit goin really sideways here
[17:46] <nacc> Ussat: understood
[17:47] <nacc> Ussat: so it's knonw upstream? fixed already?
[17:47] <Ussat> upstream and not fix, ack'd though
[17:48] <nacc> Ussat: ok, hard for us to do anything without an upstream fix :)
[17:50] <Ussat> yup
[17:52] <Ussat> Just ack'd the bug yesterday...so I would not expect anything soon
[17:57] <sruli> time on my server is out of sync - "timedatectl: Failed to query server: Failed to activate service 'org.freedesktop.timedate1': timed out"  - - "systemctl status systemd-timesyncd: ... ... systemd-timesyncd[742]: Timed out waiting for reply from 91.189.91.157:123 (ntp.ubuntu.com)" - - "ping 91.189.91.157: 64 bytes from 91.189.91.157: icmp_seq=1 ttl=55 time=80.1 ms"
[18:01] <blackflow> ping's irrelevant if there's an issue with the ntp service. Try another pool, like pool.ntp.org
[18:01] <blackflow> sruli: ^^^
[18:02] <sruli> how do i change it?
[18:02] <blackflow> sruli: /etc/systemd/timesyncd.conf
[18:05] <sruli> NTP=pool.ntp.org or FallbackNTP=pool.ntp.org ?
[18:06] <blackflow> NTP is primary
[18:06] <sruli> same, i get a timeout
[18:06] <nacc> `man timesyncd.conf`
[18:06] <blackflow> so yeah you could set FallbackNTP in case ntp.ubuntu.com for some reason isn't accessible
[18:07] <sruli> pool.ntp.org is also not working, womething else seems to be the issue
[18:09] <blackflow> sruli: firewall? is that a hosted server? some DCs don't allow outbound ntp due to it being easy to abuse, and require you to use their own servers
[18:10] <sruli> my own server, its a vm, just tested on another few on same network, cant find anything in touter iptables to block it
[18:12] <blackflow> residential ISP?
[18:12] <nacc> iirc, you can use ntpdate by hand to query an ntp server?
[18:13] <sruli> not residential but other servers (all 18.04) work fine
[18:14] <sruli> 28 Jun 18:14:27 ntpdate[29101]: no servers can be used, exiting
[18:15] <blackflow> speaking of "outer iptables", how's that set up for established,related  flows? the firewall needs to track UDP packets otherwise you'll have to open port 123 for inbound response UDP packets
[18:16] <sruli> established,related accept. will try to run a tcpdump now and see if i see anything
[18:20] <sruli> blackflow: its not hitting my router, also ntpdate exits so fast its not possible that its even trying to ake a connection
[18:21] <blackflow> sruli: I think if you disable ntp and then enable it (timedatectl set-ntp on|off) it should start syncing up when it's enabled again.
[18:21] <blackflow> if not, the nuke that carp and install proper ntp daemon. openntpd is recommended.
[18:21] <blackflow> !info openntpd
[18:21] <blackflow> *then
[18:24] <sruli> cant even turn it off "Failed to set ntp: Failed to activate service 'org.freedesktop.timedate1': timed out"
[18:24] <blackflow> ¯\_(ツ)_/¯  SystemD
[18:27] <sruli> openntpd not much in the man page, how do i query the time with it?
[18:28] <sdeziel> sruli: I believe you cannot
[18:28] <sdeziel> sruli: but check man ntpctl
[18:28] <nacc> i don't think openntpd is really the answer here
[18:28] <nacc> if ntpdate can't query the ntp server, something else is wrong
[18:29] <sruli> nacc: ntpdate isnt even trying, its exits faster than its possible to establish a connection
[18:29] <nacc> sruli: how did you run it?
[18:29] <sruli> ntpdate
[18:30] <nacc> sruli: right, so you didn't tell it to query any servers :)
[18:30] <nacc> sruli: hint, `man ntpdate`
[18:30] <sdeziel> ntpdate -q -v pool.ntp.org
[18:30] <sruli> No manual entry for nptdate
[18:30] <sdeziel> sruli: s/npt/ntp/ ;)
[18:31] <sruli> ;-)
[18:33] <sruli> time is adjusted, but how do i set it for summer time?
[18:34] <nacc> sruli: so manual ntpdate worked?
[18:34] <sruli> yes
[18:34] <sdeziel> sruli: this is not related to NTP, it's a TZ (timezone) setting
[18:35] <nacc> sruli: or was that a joke re: summer time? :)
[18:35] <sdeziel> sruli: could you run "ntpdate -q -v 91.189.91.157"
[18:35] <sruli> nacc, i need to set it to current local time, cant do it with timedatectl as its timing out
[18:36] <sruli> sdeziel: worked
[18:36] <sdeziel> sruli: that's weird as that was the IP systemd-timesyncd couldn't reach
[18:37] <nacc> yeah something seems off
[18:37] <sruli> as far as i understand the timezone is supposed to be set in timedatectl... something is broke witht he timedatectl.. any other way i can change the tz?
[19:03] <l4m8d4> sruli: Have you read the server manual? You're not supposed to install ntpd or any other time sync package if you use timedatectl
[19:04] <l4m8d4> So just remove ntpd and try again with timedatectl
[19:24] <l4m8d4> If you configure link aggregation of two ethernet ports with netplan, does the network switch have to support that explicitly?
[19:25] <tomreyn> how would you do link aggregation on a single side of the transfer only?
[19:25] <sruli> l4m8d4: i started off with timedatectl it doesnt work thats why i needed something else!
[19:26] <dlloyd> there are some super naive implementations that do not require switch participation, but are not really aggregation
[19:26] <sruli> l4m8d4: for link agg switch needs to support 802.3ad.. else you can use other bonding methods
[19:26] <l4m8d4> tomreyn: Yeah, that was the question. I just wanted to know if that is possible or if both deviced need to be "informed" of the bond
[19:27] <l4m8d4> Okay thank you
[19:27] <tomreyn> you can also run a mirror raid with just a single raid device. but does it make sense? not a lot.
[19:27] <blackflow> ntpdate is just a temporary solution, you have to figure out why continuous syncing is not working
[19:27] <sruli> l4m8d4: it needs to be setup on both sides
[19:28] <sruli> blackflow: i know, don't know how to troubleshoot this.. hever has a issue with time sync in the past
[19:29] <sarnold> if timedatectl thing isn't sufficient for you, try chrony next
[19:29] <sruli> sarnold: it's not that it's not sufficient, it's just broke, doesnt work
[19:29] <sruli> and i would like to fix it if poss
[19:30] <l4m8d4> sruli: Are you sure that neither chrony nor ntpd is installed? Because if that were the case, timedatectl would be disabled automatically to prevent conflicts
[19:30] <blackflow> sruli: apparently you can't start or stop the daemon. that's why I recommended you nuke the systemd component and use an external one. systemd is init + process manager, anything else is half assed, constantly broken insecure reinvention. as observed with resolved and I'm pretty sure that timesyncd went belly up because something something dbus.
[19:31] <sruli> l4m8d4: ntpd was installed to check if there a problem with reaching npt protocol on the server.. timedatectl was broke before that, will remove it now and test timedatectl again
[19:33] <l4m8d4> blackflow: timedatectl is configured on ubuntu to be disabled automatically if other means of sync are present, so there should be no need to "nuke" the component
[19:34] <blackflow> l4m8d4: with "org.freedesktop.timedate1" timing out if attempted?
[19:34] <sruli> l4m8d4: removed ntpd - :~# timedatectl Failed to query server: Connection timed out
[19:34] <blackflow> you don't say.
[19:34] <sarnold> blackflow: something something dbus :)
[19:34] <blackflow> x-actly :)
[19:35] <l4m8d4> sruli: What is the output of systemctl status systemd-timesyncd.service
[19:35] <sruli> "systemctl status systemd-timesyncd: ... ... systemd-timesyncd[742]: Timed out waiting for reply from 91.189.91.157:123 (ntp.ubuntu.com)"
[19:36] <sruli> ^^^ that was before.. now its just deat
[19:36] <l4m8d4> sruli: What happens if you start it manually?
[19:37] <sruli> times out.. in the process of timing out now
[19:38] <blackflow> openntpd is nice. you can even peg it to a https domain to validate the ntp response so your time can't be messed with by rogue ntp servers
[19:38] <sruli> systemd[1]: systemd-timesyncd.service: Start operation timed out. Terminating.
[19:38] <sruli> systemd[1]: systemd-timesyncd.service: Failed with result 'timeout'.
[19:38] <sruli> systemd[1]: Failed to start Network Time Synchronization.
[19:39] <blackflow> been using it on all linux and freebsd machines, never needed anything else. it's less precise than ISC ntpd but you don't need nanosecond precision do you? you aren't running HFT or something
[19:40] <sruli> all i need is the correct time, not asking for much
[19:40] <l4m8d4> sruli: But ntp.ubuntu.com is reachable otherwise, right?
[19:40] <sarnold> sruli: you don't happen to have funny firewall rules dropping udp packets or something?
[19:40] <blackflow> been through all that, and ntpdate worked.
[19:40] <sdeziel> the "start operation timed out" doesn't seem like NTP related to me, more like systemd having a bad day
[19:41] <blackflow> duh!  :)
[19:41] <blackflow> bad day, week, month and past 10 years actually :)
[19:41] <sruli> i was able to use ntpd and ntpdate... and i ran a tcpdump to see if any packets were being dropped by the router timedatectl did not send any packets out of the vm
[19:41] <sdeziel> I love systemd, for real ;)
[19:41] <sruli> i also love it (when it works)
[19:41] <blackflow> process management is good, the power of unit files awesome. but evrything ELSE, suxxxxxxxx
[19:42] <sdeziel> sruli: beware that timesyncd will back down if any other ntpd daemon is even present on the system
[19:42] <blackflow> resolved, timesyncd, nspawn, firewalld.... ughd!
[19:42] <sdeziel> sruli: did you pastebin "journalctl -u systemd-timesyncd" earlier?
[19:44] <l4m8d4> sdeziel: That's also what I would guess. Maybe they can't rely upon other packages stopping the service properly, so they decided to weirdly detect different timesync services and just time out if one is detected.
[19:44] <blackflow> WHAT!
[19:44] <sruli> http://termbin.com/t2f8
[19:45] <sdeziel> sruli: thx, have you made some changes to timesyncd.conf that were not reverted?
[19:46] <sdeziel> sruli: cause at "Jun 28 17:49:17" you manually stopped the service and tried to start it back... and it never worked
[19:47] <sarnold> so uh what changed between Jun 28 16:25:11 and Jun 28 17:49:17?
[19:48] <blackflow> sruli: btw, are there any errors showing up wrt resolving ntp.ubuntu.com domain for systemd-resolved service?  you tried ntpdate against an IP, but not against a pool name....
[19:49] <sdeziel> l4m8d4: I find timesyncd very well behaved as it doesn't try to concurrently manage my clock if I opt in for another NTP implementation :)
[19:49] <sruli> blackflow: just tried with poo.ntp.org worked
[19:49] <l4m8d4> Yeah, it is strange because 1) sometimes it timed out waiting for some servers, which I never experience and 2) in the end it doesn't seem to try to sync anymore
[19:50] <sdeziel> I still think it's not NTP related ;)
[19:50] <sdeziel> systemd complains that the daemon doesn't starts properly
[19:50] <sdeziel> and IIRC, timesyncd can cope with the inability to resolve DNS at startup
[19:51] <LaserAllan_> hey guys, just a stupid question, what package do I need to install php-fpm on ubuntu 1804?, I think i tried it sometime ago and it wanted ot install apache, which i don't really use
[19:51] <sruli> sarnold: it stopped working Jun 27 02:19:52, no clue what happend at that time
[19:52] <blackflow> LaserAllan_: incredibly, but....   php-fpm
[19:53] <blackflow> LaserAllan_: also note that php-fpm is orthogonal to apache. you can install nginx first and php-fpm wouldn't pull in apache.
[19:54] <LaserAllan_> blackflow: So tha tis why
[19:54] <LaserAllan_> Weird, i think i installed nginx first thought but i might be wrong :)
[19:54] <LaserAllan_> I will try that thank you
[19:55] <l4m8d4> sruli: I think it really started to break at Jun 28 17:50:48
[19:55] <blackflow> LaserAllan_: in fact, on Bionic it's now completely separate from httpd it seems. on 16.04 there use to be .... .issues.
[19:55] <l4m8d4> Before then it still tried to sync
[19:55] <l4m8d4> After that it just failed silently
[19:56] <blackflow> sruli: hey, you want good, stable, secure, no shenanigans, ntp client service?  try out openntpd! you won't regret it ;)
[19:56] <LaserAllan_> blackflow: Sounds good, I have been using quite allot of CentOS and FreeBSd before so this is kinda new to me. But I thought id give Ubuntu 1804 a spin now that my 1404 machine is very old and needs to slowly ie.
[19:56] <sruli> l4m8d4: lol thats when i started investigating why my time is wrong, and just tried to restart it
[19:57] <sdeziel> sruli: IIRC, at some point you edited it's conf file, no?
[19:57] <l4m8d4> sruli: You may want to adjust the systemd log level to get more details on this
[19:58] <sruli> sdeziel: yes i tried to change to pool.ntp.org, reverted later
[19:58] <sruli> l4m8d4: where do i change the log level for this?
[19:58] <LaserAllan_> l4m8d4: How do adjust the systemd log level? (just curious)
[19:58] <blackflow> or! or! here's a wild idea! install an ntpd developed by people who know what they're doing. :)  also, bonus https-based constraint check!
[20:00] <l4m8d4> sruli: systemd-analyze log-level
[20:00] <l4m8d4> Without parameter, it just gives you the current log level
[20:01] <l4m8d4> Otherwise you pass a log level, one of "emerg, alert,crit, err, warning, notice, info, debug"
[20:01] <l4m8d4> In this verbosity order I guess, where emerg is the least verbose, debug the most verbose
[20:03] <sdeziel> l4m8d4: thanks, I didn't know that one!
[20:03] <l4m8d4> blackflow: Still, it would be interesting to know why the problem occurs, don't you think?
[20:03] <ahasenack> hm, autopkgtest-build-lxd tries to install a kernel into the container :/
[20:03] <ahasenack> that just hangs here
[20:04] <blackflow> l4m8d4: after all these years, it's no longer interesting to me to find out its' because something something over dbus via xml :)
[20:07] <l4m8d4> Well, I think if possible you should always investigate why something doesn't work as intended on your system. In my case, I often find out interesting things in the process at least.
[20:09] <blackflow> l4m8d4: thats' true, but with systemd, in my experience, that has mostly been a carnival ride that burns you out.
[20:10] <blackflow> I've minimized that pain by using only the most minimum: init + process management, w/ journal (and only as a short in-memory buffer before syslog-ng).
[20:10] <blackflow> _that_ works quite well, indeed.
[20:10] <l4m8d4> blackflow: Then we have a different experience. For me, systemd has made managing the systemd a lot easier.
[20:10] <l4m8d4> blackflow: In that case, maybe you should consider going with a distribution that doesn't ship systemd by default, that might make you happy
[20:11] <blackflow> oh yes, no systemd is default in our shop. but sometimes, for some clients, you need to maintain systemd :)
[20:11] <l4m8d4> *managing the system, funny typo though
[20:14] <blackflow> the features and kernel capabilities (AND CAP capabilities) exposed through simple ini files really is awesome, yes. that part of systemd I like.
[20:15] <blackflow> but lets' be real. systemd-resolved? that thing has been nothing but a wild ride of vulns and half assed implementations. ubuntu 17.04 got burnt pretty good for defaulting to it.   systemd-timesyncd? also half-assed and vulnerable, and why on earth would I remove working quality ntpd clients that have worked well for years.
[20:16] <sruli> i rebooted and magically it works now
[20:16] <blackflow> until it breaks again. :)
[20:16] <sruli> blackflow: i know
[20:21] <blackflow> btw, systemd-timesyncd.service on Bionic.... there aren't ConditionFileIsExecutable  conditions defined by default?
[20:21] <blackflow> on debian they're in /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
[20:23] <blackflow> how does that work then
[20:26] <l4m8d4> blackflow: I guess that the system will just call "systemctl stop systemd-timesyncd.service && systemctl disable systemd-timesyncd.service" if you install something else
[20:27] <blackflow> where's that trigger defined?
[20:29] <blackflow> sdeziel: "sruli: beware that timesyncd will back down if any other ntpd daemon is even present on the system"   -- how, on Bionic?
[20:32] <sdeziel> blackflow: I don't know, I just checked chrony's postinst and there is nothing in there
[20:33] <blackflow> I thought ubuntu wsa based on debian? :)
[20:33] <nacc> blackflow: what do you think "based on" means?
[20:33] <blackflow> on debian there's a nice list of ConditionFileIsExecutable   that prevents start up if the other daemons (virtualbox included) are present
[20:33] <blackflow> nacc: debs taken from debian unstable?
[20:34] <nacc> blackflow: at some point in time
[20:34] <blackflow> is there any other definition?
[20:34] <nacc> blackflow: is the debian changes more recent than bionic?
[20:34] <blackflow> nope
[20:34] <blackflow> it's actually years old
[20:34] <blackflow> in fact, I believe even Xenial had those, but I have no xenial systems now to check
[20:36] <nacc> blackflow: checking git
[20:36] <sdeziel> blackflow: yes, xenial has that disable-with-time-daemon.conf snippet
[20:36] <blackflow> so, huge regression on Bionic?
[20:36] <sarnold> https://patches.ubuntu.com/s/systemd/systemd_237-3ubuntu10.patch
[20:36] <sarnold> +  * Drop systemd-timesyncd.service.d/disable-with-time-daemon.conf.
[20:36] <sarnold> +    All major NTP implementations ship a native service file nowadays with a
[20:37] <sarnold> +    Conflicts=systemd-timesyncd.service so this drop-in is no longer
[20:37] <sarnold> +    necessary. (Closes: #873185) (LP: #1721204)
[20:37] <nacc> sarnold: thanks
[20:37] <blackflow> I see.
[20:40] <l4m8d4> Yeah, I guess thats a more clean way of preventing conflicts there
[20:57] <blackflow> l4m8d4: yeah it's cleaner if individual packages conflicted on timesyncd, and packages amongthemselves are not installable together.
[20:58] <blackflow> the old method required one package to know all installable variants, hardcoded in teh config