[06:16] <lordievader> Good morning
[07:44] <seven-eleven> why does the SSH host key change if I restart cloud init?
[07:47] <lordievader> Probably to prevent many hosts from having the same host-key.
[07:52] <seven-eleven> why not create a unique instance and have persistent host keys for the instance on reboot
[07:58] <seven-eleven> if you create an instance you can give it persistent host keys until it is destroyed; is it not a security risk to have changed host keys all the time, now you can't know if it's a MITM or still the first host you connected to
[08:00] <seven-eleven> cloud init should simply check if the host keys are present already and if the host keys are using the same encryption as specified in cloud init
[08:02] <seven-eleven> i rechecked, on reboot the host keys are persistent, only if you delete the instance it's not
[08:02] <seven-eleven> thats fine :)
[08:33] <mwhudson> seven-eleven: cloud-init has a bunch of per-instance things and a bunch of per-boot things
[08:33] <mwhudson> i'd assyme ssh host keys are per-instance but i haven't checked...
[08:54] <seven-eleven> mhm
[08:54] <seven-eleven> can I write a cloud init configuration like in example B or does only example A work? http://dpaste.com/32ZTZ1Q
[08:55] <seven-eleven> I'm not sure if I can split up the dictionary in two parts
[09:12] <seven-eleven> i created a sha-512 password with this command https://unix.stackexchange.com/a/260195 and added the hash to cloud init's user: passwd directive. when the instance is started the password is not accepted. http://dpaste.com/015W9V2
[09:50] <seven-eleven> no matter what I the password is not picked up by cloud init, i did it the same way as in these examples https://cloudinit.readthedocs.io/en/latest/topics/examples.html
[09:50] <seven-eleven> +try
[13:03] <cpaelzer> rafaeldtinoco: rbasak: wooooot I think I cracked ufw/iptables for mysql8
[13:03] <cpaelzer> the reason it only triggers from autopkgtest's build-needed is the way users are set up for the build
[13:03] <cpaelzer> fix is available and currenlty running tests
[13:04] <cpaelzer> and this was a real issue that would have got into eoan, so the UFW test did well
[13:09] <cpaelzer> rbasak: if you maybe could take a look at https://code.launchpad.net/~paelzer/ubuntu/+source/iptables/+git/iptables/+merge/371575 ?
[13:10] <lopta> When I try to install 19.04 in a VM that I made for it, I get "An error occurred during installation".  I'm going to see whether I find find out more in the full log...
[13:11] <lopta> Looks as though "Some index files failed to download".
[13:12] <cpaelzer> lopta: is the error reproducible?
[13:12] <cpaelzer> or could it be a one off network issue that made e.g. apt fail?
[13:12] <lopta> cpaelzer: For me, yes.  This is my second attempt.
[13:12] <lopta> (in two days)
[13:12]  * cpaelzer is installing from iso ...
[13:13]  * lopta nods
[13:13] <cpaelzer> lopta: which one do you use http://releases.ubuntu.com/19.04/ubuntu-19.04-live-server-amd64.iso ?
[13:13]  * lopta nods
[13:17]  * lopta has another go, this time opting not to update the installer.
[13:21] <lopta> No. Same thing.  18.04.3 installed without errors but that doesn't have the version of mono-complete that my application software seems to need.
[13:21] <lopta> I wonder whether I can install 18.04.3 and the somehow update to 19.04
[13:28] <cpaelzer> lopta: anything special on install?
[13:28] <cpaelzer> or jsut enter/enter/...
[13:29] <lopta> Enter... Enter, mostly.  Is 32G enough disk space?
[13:29] <cpaelzer> I have 5G
[13:29] <cpaelzer> update of new installer worked ... going on
[13:31] <lopta> I wonder whether our network is blocking something that 19.04 needs that 18.04 didn't.
[13:31] <cpaelzer> install is running, I see various curin info steps
[13:31] <cpaelzer> at which step did yours fail lopta ?
[13:35] <cpaelzer> lopta: mine seems mostly complete already, it is at "downloading and installing security updates"
[13:39] <cpaelzer> lopta: installed just fine for me
[13:46] <lopta> cpaelzer: I wiped the VM.  Let me try it again...
[13:47] <cpaelzer> ahasenack: rbasak: kanashiro: ahve you seen builds complete but not end recently?
[13:47] <cpaelzer> I have a PPA which took linger tan expected and they seem complete but staying in building state
[13:48] <cpaelzer> e.g. https://launchpad.net/~paelzer/+archive/ubuntu/bug-1840872-duplicatehotplug-1840745-amdssbd/+build/17449039
[13:48] <ubottu> Error: launchpad bug 17449039 not found
[13:48] <ahasenack> cpaelzer: I have not seen that
[13:48] <cpaelzer> I'll give it another 15 minutes, but then cancel and restart them
[13:48]  * cpaelzer doesn't want to waste resources
[13:49] <cpaelzer> maybe asking the LP team if they know why the completion isn't picked up
[13:54] <ahasenack> ufw failed to build, did you kill it?
[13:55] <cpaelzer> in the bileto ticket?
[13:55] <cpaelzer> no I just did a no change rebuild to enforce the tests agin
[13:55] <cpaelzer> ahasenack: ^^
[13:55] <ahasenack> bileto, yes
[13:55] <cpaelzer> ah
[13:55] <ahasenack> got an email
[13:56] <cpaelzer> yeah I still have some dbeug on it which makes no sense
[13:56] <ahasenack> like I do for every single bileto ticket
[13:56] <cpaelzer> will resolve it
[13:57] <cpaelzer> my inbox is useless until I get som eauto-sorting onto the "stuck in proposed mails"
[13:57] <cpaelzer> truns out transitions are so noisy in your inbox you don't see anything else
[13:57] <rbasak> I've been considering /dev/null'ing them
[13:57] <rbasak> It's be nice to set an expiry on a procmail rule. I guess I can arrange that but I'm not sure of a recipe.
[13:58] <rbasak> I'd have test it etc.
[13:59] <teward> rbasak: i just shunt half the emails i receive for things that dont' concern me to a junk mailbox xD
[13:59] <teward> rewrite:destination at my mail gateway, it goes to a different account :P
[13:59] <rbasak> I have a mailbox called "notme" for that.
[14:00] <teward> ... unlike tsimonq2 who lets all his messages through and doesn't delete/cleanup them and has an inbox the size of Texas right now
[14:00]  * teward runs tsimonq2's email for them, hence how he knows this
[14:00] <rbasak> =INBOX [Msgs:49434 Flag:1001 Post:6 804M] :-/
[14:01] <teward> Simon's up to 1.1GB right now, at least when you factor in the indexes, etc.
[14:01] <teward> and that's just their ubuntu-changes folder :P
[14:02] <teward> but meh
[14:02]  * teward goes to dig into why Xenial doesn't like latest NGINX builds for some reason
[14:03]  * lopta wipes his virtual disk again
[14:10]  * lopta has another go at installing Ubuntu Server 19.04
[14:11] <lopta> Wish me luck!
=== Napsterbater is now known as Guest93798
=== Napsterbater_ is now known as Napsterbater
[14:16] <lopta> cpaelzer: The first package that failed to fetch was Commands-amd64
[14:16] <lopta> "lzma_read: Read error (5)
[14:16] <lopta> "
=== logan_ is now known as logan-
[14:19] <lopta> Final line says "finish: cmd-install/stage-curthooks/001-configure-apt/cmd-in-target: FAIL: curtin command in-target
[14:19] <lopta> Stderr: ''
[14:21] <lopta> I was really hoping to use Ubuntu Server for this job.
[14:25] <cpaelzer> lopta: atm I can only say that it worked for me and that I don't see an obvious item to attack with the error messages
[14:25] <cpaelzer> Odd_Bloke: ^^ do these messages mean something to you from a curtin POV ?
[14:26] <lopta> Is there a command to upgrade from 1804 to 1904?
[14:26] <cpaelzer> yeah
[14:26] <cpaelzer> let me fetch a good link
[14:26] <cpaelzer> unfortunately askubuntu has maintenance atm :-)
[14:27] <Odd_Bloke> That doesn't ring any bells, but I'm not hugely experienced with curtin yet.
[14:27] <cpaelzer> lopta: https://help.ubuntu.com/lts/serverguide/installing-upgrading.html maybe as a start
[14:27] <Odd_Bloke> mwhudson or rharper may be able to help more.
[14:27] <cpaelzer> lopta: since 18.04 is a LTS it won't prompt you to upgrade until 20.04 is released
[14:27] <cpaelzer> but you can change the config to do it
[14:28] <cpaelzer> sudo do-release-upgrade -d
[14:28] <cpaelzer> whic hwill tell you to edit /etc/update-manager/release-upgrades
[14:29] <rharper> Odd_Bloke: lopta it looks to me like an apt update failed, network connection or sometimes the archive isnt available; we see transient failures during apt installs on our nightly testing some times;
[14:30] <cpaelzer> -d is for devel relase, which in your case you done't need/want
[14:30] <rharper> lopta: does it fail the same way each time ?
[14:30] <lopta> rharper: Ye
[14:30] <lopta> s
[14:31] <lopta> "Upgrades to the development release are only available from the latests supported release"
[14:31] <rharper> and you know networking on the device works ?
[14:31] <lopta> Ah, thanks
[14:31] <cpaelzer> lopta: you don't want/need -d
[14:31] <lopta> rharper: yes
[14:33] <lopta> Looks like it's getting Disco Dingo...
[14:33] <cpaelzer> which is 19.04
[14:33] <rharper> it sure looks like a networking issue;  you could try offline install, https://bugs.launchpad.net/subiquity/+bug/1750819 ; http://cdimage.ubuntu.com/ubuntu-server/bionic/daily-live/20190801/
[14:33]  * lopta nods
[14:38] <lopta> Well, let's see whether this upgrade process works.
[14:43] <lopta> Nope.  Kernel panicced on reboot.
[14:44] <lopta> "...not syncing: No working init found"...
[14:49]  * lopta resorts to a desktop install...
[14:54] <lopta> Well that's unfortunate.  My mouse isn't working.
[14:55] <lopta> ...and I can't seem to tab around.
[14:55] <lopta> Suppose that's an issue for another channel though.
[15:25] <lopta> Let's try 1904 on bare metal.
[15:35] <runelind_q> my landscape on-premise installation hasn't run update_security_db.sh in a week :(
[15:35] <runelind_q> when I try to manually run the script, it just stops with exit 1
[15:39] <runelind_q> hrm, it may be getting somewhere after the umpteenth restart ;p
[15:51] <runelind_q> heh yep, it works now
[15:51] <runelind_q> you may go about your business.  Move along, move along.
[16:10] <lopta> Interestingly (to me) 1904 installed nicely onto bare metal.
[16:10] <lopta> ...not sure what's up with my VM
[16:15] <lopta> Alright. It's lunchtime.
[16:25] <runelind_q> so I kinda screwed up when I installed this server, creating an mdadm mirror on a pair of 8GB sata DOMs for the OS install.  Predictably, space is getting pretty tight.  What's the best way to get bigger disks in there without reinstalling?  Clonezilla?
[16:44] <ahasenack> add more disks, raid1 them too, and mount /usr on them?
[16:44] <ahasenack> or whatever is your biggest space consumer
[16:44] <ahasenack> is this a vm?
[16:46] <runelind_q> no, physical server
[16:47] <ahasenack> was just curious about the small disk
[16:47] <runelind_q> I had some sata DOMs that I thought would be cool to use.
[16:47] <runelind_q> but they're too small.
[18:18] <lopta> \o/
[18:24] <lordcirth> runelind_q, perhaps you could break the mirror, replace the other drive, rebuild, replace the first one, and expand?
[18:33] <runelind_q> that is an option, yeah.
[18:39] <leftyfb> I'm trying to pivot_root on ubuntu 16.04. I only have systemd and dbus-daemon left and can't seem to restart either of them to get them onto the new root. systemctl daemon-reexec doesn't seem to do anything for systemd. Any signals I give to the dbus PID seem to just kill the machine completely. Any ideas?
[18:44] <leftyfb> actually, I was able to kill and restart the systemd service. So now it's only dbus I'm trying to get off of the /oldroot
[18:49] <runelind_q> I don't believe the sata DOMs have serial numbers written on them, so I'll have a 50/50 chance of picking the right one when I fail/replace it.
[19:06] <lopta> Apparently our application is up and running on Ubuntu Server 1904.  I'm impressed at how smoothly the installation goes on bare metal.
[19:23] <lopta> brb, coffee++
[21:03] <mwhudson> lopta: did you figure out what was going on in the vm?
[21:03] <mwhudson> lopta: i'm glad it worked on bare metal :)
[21:04] <lopta> mwhudson: I'm not sure exactly.  This'll do until I leave and someone accidentally switches it off. ;-)
[21:04] <lopta> "Hey, why'd all our telemetry stop?!"
[21:05] <mwhudson> haha
[21:05] <mwhudson> "we've all ready the google sre manual, that's good enough right?"
[21:16] <lopta> Well originally I asked for a VM on the ESXi cluster but the IT manager got very angry at the suggestion so I just told him "Don't worry about it. I'll take care of it myself".
[21:17] <lopta> (and BCCd his temporary boss)
[21:27] <lopta> Does (can) Ubuntu Server put the screen to sleep after a set period of no keyboard activity?
[21:28] <compdoc> I think it does
[21:30] <lopta> Thanks.
[21:30] <lopta> We'll see what it does overnight.
[21:30] <lopta> By!
[21:30] <lopta> e*
[22:29] <V7> Hey all
[22:30] <V7> Postfix shows in syslog:  warning: connect to Milter service unix:/var/run/opendkim/opendkim.sock: No such file or directory
[22:30] <V7> Already did https://unix.stackexchange.com/a/74491/133353
[22:31] <V7> What could this be?
[22:33] <V7> Figured out
[22:33] <V7> In main.cf changed unix:/var/run/opendkim/opendkim.sock to unix:var/run/opendkim/opendkim.sock