[01:21] <Maxel> so I have a raid card that allows me to mount a volume in ubuntu server 16.04, when I upgraded to 18.04 I was unable to mount that volume
[01:22] <Maxel> I don't remember how I mounted the volume initially, but I'd like to have the same volume with the same data in the upgraded ubuntu version
[01:30] <sarnold> what error did you get?
[01:37] <Maxels> good question, I'll load up my snapshot and see
[01:40] <Maxels> so when booting, I get a failure on "failed to mount [volume]"
[01:40] <Maxels> and then I am presented with warning I am in emergency mode
[01:41] <Maxels> and I can also check the log for the mounting process that failed
[01:43] <Maxels> mount: [volume]: wrong fs type, bad option, bad superbloc
[01:43] <Maxels> if I revert to the old snapshot on 16.04 it works fine though
[01:45] <sarnold> what filesystem type is it? does fstab just leave it auto or does it specify?
[01:46] <Maxels> I'm trying to remember, I can switch to the other snapshot but I think it was xfs
[01:46] <Maxels> I don't remember how to use fstab from when I set this up
[01:48] <Maxels> I appreciate your help btw :)
[01:51] <Maxels> does 18.04 just not support xfs or something?
[01:53] <sarnold> at least on the kernel my laptop is running it required loading a module
[01:53] <sarnold> cat /proc/filesystems | grep xfs
[01:53] <sarnold> 	xfs
[01:53] <sarnold> that's after sudo modprobe xfs
[01:54] <sarnold> (please forgive the abuse of cat, I ran cat /proc/filesystems first just to see what it supported; I hadn't looked in ages :)
[01:56] <Maxels> hmmmm, I'm trying to unpack what you're saying
[01:56] <Maxels> did the cat search supported filesystems?
[01:59] <Maxels> and is loading the module to support xfs as simple as an apt-get add?
[02:03] <sarnold> it should just be sudo modprobe xfs
[02:03] <sarnold> if that doesn't load it, then yeah, an apt-get install will be required :)
[02:04] <Maxels> I'm not sure what modprobe normally would do, but it didn't print anything on that command
[02:04] <sarnold> /proc/filesystems shows the filesystems that the kernel currently knows how to mount -- others may require loading modules, as it did for me to load xfs
[02:04] <sarnold> usual unix rules, it shuoldn't print anything if it succeeds :)
[02:05] <Maxels> hmm, ran modprobe, still failing the mounting
[02:05] <Maxels> and then starting in emegency mode, although I don't know what emergency mode does
[02:05] <sarnold> modprobe only affects the current boot
[02:05] <sarnold> if you've rebooted then it's unloaded
[02:06] <Maxels> hmmm, so how would I force the process to mount the disk again after running modprobe
[02:08] <sarnold> I'd just try mount /path/to/device /path/to/mount/point and see if that works
[02:08] <sarnold> if it works, then figure out how to get the boot process to mount it, if that's what you want, and if it doesn't work, then start debugging that :)
[02:10] <Maxels> ah, I see what you're saying
[02:10] <Maxels> so I ran the exact same command that failed on boot, and it failed after I had run modprobe
[02:11] <sarnold> how did it fail?
[02:15] <Maxels> same error as when booting: wrong fs type, bad option, bad superblock on /dev/sda, missing codepage or helper program, or other error.
[02:16] <sarnold> is there anything more useful in dmesg?
[02:16] <Maxels> I don't even know what dmesg is
[02:17] <sarnold> dmesg dumps the kernel's message buffer
[02:17] <sarnold> it's INSANELY wonderful
[02:17] <sarnold> get to know this one :)
[02:19] <Maxels> oh boy, lots of info
[02:20] <Maxels> I'm digressing a lot, but something that drives me nuts is how history doesn't seem to always save, and gets truncated
[02:20] <Maxels> is there a way to make history unlimited and save more often somehow?
[02:20] <Maxels> I'm trying to remember the commands I used to mount the volume after I was wrestling with some accounts, and it lost history
[02:23] <sarnold> so... history is involved.
[02:24] <sarnold> you can configure a HGUE amount of aspects of it; man bash, search for HIST and histappend
[02:24] <sarnold> running multiple shells at once tends to be the usual cause of "lost" command
[02:26] <sarnold> there are external tools you can use too, to try to store history across sessions / computers / etc .. I don't use this myself, but it *looks* neat, you know? :)
[02:38] <Maxel> yeah maybe that was a bad assumption, that it would work across sessions
[02:38] <Maxel> I assumed it was user based
[02:41] <sarnold> each shell maintains its own in-memory history of executed commands
[02:41] <sarnold> and at exit will either overwrite the history file, or append to the history file
[02:42] <Maxel> yeah, and I just want the "no matter where you're session originated, if you use the same user save any command to history, forever"
[02:43] <sarnold> that can be done :)
[02:43] <Maxel> I've got all sorts of problems with this upgrade though. I can't connect via ssh anymore, the fs isn't mounting correctly, I guess that's all my problems for now
[02:43] <Maxel> history thing has been a long ongoing problem
[13:48] <lordcirth> Maxel, try adding this to bashrc: "export PROMPT_COMMAND='history -a'"
[13:48] <lordcirth> that will flush your history to file every command
[14:44] <rbasak> cpaelzer: https://pastebin.ubuntu.com/p/xG2VTmDb7j/
[14:45] <rbasak> cpaelzer: not a problem from an SRU review perspective, but seems odd from a git-ubuntu workflow perspective.
[14:53] <cpaelzer> rbasak: that is the first time we used git ubutnu for that - formerly was pull-lp-source
[14:53] <cpaelzer> interestign
[15:31] <rbasak> cpaelzer: ah. It's because the watch file uses bz2
[15:32] <rbasak> So therefore uscan does
[15:38] <cpaelzer> ah ok, the confusion makes snese now
[15:38] <cpaelzer> even "sense"
[16:33] <theGoat> we are using setfacl to give the splunk user access to read logs in /var/log, but what we have noticed is that it is also changing the group permissions of the file.  is there a way to run it so it doesn't touch the group permissions?
[16:37] <sarnold> theGoat: is the filesystem mounted with noacl?
[16:37] <theGoat> no i don't believe so
[16:37] <theGoat> i would have to reach out to one of the system owners
[16:40] <sarnold> I did this on an 18.04 LTS and got the results I expected: setfacl -m u:root:w _z.jpg
[16:41] <strk> what's the preferred way to pass env variables to a systemd service file ?
[16:44] <jelly> strk: /etc/init/foo.conf is NOT a systemd service file, it's an upstart service... uh, thingy
[16:45] <strk> uh
[16:45] <jelly> disclaimer: srtk was accidentally asking about their "how to pass http_proxy env.var. to a service" trusty issue in #debian
[16:46] <jelly> we had zero clue and less interest in that, but figured someone in here might remember enough about upstart
[16:46] <sdeziel> isn't that the "env" directive?
[16:47] <jelly> strk: see!  That's what happens when you ask in the right place.  Answers.
[16:47] <sdeziel> strk: yes, that's env: http://upstart.ubuntu.com/cookbook/#env
[16:49] <sdeziel> strk: you may or may not want to put that in a .override file (/etc/init/foo.override, see http://upstart.ubuntu.com/cookbook/#override-files)
[16:50] <strk> how about: service localstack restart http_proxy=xxxx ?
[16:51] <strk> is that expected to work ?
[16:51] <lordcirth> strk, fyi, trusty won't be supported much longer, unless you're paying
[16:52] <jelly> and if you're paying?
[16:52] <jelly> will repos be moved somewhere behind a username and password?
[16:52] <sarnold> updates will be hosted on a ppa
[16:53] <sarnold> I think the archives will be left alone
[16:53] <jelly> but still available to anyone?
[16:53] <sdeziel> strk: no that won't work, see http://upstart.ubuntu.com/cookbook/#job-environment
[16:54] <jelly> looking at Debian ELTS, paid support but the repo is free to use if you need fixes for a package that someone else is paying support for.
[16:54] <lordcirth> jelly, the archives stay up for a while, yes, but without updates
[16:55] <jelly> lordcirth: will the updates be hidden behind username and password or some other auth?
[16:55] <strk> I didn't understand the documentation about `env`, nor I see a clear reference about job-environment in the #job-environment url
[16:55] <strk> I'm probably too tired
[16:55] <sdeziel> jelly: in https://www.ubuntu.com/esm#faq: "ESM is just a regular Ubuntu archive, but authenticated and served over HTTPS."
[16:56] <lordcirth> !esm | jelly
[16:57] <sdeziel> strk: in your case, you'd probably want to use this: echo 'env "http_proxy=xxxx"' >> /etc/init/localstack.override
[16:58] <sdeziel> strk: because otherwise, the job's environment is really minimal (only TERM and PATH)
[17:01] <jelly> uh... why would the service manager define TERM
[17:01] <jelly> wait, don't answer, I'm fine not knowing any more about upstart now that it lives only in EL6
[17:02] <jelly> (and trusty)
[17:03] <jelly> thanks for the faq!
[17:04] <sarnold> no no I'm curious about this, what *does* it default to? :)
[17:04] <sdeziel> sorry, -ENOTRUSTY
[17:07] <sdeziel> http://upstart.ubuntu.com/cookbook/#mountall-examples suggests "TERM=linux"
[17:09] <sarnold> TERM=linux is in a huge pile of expected test results too
[17:09] <sarnold> https://sources.debian.org/src/upstart/1.11-5/ChangeLog/#L10626
[17:15] <strk> sdeziel: but in that case It'll stay, while my goal is to NOT store the proxy info in a static place
[19:47] <teward> where do I report a subiquity installer bug again?
[19:49] <ahasenack> bugs.launchpad.net/subiquity iirc
[19:49] <ahasenack> hm, no
[19:50] <ahasenack> https://bugs.launchpad.net/subiquity/+filebug <-- there teward
[19:50] <teward> ahasenack: that's what I thought i just filed my bug
[19:50] <teward> nasty little search domain ERRORCRASH cases
[19:50] <ahasenack> cool
[19:56] <the_actor> I am having problems with setting up two factor authentication for SSH using pam_google_authenticator.so. I am using a fresh install of Ubuntu LTS 18.4 and can’t seem to get PAM to work well with SSH. The minute I systemctrl reload ssh.service the SSH login prompt looks different and fails regardless of input. Been using this
[19:56] <the_actor> https://www.google.com/amp/s/www.linuxbabe.com/ubuntu/two-factor-authentication-ssh-key-ubuntu-18-04/amp I have gone over the steps multiple times. Any suggestions?
[19:57] <lordcirth> the_actor, anything useful in 'journalctl --unit ssh', 'less /var/log/auth.log', or 'less /var/log/syslog'?
[20:01] <the_actor> I have not checked. I have rolled back the image multiple times to a base 18.4 install. I am thinking there is some thing I don’t understand regarding how pam and or ssh work or some minor difference in the way the config files are written. The only other thing is perhaps I need to generate a key, which is something I am trying to replace with a password and a google auth token.
[20:02] <lordcirth> I have not done this, so I don't know, but "check the logs" is usually a good place to start.
[20:03] <the_actor> And I’m not even sure that it is a good idea, because I have read in the SSH official documentation that they prefer password based login as opposed to public key. I’m wondering how secure that actually is without some kind of pre-shared key or certificate being done over the cloud. So the Google authentication token seems like a good idea. Unless I am foolishly misguided.
[20:04] <the_actor> I invite any input.
[20:06] <lordcirth> the_actor, where did you see that passwords are preferred to keys?
[20:06] <the_actor> The most important thing is, in its default state, once the user manual he authenticates the fingerprints, is every subsequent initial connection after that initiated with the protection of encryption?
[20:07] <the_actor> Hold on let me see if I can locate the article.
[20:07] <lordcirth> the_actor, with default ssh configs? Yes, everything is encrypted, and once the user accepts the host's key, any server without that key will be unable to impersonate or read the connection.
[20:11] <the_actor> It was on ssh.com in one of their articles. I can not locate the exact one now. They were weighing out the pros and cons of key-based authentication password-based authentication and Certificate based authentication
[20:13] <the_actor> lordcirth: what is your opinion on a simple password, and a google one time use authentication token?
[20:13] <sdeziel> the_actor: ssh.com != openssh
[20:13] <lordcirth> the_actor, depends, how much do you trust Google? :P
[20:13] <sdeziel> the_actor: if you don't want TOTP specifically, you can easily do pubkey+Unix password auth with OpenSSH
[20:13] <the_actor> lordcirth: interesting point
[20:13] <lordcirth> Google Authenticator is proprietary now, which is a red flag.
[20:14] <lordcirth> But I think you can do similar things with open source apps and self-hosting.
[20:16] <the_actor> sdeziel: Good point. Just thought adding it to my google auth app would be easier.
[20:17] <the_actor> lordcirth: Thanks for the warning, I thought it was open source.
[20:17] <lordcirth> the_actor, it was, and then it wasn't. I think f-droid still has an old copy, but I wouldn't start using it if you aren't already.
[20:17] <lordcirth> And yeah, pubkey + password means you need your device + your brain, which is pretty decent.
[20:20] <the_actor> lordcirth: Thanks, to confirm. Even though I do not have any security cert on my server, with the default config once the ssh keys are accepted on initial connect then in subsequent connects my password is not sent in clear text over the cloud?
[20:20] <lordcirth> the_actor, ssh will never send a password over cleartext. It will never send data over cleartext unless you pass some very specific and obvious options.
[20:22] <the_actor> lordcirth: Ok, so then the safest bet would be to confirm the keys on first connect on the local net?
[20:23] <lordcirth> the_actor, the main vulnerability here is that an attacker pulls a MITM attack on your first connection, you accept their host key, and they continue to MITM you. If you need to avoid this, copy the host key over yourself in some trusted manner
[20:23] <lordcirth> Or just view the host key fingerprint on the server and compare visually, I guess
[20:24] <the_actor> lordcirth: Cool man. You helped me a lot.
[20:24] <the_actor> Thanks guys
[20:24] <lordcirth> np
[20:54] <keithzg[m]> Hmm, how might I blacklist libraries from being loaded while trying to run an executable? Trying to run a self-compiled version of `sqlite3` and it's failing on "header and source version mismatch" and I'm presuming (perhaps incorrectly!) that this is due to the sqlite3 libraries already installed on the system.
[20:56] <lordcirth> keithzg[m], prepend your custom lib dir to LD_LIBRARY_PATH
[22:08] <qwebirc24999> Hello. I am unable to use iscsi in initramfs properly - specifically, the internet connection is not established. This bug I am having since 18.10. It all works in 18.04.
[22:08] <qwebirc24999> so what I did was install open-iscsi, then echo "iscsi" >> /etc/initramfs-tools/modules, echo "ISCSI_AUTO=true" > /etc/iscsi/iscsi.initramfs and update-initramfs -u. To see if it all works, I made a keyscript with curl example.com and disabled quiet splash. In 18.10 (and 19.04) connection details do not appear like in 18.04 (signaling that there is an issue) and example.com cannot be resolved then. How do I fix this issue
[22:27] <keithzg[m]> lordcirth: Oh, I don't know why that didn't occur to me!  Although, that doesn't seem to actually change anything; I still get "SQLite header and source version mismatch" (then the two disparate entries corresponding to the `#define SQLITE_SOURCE_ID` lines in `sqlite3.h` presumably; certainly the one corresponds to that in my local copy of `sqlite3.h`. Hmmm.
[22:52] <mwhudson> teward: thanks for the bug, i think that one is fixed in the current subiquity release
[22:52] <mwhudson> but i should check i guess
[23:47] <qwebirc24999> folks, why is it that on dhcp setup in initramfs I get a line 8 error 8.8.4.4 not found? My line 8 is IPV4DNS0=8.8.8.8 8.8.4.4 [ISP DNS]
[23:49] <sarnold> try just one ip