[08:02] <Zahovay> I just saw that after i upgraded my server through ssh i still have 2.6 kernel. Is it possible to update the kernel through ssh ?
[08:11] <blackflow> Zahovay: what's the output of   uname -a   ?
[08:12] <Zahovay> 2.6.32
[08:12] <blackflow> that's not output of uname -a
[08:12] <Zahovay> 2.6.32-042stab130.1 #1 SMP Tue May 22 09:19:34 MSK 2018 x86_64 x86_64 x86_64 GNU/Linux
[08:13] <blackflow> Zahovay: is that OpenVZ VPS? if yes, then no, you can't touch the kernel. I'd leave that hoster before I could finish this sentence.
[08:17] <Zahovay> Not quite sure about it. The tarhely(dot)eu does provide openVZ vps, could be
[08:17] <blackflow> that 'stab' kernel is OpenVZ signature
[08:19] <Zahovay> lol
[08:19] <Zahovay> your knowledge is amazing (to me atleast)
[08:21] <Zahovay> do you suggest any "cheap" but not horrible provider?
[08:22] <blackflow> in EU I'd recommend Hetzner. Digital Ocean is otherwise not too bad.
[08:25] <Zahovay> Thanks for your advice, hetzner is a bit messy to me but digital ocean looks good
[08:27] <blackflow> messy how?
[08:29] <Zahovay> most of the time I find vps server on the site and its clear what it is. On hetzner there are too much options I cant see vps keyword so I should read the whole site which one I m looking for
[08:29] <Zahovay> if it is at the managed server section it costs way too much
[08:29] <Zahovay> to us yet
[08:30] <blackflow> oh they call it Cloud now. but it's a regular VPS with some "cloudy" features like floating IP.
[08:30] <Zahovay> oh
[08:30] <blackflow> (and they separate storage from compute nodes, so that's another "cloudy" feature)
[08:35] <Zahovay> I've made pictures of these prices with a little description of why openvz s...ks, thanks for your help and suggestions
[08:35] <Zahovay> so back to server, I cant change kernel?
[08:36] <blackflow> no. that's not really a VM. openvz is a form of OS level "virtualization". a container on steroids if you will. not unlike LXC. so that's just an advanced namespace on the host, with all the limitations of it.
[08:38] <Zahovay> lol
[08:38] <Zahovay> you must be kidding me
[08:42] <Zahovay> blackflow: I am really thankful for your help, you saved me a few days of research and also helped me to get to the right direction. Thank you!
[08:42] <blackflow> you're welcome.
[08:43] <blackflow> Zahovay: btw, all this is on the assumption that it _is_ OpenVZ, based on that uname. Given what I've seen people do, it's not theoretically impossible this really is a VM, some franken something with gods know what kernel. :)
[08:44] <Zahovay> I asked the guy, he told me that yes it is openVZ
[08:44] <blackflow> mkay.
[08:45] <Zahovay> anyway I will use this server to host a webpage for now.. (without input field so only information could be read)
[12:12] <Ussat> Did the command to purge old kernels change ?
[12:13] <Ussat> sudo purge-old-kernels --keep  2 -qy is now throwing errors. : Command line option --keep is not understood in combination with the other options
[12:14] <Ussat> Dont remember seeing that before today, this is on 18.04
[12:15] <Ussat> seems to work fine on 16.04
[12:16] <Ussat> and works fine on 17.X
[12:21] <rbasak> Ussat: "sudo apt autoremove" (possibly with --purge) should be sufficient now.
[12:23] <Ussat> OK, but how does it know how many to keep ?
[12:25] <RoyK> Ussat: https://help.ubuntu.com/community/RemoveOldKernels perhaps
[12:27] <Ussat> the old purge-old-kernels -y --keep 2 was working fine , untill 18.04lts
[12:27] <ogra_> Ussat, autoremove will never remove the currently running kernel and the one the linux-generic package depends on
[12:28] <rbasak> Ussat: the logic is in /etc/kernel/postinst.d/apt-auto-removal
[12:28] <rbasak> I'm not sure you can tweak the set of kept kernels any more. But enhancing that with options is a reasonable feature request I think.
[12:30] <rbasak> Some details at bug 1686138
[12:30] <Ussat> OK, so safe to assume then that sudo apt autoremove --purge will keep a "extra" kernel to boot from in case of oh shit
[12:30] <Ussat> OK, ya
[12:30] <rbasak> Ussat: that's the idea, yes. If it doesn't work for you, please tell us :)
[12:31] <Ussat> :) count on it.....running it on my test system now :)
[12:34] <Ussat> sudo apt-get -y autoremove --purge be viable for 16.04 and 17.X also ?
[12:35] <rbasak> I think it works on 16.04 too.
[12:35] <rbasak> It's been around for a while.
[12:36] <rbasak> Since apt 0.9.9.1 according to https://git.launchpad.net/ubuntu/+source/apt/log/debian/apt.auto-removal.sh
[12:37] <rbasak> That includes Trusty
[12:37] <rbasak> So it might also work on 14.04 unless there are other moving parts I've not accounted for.
[12:37] <Ussat> ok, will see. I understand the reasoning, but I like to keep 1 running, a "gneric" and my last known good or N, n-1 and a generic
[12:37] <ogra_> definitely works on 16.04, i use it regulary on all my classic deb based installs
[12:38] <rbasak> Ussat: I think if you want to keep extra ones present, you can mark them as manually installed using apt-mark. Then apt won't suggest removing them.
[12:38] <Ussat> which is what sudo purge-old-kernels -y --keep 2 allowed
[12:39] <Ussat> rbasak, sure, but I need to do that every time a new kernel is installed. with sudo purge-old-kernels -y --keep 2 it always kept N, N-1 and the generic
[12:39] <rbasak> Ussat: or tweak the script in /etc. It should be preserved on package upgrades (since it's in /etc).
[12:39] <rbasak> Ussat: /etc/kernel/postinst.d/ scripts run every time a new kernel is installed :)
[12:40] <Ussat> OK, but I guess I dont understand the reasoning not allowing to flag how many to keep ?
[12:40] <ogra_> you dont need to re-set the apt-mark mark if noew kernels are installed ... that is persistent
[12:40] <ogra_> *new
[12:40] <rbasak> ogra_: only on the metapackages presumably though?
[12:41] <ogra_> it should work on the -image packages too ... autoremove ignores manually installed packages
[12:41] <rbasak> Ussat: I think it'd be perfectly reasonable to add a feature to /etc/kernel/postinst.d/apt-auto-removal to support configurability of how many kernels to keep.
[12:41] <Ussat> How would I request that ?
[12:41] <rbasak> Ussat: the only difficulty is in implementation since ideally it'd be stateless, and "how many to keep" is difficult to define (in terms of order of installs, or order of versions, orders of boot, or what?)
[12:41] <ogra_> you could go a step further and make that an auto-setting feature that simply sets it self up based on available space in boot ;)
[12:42] <rbasak> Ussat: file a wishlist bug against apt please, noting apt-auto-removal in the subject.
[12:42] <ogra_> tiny /boot -> keep two ... large /boot automatically keep a few more
[12:42] <rbasak> (since the apt package ships that script)
[12:42] <Ussat> ogra_, um.... not sure I would want that auto set, and if was be able to change it
[12:43] <rbasak> Ussat: if you can provide a patch for the script, even better :)
[12:43] <ogra_> (plus a manual override on top allowing you to set a fixed number)
[12:43] <Ussat> rbasak, will work on it in all my free time :)
[12:43] <Ussat> thanks
[12:44] <rbasak> No problem. Note that I'm not apt upstream and so I can't make the final decision. But if the patch is reasonable then I see no reason why it can't be done.
[12:44] <Ussat> noted, I appreciate the help on this...
[12:44]  * ogra_ hopes eventually we'll simply shop all kernels as snap packages ... that would solve the issue once and for all ;)
[12:44] <ogra_> *ship
[12:58] <rbasak> ahasenack: o/
[12:58] <ahasenack> hi rbasak
[12:58] <rbasak> ahasenack: I think Monday is cpaezler today, but since he's out, shall we bump to the next person (you)?
[12:58] <ahasenack> I'm fine with that
[12:58] <rbasak> Then he can do yours next week I guess.
[12:59] <rbasak> Thanks
[13:11] <ahasenack> hm, is it expected that subiquity only enables the main repo in the installed system?
[13:11] <ahasenack> no restricted, universe or multiverse
[13:11] <ahasenack> I don't recall if the old server install was also like this
[13:19] <rbasak> That doesn't sound right
[14:32] <coreycb> jamespage: for nova i don't think we can move all config to nova-common. there are all of the nova-compute-*.conf files for example.
[15:26] <Forty-3> how do I restart networking on 18.04?
[15:26] <Forty-3> I've looked through https://askubuntu.com/questions/230698/how-to-restart-the-networking-service but it doesn't seem to have anything past 16.04
[15:27] <Ussat> netplan
[15:27] <Ussat> sudo  systemctl restart NetworkManager.service
[15:28] <Forty-3> I'm on server, there is no NetworkManager
[15:28] <Ussat> or
[15:28] <Ussat> sudo service network-manager restart
[15:28] <Ussat> I am also on servers and that works
[15:28] <Forty-3> not for me :l
[15:28] <Forty-3> network-manager and NetworkManager are both not found
[15:28] <Forty-3> I really just need to get a new dhcp lease
[15:29] <Forty-3> I was hoping for something like `systemctl restart dhcpcd` like on other distros
[18:51] <tomreyn> are there changes in 18.04 server compared to 16.04 as to how ssh key authentication works? i just setup an amd64 server using the classic / alternative server installer and while password autherntication by ssh works fine, i can't seem to make pubkey authentication work, not with RSA keys, not with ed25519 keys.
[18:52] <sarnold> tomreyn: rsa keys have to be > 1024 bits, that seems to be the most common stumbling block
[18:55] <tomreyn> it's 2048
[18:56] <tomreyn> hmm there is a lot more commented out than in earlier versions apparently
[18:57] <teward> 18.04 the commented out sections are because those are now the 'defaults'
[18:57] <teward> if you want to be sure though uncomment SSHKeyAuthentication and set it to "yes", then restart the SSH process, to make sure it accepts pubkey auth as a valid method
[18:58] <tomreyn> http://paste.ubuntu.com/p/3PhWxDM9p8/ is what i have after enabling and also changing a little
[18:59] <tomreyn> E486: Pattern not found: SSHKeyAuthentication                                                                                                                       20,19         Top
[18:59] <teward> hang on I forget the specific argument 1 moment
[18:59] <tomreyn> ignore the 2nd line please
[18:59] <tomreyn> PubKeyAuthentication is yes
[19:04] <teward> tomreyn: did you put the public key of your SSH key into the ~/.ssh/authorized_keys file for the user in question?
[19:04] <teward> (if the user was foobarbaz, that'd be /home/foobarbaz/.ssh/authorized_keys, if it's root it's /root/.ssh/authorized_keys)
[19:07] <tomreyn> yes i did. i dont know what i changed, but it works now.
[19:08] <tomreyn> actually i know what i changed. i uncommented these lines
[19:08] <tomreyn> #HostKey /etc/ssh/ssh_host_rsa_key
[19:08] <tomreyn> #HostKey /etc/ssh/ssh_host_ecdsa_key
[19:08] <tomreyn> #HostKey /etc/ssh/ssh_host_ed25519_key
[19:08] <tomreyn> restarted sshd, could log in
[19:08] <tomreyn> then commented the lines again, restarted sshd, could still log in
[19:08] <tomreyn> my guess is the ssh host keys were not created initially
[19:10] <tomreyn> hmm no, the timestamps on them are old.
[19:10] <tomreyn> okay, i'm clueless. thanks for helping me out, though.
[19:10] <dlloyd> whats in /var/log/auth.log for the failed login?
[19:16] <tomreyn> error: maximum authentication attempts exceeded for root from 123.123.123.123 port 12345 ssh2 [preauth]
[19:16] <tomreyn> Disconnecting authenticating user root 123.123.123.123 port 12345: Too many authentication failures [preauth]
[19:17] <tomreyn> just those lines. i still get those when trying to do pubkey auth against root using an ed25519 key
[19:17] <tomreyn> rsa works
[19:22] <ahasenack> does anybody have an example (package, project, etc) that uses libapache2-mod-perl2?
[19:22] <ahasenack> I'm trying to verify https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-perl2/+bug/1779400 so make sure the rebuild didn't introduce some unknown breakage
[19:23] <ahasenack> I'm going over apt-cache rdepends libapache2-mod-perl2, but so far I couldn't get anything useful
[19:23] <ahasenack> webgui doesn't work (that's a package)
[19:23] <ahasenack> nor does octopussy
[19:29]  * ahasenack tries otrs2