=== svetlana is now known as Sveta
=== gnomethrower is now known as Wings
=== Wings is now known as wings
[08:27] <majom> Hi, I have set up googe authenticator authentication for ssh following this guide: https://www.digitalocean.com/community/tutorials/how-to-set-up-multi-factor-authentication-for-ssh-on-ubuntu-16-04. The problem is that according to the logs the google authentication is passes but I still receive a seond prompt to enter my verification code. My logs, configuration and outputs are pasted here: https://paste.ubuntu.com/p/yQZs2XDzn9/
[09:27] <aneon> hi, is there any option for encrypted LVM setup in 18.04 install media?
[09:28] <majom> aneon, you can choose the encryption method at install time
[09:29] <aneon> couldnt find it
[09:30] <majom> it's there
[09:30] <aneon> under which menu?
[09:31] <blackflow> I'm not sure the new subiquity has support for that yet, iirc you'd have to use the old installer
[09:32] <aneon> I wont mind old release, I can always do dist-upgrade
[09:33] <aneon> the install is failing due to hash mismatch, I tried 6 different mirrors
[09:34] <blackflow> it's not old release, but the old installer. there's separate ISOs for that. I think it's called the "Alternative installer" here:  https://www.ubuntu.com/download/alternative-downloads#alternate-ubuntu-server-installer
[09:34] <aneon> okay I will get that one then
[09:35] <blackflow> infact, that installer is the mature one. the new subiquity, that for some reason is now defaulted to, is still in need of baking to completion.
[09:38] <aneon> the new thing is horrible
[09:40] <aneon> I am getting the alternative installer media
[09:40] <aneon> blackflow: Is there any other install media that has all packages bundled in it?
[09:55] <lotuspsychje> aneon: feel free to join #ubuntu-discuss
[09:56] <aneon> some other time
[10:42] <lordievader> The new installer is quite incomplete. I rember I wanted to reuse an existing LVM setup on a host. All the installer could offer me was to create a brand new LVM setup.
[10:50] <aneon> dunno why they push beta stuff in release
[12:51] <weedmic> anyone familiar with urwid?  it's a way to make tui (instead of gui) interfaces?
[12:54] <lucido> Hi, anyone here familiar with PAM and google authenticator?
[13:03] <chl_> is anyone using the 'x'-option in tftpd.remap files on 18.04?
[13:40] <rbasak> weedmic, lucido, chl_: I suggest you just ask your respective questions. People tend not to volunteer themselves for unknown discussions.
[13:50] <teward> lucido: i know a little bit, but i'll need more details on your *question* specifically to help.  as rbasak said, you should ask your ACTUAL question otherwise we don't usually volunteer for 'unknown' discussions
[13:52] <virole_bridee> Hello.
[13:53] <virole_bridee> I have almost no knowledge of Ubuntu Server, and I'm in charge of configuring a new VM that was provided to me.
[13:54] <virole_bridee> The guys who created the VM used a 18.04 LTS iso, and I played the installation.
[13:55] <teward> > I'm in charge of configuring a new VM that was provided to me. < if you don't have knowledge to do the configuration, then why did they give you the task heh
[13:55] <teward> (just saying)
[13:56] <virole_bridee> -init
[13:57] <virole_bridee> Is Ubuntu server necessarily including cloud-init, or are there iso images without it ?
[13:58] <teward> virole_bridee: it's included unfortunately in the Subiqutiy based ISOs.  Alternate ISO or mini.iso won't have it, but you can use Cloud-Init to *start* config and install, then remove cloud-init afterwards
[13:58] <virole_bridee> as concerns the why : I'm the only Linux guy here, and Ubuntu was forced to us by the final software provider, hence the job for me.
[13:58] <teward> which is actually what I do with all my VM(s) deployed from the ISO.
[13:58] <teward> cloud-init makes for fast setup and such, but it's lousy after the fact.
[13:58] <virole_bridee> OK, thanks.
[13:58] <teward> (in standard VM installs anyways)
[13:59] <virole_bridee> But it seems to me that removing cloud-init isn't simply done by removing the pakage, right?
[13:59] <teward> just `sudo apt remove cloud-init`.  It'll remove the underlying service.
[13:59] <teward> and then not run anymore.
[13:59] <teward> unless you mean something else by 'remove'
[14:00] <virole_bridee> Oh, cool. Thanks a lot .Taht's exactly what I was expecting.
[14:00] <teward> and yes, just simply removing the package and then doing `sudo apt autoremove` will clean up deps.
[14:00] <virole_bridee> some formue
[14:00] <teward> it may leave some configuration files behind but they don't do anything with the service removed.
[14:00] <virole_bridee> I'll do that
[14:00] <virole_bridee> Thanks again, you saved my day.
[14:04] <rbasak> teward: I'm curious: how does cloud-init get in the way for you after an instance deployment?
[14:05] <teward> rbasak: known issues with hostname not changing, resetting network configs, etc. after the fact.
[14:05] <teward> "fixed" but not in 18.04.2 ISOs
[14:06] <teward> at least, fixed *supposedly* from what i've heard
[14:06] <teward> rbasak: it also irritates the **** out of mee for other reasons, so in *my* case I just purged it from the VM template I use.
[14:06] <teward> (since i have a VMware cluster I created a template VM that I just clone now :P)
[14:07] <rbasak> teward: but part of the point is that if cloud-init remains, appropriate actions after VM image cloning are automatically taken :)
[14:07] <rbasak> teward: are hostname not changing/resetting network configs bugs or just unfortunate defaults for your particular case? Or do you think the defaults are wrong?
[14:09] <teward> rbasak: different issue
[14:10] <teward> rbasak: the 'defaults' being wrong have issues open
[14:10] <teward> there's a current bug in cloud-init where SOMETIMES even if you tell it to not preserve the hostnaame (so you can change hostname on the boxes) it actually *ignores* that setting and  keeps resetting hostnames back
[14:10] <teward> EVEN IF everything is set to permit hostname changes
[14:10] <teward> rbasak: don't get me wrong, I *like* cloud-init
[14:11] <teward> but if it's going to be broken when I set it to allow hostname changes and IGNORE that setting... it's on my 'purge after install' list
[14:11] <teward> until THAT is fixed...
[14:11] <teward> (this bug has been reported also)
[14:12] <teward> rbasak: and I've confirmed it in about 20% of my VM deployments personally and at work.  The only workaround temporarily was remove cloud-init
=== cshep is now known as platonical
[14:19] <rbasak> teward: bug link please?
[14:20] <teward> rbasak: gotta dig for it, hang on
[14:20] <rbasak> teward: no rush. I'm just curious to track these things :)
[14:22] <teward> rbasak: the problem is it's not reproducible all the time
[14:22] <teward> it's 'hit or miss' so :/
[14:22] <teward> not sure if the bug has been closed or not already
[14:22] <teward> ... fooey and I have a meeting i have to jump into
[14:24] <teward> rbasak: I can't find the bug, it may've been closed upstream, but it's a known 'issue' that i've run into multiple times.  Might just write a new bug and let someone dupe it to a preexisting bug if there is one
[14:24] <teward> ... after this meeting./
[14:25] <virole_bridee> teward: sory for my late answer. 'how does cloud-init get in the way for you after an instance deployment?' : while learning how to configure networking, I arrived at a file under /etc/netplan/ mentionning this cloud-init,
[14:25] <teward> virole_bridee: oh, *that* will still exist.
[14:25] <virole_bridee> and warning me that all modificaitons would be scratched after reoot.
[14:25] <teward> but you can edit that freely
[14:25] <teward> and those changes'll stick
[14:25] <teward> those only get overwritten when, say, OpenStack or something deploys it
[14:26] <virole_bridee> OK. Anyway, I removed this cloud thing, which I do not want at any price on a production server.
[14:27] <virole_bridee> NTW, I know quite well Debian/RedHat/CentOS/OpenBSD, I'll have to learn this Ubuntu animal *^v^*
[14:27] <rbasak> virole_bridee: most distributions use cloud-init for their cloud images :)
[14:28] <rbasak> If you're a professional it's probably worth learning how cloud images work.
[14:28] <rbasak> They are very widely used.
[14:28] <virole_bridee> Problably, but no cloud here. Purely internal servers.
[14:29] <virole_bridee> Also, 'most distributions use cloud-init for their cloud images' : but I don't need a cloud image.
[14:29] <rbasak> They are still relevant for internal-only use.
[14:31] <virole_bridee> OK, thanks, I'll try to get informed about it.
[14:34] <weedmic> I get "python3 is already the newest version (3.5.1-3)" when trying to install/upgrade to 3.6.7 on 4.4.0-1083-aws (ubuntu) - does that make sense/is it telling the truth?
[14:36] <rbasak> weedmic: which Ubuntu release?
[14:36] <weedmic> Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-1083-aws x86_64)
[14:36] <teward> that's correct for 16.04
[14:37] <teward> weedmic: if you intend to install OTHER python versions beware you might torch your system if you're not careful
[14:37] <weedmic> What badness happens if I force it to go to 3.6.7?
[14:37] <weedmic> ok, that sounds bad - python is intermixed with the kernel?  it's not outside of it and called?
[14:37] <teward> it could break anything depending on Py3.5 stuff.  If you need 3.6.7 for dev environments I suggest you look into pyenv so you can have 'userspace' installs of 3.6.7 that wont' affect the system packages
[14:37] <teward> weedmic: its' not necessarily the *kernel* more like a ton of system utilities and scripts that keep things working
[14:38] <teward> (note that pyenv isn't supported in here, but it's my suggestoin)
[14:38] <rbasak> weedmic: you might consider upgrading to 18.04.
[14:38] <weedmic> can that be done from the kommand line?
[14:39] <rbasak> I think most AWS users would expect to deploy a new instance with 18.04 to do what they want.
[14:39] <weedmic> i c - i shall resistance meet, but will bring it up.
[14:39] <teward> weedmic: i'd back up your stuff first if you want to do an in-place upgrade, but you might do ^ that, deploy a new 18.04, transfer data between old -> new, get things working, decommission old.
[14:40] <weedmic> not worried about data - worried about lots of docker containers working and setting up all the face nics and things, but I can script it.
[14:44] <rbasak> worried about lots of docker containers working> seems ironic. Isn't not having to worry the entire point of using Docker in the first place?
[14:45] <weedmic> all the servers are 18.0x.x except for one - hmmm...
[14:47] <weedmic> they talk to eachother and if we leave one link out, poof - hours of work figuring it out.  it was assembled by programmers.  if "I" did it it would be a script - that is the same each time it is run.
[17:34] <ahasenack> rbasak: found this answer for my "what provides <foo>?" question from earlyer
[17:34] <ahasenack> aptitude search '~Pdefault-mta'
[17:41] <rbasak> ahasenack: nice, good to know thanks