[05:37] <Ham62_> how do I roll back to the pervious server version after installing an update
[05:38] <Ham62> I had a server running 12.04 fine and it kept nagging me to update so I just finished the update to 14.04 and after it booted into the login screen the entire display is just white with little black outlines where text is supposed tobe
[05:38] <Ham62> I can't read anything so I want to roll back to 12.04 so at least the local terminal is usable
[05:40] <Ham62> this is what I get when it boots: https://i.imgur.com/BKvV5yq.jpg
[05:40] <Ham62> I typed in the username and password at the top and this is the greeting message with the bash prompt on the bottom
[05:41] <Ham62> I don't have any GUI or anything installed this is just running on the text mode
[05:45] <lotuspsychje> Ham62: 12.04 is end of life
[05:45] <Ham62> 14.04 has brought the end of usability to my system so I think that I don't have much choice
[05:46] <lotuspsychje> Ham62: its not a good idea to upgrade from an eol version, would you still trust it?
[05:46] <Ham62> I don't need the latest security updates and everythign I'm just using it on my LAN
[05:47] <lotuspsychje> Ham62: also, 14.04 will be eol soon too
[05:47] <lotuspsychje> Ham62: would be wise backing up your data and start fresh 16.04 or 18.04
[05:48] <Ham62> you think that doing further updates would fix the video issues going 12 -> 14?
[05:49] <lotuspsychje> Ham62: you just said your on inside lan? sno not connected to internet?
[05:49] <Ham62> it has internet but it has nothing ported forward
[05:50] <lotuspsychje> Ham62: then its not wise to upgrade from eol
[05:50] <lotuspsychje> !eolupgrade
[05:50] <lotuspsychje> but its your system Ham62 we can only advice
[05:51] <Ham62> my media center PC on my TV is still running XP and has no issues it's not going to become part of a massive botnet just from having a connection behind a firewall
[05:52] <lotuspsychje> Ham62: a firewall isnt a 100% proof of not getting exploited
[05:53] <Ham62> if no one is connecting into you you won't get exploited
[05:53] <Ham62> if there is no access point for them to exploit you you can't be exploited
[05:54] <Ham62> and I'm not running a web browser or anything connecting to other sites so it won't get malware that way
[05:55] <lotuspsychje> Ham62: what makes you so sure nobody connects you on your EOL server?
[05:56] <Ham62> because I have nothing ported forward
[05:56] <Ham62> there is no way to access this system from outside the LAN
[05:56] <lotuspsychje> Ham62: you receive updates to your server right
[05:56] <Ham62> when I tell it to
[05:56] <lotuspsychje> so your connected
[05:56] <Ham62> this is the first time installing an update to it in 2 years
[05:57] <lotuspsychje> !usn
[05:57] <lotuspsychje> check how many exploits out there on eol versions
[05:58] <Ham62> I see lots of exploits for escaping a virtual machine
[05:58] <Ham62> which 1) requires running the native code on the VM and 2) having a VM installed
[05:58] <Ham62> and PHP vulnerablility which again you need to be running a PHP server ported forward
[05:59] <lotuspsychje> listen im not gonna kee argue, i advice you a fresh 16.04 or 18.04
[06:00] <lotuspsychje> if you decide upgrading to 14.04, in a month its also eol and youl need to upgrade to 16.04 anyway
[07:48] <lordievader> Good morning
[08:11] <kstenerud> Who would be the person to talk to about debugging incorrect systemd configurations?
[08:12] <kstenerud> As in, figuring out why systemd reports things like: Failed with result 'exit-code'
[08:13] <kstenerud> or: -- The result is RESULT.
[08:17] <cpaelzer> coreycb: thank you for the testing
[08:28] <blackflow> kstenerud: depends on the package, perhaps start with a bugreport
[08:29] <kstenerud> it's with corosync, which I'm taking over. But first I need to debug why the service fails to start
[08:29] <kstenerud> but it looks like systemd is getting faked info in the result codes, which makes this difficult to debug
[08:30] <blackflow> or it can't tell because it's a forking service
[08:30] <blackflow> ideally with sd, wherever possible daemons should run as Type=simple or notify if it supports that
[08:31] <blackflow> that's why I said start with the package, as I've seen packages with forking type where it shouldn't have been. nginx, redis just to name the two recent examples. and hell, redis even supports notify
[08:32] <kstenerud> hmm looks like it's type notify
[08:34] <blackflow> I guess the service is not informing systemd properly then. is there a specifc application log?
[08:35] <kstenerud> there is, but it's empty
[08:36] <blackflow> are there any confinements? ProtectSystem= ? seccomp fileters? disable temporarily all confinements?
[08:36] <kstenerud> uhh... sorry where would I find those?
[08:36] <blackflow> in the service unit file
[08:38] <kstenerud> Nothing like that I can see: https://pastebin.ubuntu.com/p/YvTDpTXVdq/
[08:40] <blackflow> kstenerud: can you pastebin the output of journalctl -xe   right after you attemp to start it and it fails?
[08:41] <kstenerud> sure hang on
[08:42] <blackflow> google can't seem to find any mention of it supporting systemd notify. usually daemons have a config option you can flip to tell them they're run under systemd and they should enable the notify API, I don't see that for corosync
[08:43] <kstenerud> https://pastebin.ubuntu.com/p/TMfRKMgYrk/
[08:44] <blackflow> kstenerud: try Type=simple.  that -f in the unit means "start application in foreground".  Maybe it just does not support the notify api
[08:44] <kstenerud> ok let's see...
[08:47] <kstenerud> wow! It was just that??? Crazy. It works now
[08:49] <kstenerud> thanks!
[08:53] <blackflow> you're welcome. it'd be wise to get yourself acquainted with systemd manuals and documentation if you're gonna maintain packages like that.  use the systemd.directives(7) manapge as reference point for all the config directives
[08:59] <kstenerud> ok, thanks
[13:30] <siavoshkc> Hi. I have a django server running correctly as I see. But in the log I see some errors:
[13:30] <siavoshkc> [Thu Mar 07 13:54:57.251327 2019] [wsgi:error] [pid 6129] Not Found: /
[13:30] <siavoshkc> [Thu Mar 07 13:54:57.617238 2019] [wsgi:error] [pid 6129] Forbidden: /quest/
[13:30] <siavoshkc> [Thu Mar 07 16:50:07.829690 2019] [wsgi:error] [pid 6129] Not Found: /favicon.ico
[13:30] <siavoshkc> [Thu Mar 07 16:55:09.896277 2019] [wsgi:error] [pid 6129] Forbidden: /quest/
[13:30] <siavoshkc> [Thu Mar 07 16:55:09.898376 2019] [wsgi:error] [pid 6129] Not Found: /
[13:31] <siavoshkc> Ignoring favicon.ico, I don't know about the others
[13:32] <ahasenack> siavoshkc: looks like a scan for vulnerabilities
[13:32] <Ussat> yup
[13:32] <siavoshkc> Who is scanning?
[13:32] <Ussat> We see that wen our infosec scans also
[13:32] <ahasenack> "the internet"
[13:32] <siavoshkc> So its noise
[13:34] <siavoshkc> My security is rock solid.
[13:36] <Ussat> Thats what is normally said right before a hack
[13:37] <mason> God Himself could not sink this ship.
[13:43] <Ussat> "Titanic Baby"
[13:43] <leftyfb> siavoshkc: How do you know your security is rock solid if you don't understand what you see in those logs?
[13:43] <Ussat> just stop with the logic leftyfb
[14:03] <rbasak> cpaelzer: confused by the posgres MRE. I thought we concluded that we wouldn't revert the ABI change as it's a "produces bad data" bug otherwise?
[14:05] <rbasak> Is this a different ABI change? What happened to the one we previously discussed?
[14:06] <siavoshkc> leftyfb: Good question.
[14:18] <cpaelzer> rbasak: I stated that in the bug, the "(potentially) produces bad data" change wasn't the ABI changing rename
[14:19] <cpaelzer> I only found that when sitting down and trying to prepare the checks for the extensions
[14:19] <rbasak> Ah
[14:19] <rbasak> I read your comment 19, but I couldn't find anything referring to the bad data bug.
[14:20] <cpaelzer> let me check which one #19 was
[14:21] <cpaelzer> rbasak: yeah the "other" change - that one about the client_min_messages would have a chance to cause bad data
[14:21] <cpaelzer> rbasak: which is not the ABI one
[14:21] <cpaelzer> rbasak: but, that client_min_messages has to be used incorrectly to cause that problem
[14:21] <cpaelzer> rbasak: unfortunately comments are immutable so we have a bunch of misleading comments collected over the time we worked on this :-/
[14:22] <cpaelzer> rbasak: the bug description should have the most current and most reasonable description
[14:22] <cpaelzer> rbasak: I made sure I mentioned all that in Regression potential
[14:22] <cpaelzer> in fact let me add something very important that I thought about last night
[14:23] <rbasak> cpaelzer: which bit of the regression potential refers to the bad data bug?
[14:25] <cpaelzer> rbasak: adding that as well more clearly
[14:28] <cpaelzer> rbasak: updated the description again to hopefully be even better now
[14:30] <cpaelzer> rbasak: the important bit I added on my own is the fact that by our choices we don't CHANGE anything on the two debated commits
[14:31] <cpaelzer> we take the MRE minus those two
[14:31] <cpaelzer> which makes the MRE less regression-likely
[14:38] <rbasak> cpaelzer: got time for a HO please? I'm still confused - trying to correct my old understanding with the corrections I think. A HO will probably be quickest.
[14:39] <cpaelzer> rbasak: I'm in one already, I'll ping you once I'm ready
[14:39] <rbasak> ack
[14:48] <coreycb> sahid: i've uploaded cinder, nova and swift to the bionic unapproved queue for bug 1818069 where they're awaiting review by the sru team: https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=
[14:48] <coreycb> also pushed to https://code.launchpad.net/~ubuntu-server-dev/+git
[14:48] <coreycb> thanks for those
[14:50] <sahid> coreycb: thanks
[16:15] <ahasenack> cpaelzer: I added X-Python3-Version: 3.7 to d/control
[16:15] <ahasenack> cpaelzer: the XS- variant is for python 2 only
[16:15] <ahasenack> I still get the warning about ${python3:Versions} being unused, well, it's really ununsed
[16:16] <ahasenack> your suggestion was to add it like X-Python3-Version: ${python3:Versions} (you mentioned the XS- variant, though)
[16:16] <ahasenack> right now, I think ${python3:Versions} expands to 3.7 only, or something like >= 3.7, < 3.8 (have to check)
[16:17] <ahasenack> I didn't find the text "python3:Versions" in the dh_python manpage, nor in https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html
[16:17] <ahasenack> rbasak: do you know something about that?
[16:17] <ahasenack> the warning we are talking about is:
[16:17] <ahasenack> dpkg-gencontrol: warning: package python3-tdb: substitution variable ${python3:Versions} unused, but is defined
[16:19] <rbasak> ahasenack: where's the source please?
[16:19] <ahasenack> rbasak: https://code.launchpad.net/~ahasenack/ubuntu/+source/tdb/+git/tdb/+ref/disco-tdb-1.3.18
[16:20] <ahasenack> I didn't commit the "X-Python3-Version: 3.7" change to d/control
[16:20] <ahasenack> but it's literally that line
[16:20] <cpaelzer> ahasenack: I haven't found the string in the man page either
[16:21] <cpaelzer> ahasenack: I only got there by grepping through all kind of packages and seeing them use it at that attribute
[16:21] <ahasenack> I see
[16:21] <ahasenack> my single example on my disk:
[16:21] <ahasenack> apparmor/apparmor/debian/control:XS-Python-Version: ${python3:Versions}
[16:22] <cpaelzer> ahasenack: http://paste.ubuntu.com/p/kmxSdrYwyP/
[16:22] <ahasenack> that is even incorrect, the policy says to use X-Python3-Version for python3
[16:22] <cpaelzer> yep
[16:23] <cpaelzer> that would be http://paste.ubuntu.com/p/NKvgnfqKdm/
[16:23] <cpaelzer> and http://paste.ubuntu.com/p/CmxKBsvQ9n/
[16:24] <ahasenack> "Similarly, the optional fields X-Python-Version or XS-Python-Version were used to specify the versions of Python 2 supported by the source package. They are obsolete and can be removed now that only Python 2.7 is supported."
[16:24] <ahasenack> at least that grep showed them being used for python2
[21:40] <teward> ahasenack: uhm
[21:40] <teward> the Debian bug?  I doubt it'll be acted on
[21:40] <teward> AIUI, we shouldn't be updating units to *specifically* target network-online.target
[21:40] <teward> wrt https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1818574
[21:41] <teward> ahasenack: and the workaround AFAICT is to bind to all v6 *and* the IP they specifically want; at least, per Maxim's suggestions on that thread for workarounds
[21:41] <teward> ahasenack: and network-online.target *might* not solve the issue, necessarily, AIUI because 'network online' isn't clearly defined either.
[21:42] <sdeziel> teward: I tried binding to all IPs (listen [::]:443...; + listen [2001::...]:443...;) and it didn't work. Have you tried what Maxim suggested?
[21:43] <sdeziel> I was kind of surprised that NGINX didn't support IP_FREEBIND
[21:43] <sdeziel> but maybe I'm doing it wrong
[21:45] <sdeziel> as soon as I add the 2001::... IP to an interface, nginx is happy again
[21:46] <teward> sdeziel: not recently i haven't checked.  Her'es a question, does Apache support IP_FREEBIND as well?
[21:46] <teward> if *they* don't then the question is "Why should NGINX" (from NGINX's perspective)
[21:47] <teward> if none of them support it then the question is why not?
[21:47] <sdeziel> teward: because it's really handy in HA setups
[21:49] <lordcirth__> sdeziel, on ipv4 I had to enable nonlocal_bind in sysctl. Perhaps there's a similar option?
[21:49] <lordcirth__> This was for HAProxy + keepalived
[21:50] <sdeziel> lordcirth__: yeah, I think the sysctl key make it works for v4 but I haven't tested
[21:51] <sdeziel> lordcirth__: apache2 is happy binding a non-existent v4 once the sysctl is turned on
[21:51] <teward> sdeziel: but not without that set in sysctl?
[21:52] <lordcirth__> Without that set, the kernel will reject the syscall. Program doesn't get a choice.
[21:52] <sdeziel> teward: nope and I couldn't find a way to tell Apache to explicitly use IP_FREEBIND
[21:52] <teward> if kernel is 4.3+, then in theory net.ipv6.ip_nonlocal_bind would exist.
[21:52] <teward> sdeziel: then that's probably why NGINX isn't using it - nobody is.
[21:53] <teward> lordcirth__: see my sysctl message two lines up
[21:53] <lordcirth__> Yeah I saw it, thanks
[21:53] <teward> sdeziel: test if setting net.ipv6.ip_nonlocal_bind lets Apache or NGINX bind to nonexistent v6?
[21:53] <lordcirth__> It exists on my 18.04 machine
[21:53] <teward> i'm currently on my commute so I cna't pull an image down for lxd/
[21:53] <teward> to do testing
[21:53] <sdeziel> teward: wow, I wasn't aware of that sysctl, works with Apache
[21:53] <teward> sdeziel: Google Is My Friend!
[21:53] <teward> *shot*
[21:54] <teward> (found it at https://serverfault.com/questions/236626/how-to-bind-a-non-local-ipv6-address)
[21:54] <lordcirth__> Btw, sysctl variables set in LXC don't persist properly in 16.04
[21:54] <lordcirth__> They do in 18.04, though
[21:54] <teward> lordcirth__: LXC or LXD?
[21:54] <teward> and I have an 18.04 host and use 18.04 containers usually ;)
[21:54] <lordcirth__> It's a systemd version thing
[21:54] <lordcirth__> So probably both
[21:54] <teward> ah
[21:54] <teward> that darned systemd evil!
[21:54] <teward> :P
[21:54] <sdeziel> teward: and it also works with NGINX
[21:55] <teward> sdeziel: i'm not yet willing to suggest that we change sysctl but I'll propose that as a workaround
[21:55] <lordcirth__> I hacked it into an 'up' line in eth1.cfg :P But now that's gone, yay
[21:55] <sdeziel> teward: yeah, that's opt-in behavior IMHO too
[21:55] <lordcirth__> Why wouldn't you change sysctl?
[21:55] <lordcirth__> Or do you mean by default in Ubuntu?
[21:55] <teward> lordcirth__: i mean by default
[21:55] <teward> sdeziel: this is also why I'm not a huge fan of IP_FREEBIND because this sounds a lot like 'opt-in' behavior
[21:56] <teward> not 'should be default' behavior
[21:56] <sdeziel> teward: would make good, ExecStartPre lines
[21:56] <teward> HA isn't exactly a common setup.
[21:56] <lordcirth__> Ah, yeah I think normally I would want things to fail if I mess up their IP config, not silently do nothing
[21:56] <teward> sdeziel: example of such lines? so I can add examples
[21:56] <sdeziel> teward: sec
[22:00] <sdeziel> teward: https://paste.ubuntu.com/p/gvCcP7JxZY/
[22:00] <sdeziel> teward: as for nginx and IP_FREEBIND, I would have assume it was just another listen arg that needed to be added
[22:03] <teward> sdeziel: possibly.  I've opened a Trac ticket upstream, to get reasoning, but I'm pretty sure it's easier to, on an as-needed basis, set the proper sysctl rules on individual systems/servers rather than rely on NGINX implementing it
[22:04] <teward> that said, my focus recently has been work related things and working on my coredev application.
[22:11] <sdeziel> teward: good luck on that coredev application!
[22:11] <teward> it ain't filed yet :p
[22:11] <teward> (est. 3 weeks out at most from filing the application officially)
[23:00] <The_Actor> Guys, I am looking to find a good distro to build a webserver on, and due to recent privacy issues (Cannonical deciding to collect info and share with third parties without concent) have been hesitant to try Ubuntu. Are there such issues on the server products? Also does Ubuntu offer a Virtulization server, as in full-on web interface LXE/KVM management like Antsle and RedHat Virtulization
[23:00] <The_Actor> Server? Thanks
[23:03] <sdeziel> The_Actor: do you have pointers to info collection done without consent?
[23:05] <mason> The_Actor: I think that's largely historical.
[23:06] <mason> sdeziel: I suspect he means the Amazon search results from 14.04.
[23:06] <mason> Or... whatever version it was.
[23:06] <sdeziel> so much for recent
[23:06] <mason> I'm just guessing.
[23:07] <Gerowen> Which wasn't "collecting information" even then, it just forwarded search results to Amazon and displayed relevant results in the Unity menu, and had an option to be disabled.
[23:07] <Gerowen> I mean it forwarded search "queries" to Amazon
[23:08] <The_Actor> sdeziel: I dont understand the question "do you have pointers to info collection done without consent?"
[23:08] <mason> The_Actor: He was confused because the issue is somewhat historical at this point.
[23:08] <sdeziel> The_Actor: which privacy issues are your referring to?
[23:09] <Ussat> Dude, internet.......basically toss privacy out the window
[23:10] <mason> And then there's stuff like popcon.
[23:11] <The_Actor> I recently saw a video on YouTube by somone reviewing Ubuntu, he stated that desktop search results and part of the index are sent to Canonical. A later video I saw Richard Stallman making noise that Ubuntu is sharing this with third parties . . .
[23:12] <sdeziel> The_Actor: OK so that confirms what mason was saying, that's old, not really controversial (if you ask me) and desktop only
[23:12] <The_Actor> I see
[23:13] <sarnold> who knew that using the 'search amazon' feature would send search queries to amazon :)
[23:14] <The_Actor> So I am trying to decide between building an LXE Ununtu Server Image or an LXE SUSE image for a webserver platform. Is there anything that would give Ubuntu a clear advantage over SUSE?
[23:14] <sarnold> what a crazy time to be alive
[23:17] <The_Actor> Would there be any advantages to say managing Apache on Ububtu, or perhaps good security profiles?
[23:18] <sarnold> both ubuntu and opensuse have apparmor
[23:21] <The_Actor> No clear winner then?
[23:21] <sarnold> depends upon whether you prefer apt or zypper, deb or rpm, other packaged tools, etc.
[23:22] <The_Actor> I guess I would want whichever is cleaner and has less of a history of destroying a working system
[23:22] <sdeziel> The_Actor: best is probably to try both
[23:22] <The_Actor> maybe
[23:23] <sdeziel> cause clearly asking in here will come with a certain bias...
[23:23] <sarnold> from personal experience, I've had one reiserfs3 tree destroyed on suse, and one 16.04 -> 18.04 upgrade go poorly (but recoverable). advantage to ubuntu there. :)
[23:23] <tomreyn> ubuntu LTS may have a longer free support life.
[23:23] <tomreyn> *lifecycle
[23:24] <The_Actor> I just need something with a clear cut guide that sticks to the distros standards so I dont have large gaping security holes on a public facing test webserver
[23:25] <tomreyn> opensuse leap "is expected to be maintained for at least 36 months, until the next major version of Leap is available", ubuntu LTS releases get security + bug fixes for 5 years
[23:26] <The_Actor> Good point. Is Ubuntu LTS commonly used as a Webserver OS?
[23:26] <tomreyn> there are many web servers which run on ubuntu.
[23:28] <The_Actor> Interesting . . . Do you know of any web hosting business who use Ubuntu LTS?
[23:28] <The_Actor> I thought it was mostly a RedHat, SUSE, and CloudLinux
[23:29] <sarnold> the last numbers I've seen suggested roughly 60% of the workload on the major cloud platforms is ubuntu
[23:29] <The_Actor> wow
[23:29] <sarnold> millions of ubuntu machines come and go every day
[23:30] <sarnold> red hat certainly owns US federal contracting
[23:30] <sarnold> suse does great in europe
[23:31] <The_Actor> Are there any specific management tools that make Ubuntu diffrent?
[23:32] <mason> Red Hat is in a lot of the infrastructure. Then you can run anything atop it, and that tends to include a lot of Ubuntu.
[23:32] <mason> As I understand it.
[23:32] <The_Actor> I see
[23:32] <sarnold> maas is great for managing fleets of bare boxes; juju for orchestrating workloads on various clouds; landscape for per-server views; lxd for container-based hypervisor kinds of things..
[23:33] <sarnold> of course you can probably run lxd on rhel or sles too; I'm less sure about juju and maas
[23:33] <The_Actor> Is there a Web Based LXD / KVM management system?
[23:33] <mason> I haven't heard of Juju before. Is it equivalent to OpenShift?
[23:33] <sarnold> mason: give me a second to learn about openshift :)
[23:33] <mason> Ah, it is.
[23:33] <mason> sarnold: Both Kubernetes.
[23:34] <sarnold> mason: juju's not specific to kubernetes.. or at least it wasn't last time I used it :) heh
[23:34] <sarnold> mason: cool, thanks
[23:34] <mason> Ah, I'll have to learn more then. New to me.
[23:35] <sarnold> mason: we'll use juju twice on a single cloud, even :) once with maas as the provider, to stand up the openstack cluster, and then again using openstack as the provider, to run the workloads on the cloud :)
[23:36] <mason> Ah, cool.