[00:55] <smoser> nacc, here.
[05:29] <cpaelzer> good morning
[07:32] <webnar_> @ppetraki Hi
[07:33] <webnar_> the Raid still works without issues
[07:34] <webnar_> So indeed it looks like a bug in Ubuntu server 16.04
[07:41] <joy-ict> Hi there :-) I'm looking for some help with setting up a forwarding dns
[07:41] <joy-ict> I want to use Moodle and Suitecrm outside the office. But the only things i can run outside now are SSH and Webmin
[12:13] <coreycb> jamespage: when you get a moment can you promote newton-staging to newton-proposed?
[13:39] <aaronr> cpaelzer: happy to help further with the proposed verification of https://bugs.launchpad.net/ubuntu/+source/nagios3/+bug/1686768 when it gets to that stage. i'll continue to monitor the bug, and will check in here to find out what i need to do when the time comes
[14:06] <DammitJim> have you guys disabled SMBv1 on all your linux systems?
[14:06] <DammitJim> someone just came to me telling me we need to disable it on all of our Linux systems because of the wanna Crypto vulnerability
[14:06] <DammitJim> how true is this? or where should I go to get the truth?
[14:07] <azidhaka> i don't think samba is vulnerable
[14:09] <DammitJim> dammit... it's so hard to find answers to these questions from a reliable source
[14:09] <DammitJim> azidhaka, nothing against you. I appreciate that at least you replied
[14:10] <DammitJim> but I need something to backup my answers so that the company doesn't send me to update all my linux machines
[14:10] <DammitJim> I have other projects that need to get done and I don't know that this is a real critical problem at this time
[14:11] <dpb1> DammitJim: did they point you to a CVE?
[14:12] <DammitJim> no, this is more of an: I read a blog and they said you need to disable SMBv1
[14:12] <DammitJim> now, since they have posed the question, I have to show that it's not necessary
[14:12] <DammitJim> does that make sense?
[14:13] <teward> DammitJim: does https://www.cyberciti.biz/faq/how-to-configure-samba-to-use-smbv2-and-disable-smbv1-on-linux-or-unix/ help?
[14:13] <DammitJim> teward, actually I think that's the article they read
[14:13] <teward> DammitJim: ultimately CIFS / SMB will default to trying version 2.0 or 3.0 and fall back to 1.0 iirc.  That said, if you have older servers (Win 2k3) or servers which aren't new enough to support SMBv2 then, that's out of the scope of what you can do
[14:14] <teward> DammitJim: that's... not an article, that's a how-to
[14:14] <teward> and that only applies to Samba servers
[14:14] <DammitJim> but I don't know who told this guy that he needs to disable SMBv1 because of wanna crypto
[14:14] <teward> not Samba clients on Linux devices
[14:14] <DammitJim> make sense?
[14:14] <azidhaka> DammitJim: the samba vulnerabilites are listed here: https://www.cvedetails.com/vulnerability-list/vendor_id-102/Samba.html
[14:14] <teward> DammitJim: because SMBv1 *is* ancient and vulnerable and should be disabled except for absolutely critical legacy support of things
[14:15] <DammitJim> again, I am just trying to figure out if I need to disable SMBv1 because of wanna crypto or because of it being OLD and vulnerable in general
[14:15] <DammitJim> does that make sense?
[14:15] <teward> DammitJim: stop saying "does that make sense"
[14:15] <teward> it's irritating
[14:15] <teward> yes, it does make sense.  you should disable for BOTH reasons
[14:15] <DammitJim> because if it is because of wanna crypto, I have to drop everything and disable SMBv1 on all my servers right now (test first)
[14:15] <teward> and patch all Windows 7 systems.
[14:15] <azidhaka> DammitJim: if you have old clients which require smbv1, do not disable it
[14:15] <teward> windows 7 / 8 / xp systems *
[14:15] <DammitJim> but if it is just because of it being old and vulnerable, I can table that and deteremine where it falls in my schedule of things
[14:16] <azidhaka> DammitJim: i wouldn't unless it vulnerable
[14:16] <DammitJim> yeah, windows server/workstations patching is in progress
[14:16] <DammitJim> teward, I'll stop saying "does that make sense"
[14:16] <DammitJim> ;)
[14:16] <teward> DammitJim: unless your LInux systems are running Wine, then, you shouldn't disable SMBv1 unless it's absolutely necessary to disable it.
[14:16] <teward> WannaCrypt won't hurt your Linux boxes unless you've got Wine, and unless your SMB servers are internet facing directly I'd be a little less concerned
[14:16] <DammitJim> ok, so it seems the consensus is that disabling SMBv1 doesn't have much to do with WannaCrypt
[14:17] <azidhaka> DammitJim: in linux
[14:17] <teward> ^ that
[14:17] <teward> DammitJim: in Windows it's a different story
[14:17] <DammitJim> thanks azidhaka ... in linux
[14:17] <DammitJim> right
[14:17] <DammitJim> ok, thanks! I'll tell the group that asked me this question that the how to they found makes it sound like wannacrypt and SMBv1 are related but in reality they aren't
[14:17] <teward> well
[14:17] <DammitJim> thanks guys!
[14:18] <teward> DammitJim: that's not entirely accurate either
[14:18] <DammitJim> uh oh
[14:18] <azidhaka> DammitJim: SMBv1 was vulnerable in Windows, is not vulnerable in Linux
[14:19] <azidhaka> DammitJim: disable it or patch all your windowses and leave the linuxes alone :)
[14:19] <teward> azidhaka: The question is two-fold.
[14:19] <teward> erm
[14:19] <teward> DammitJim: ^
[14:19] <teward> Question 1: Is SMBv1 vulnerable in Linux?  Question 2: Is SMBv1 vulnerable to WannaCrypt in Windows?
[14:19] <teward> And Question 3: Is SMBv1 vulnerable to WannaCrypt in Linux
[14:20] <DammitJim> yes, I am trying to address question 3
[14:20] <teward> Answer to #1: No, not really.  Answer to #2: Absolutely, patch all windows systems and disable SMBv1 on the client systems
[14:20] <teward> Answer to #3: Not really.  Just don't run Wine on linux systems.
[14:20] <DammitJim> it's all in the context of: Do I need to disable SMBv1 on all my linux systems because of wanna cry
[14:20] <DammitJim> and the answer is NO
[14:21] <DammitJim> thank you!
[14:21] <teward> DammitJim: read https://askubuntu.com/questions/914623/what-is-the-wanna-cry-ransomwares-possible-impact-on-linux-users
[14:21] <DammitJim> oh, also know that we don't use wine
[14:21] <DammitJim> we drink it ;)
[14:21] <teward> ultimately you have your answer.  So long as you patch your Windows systems and servers and install the security updates regularly
[14:22] <teward> because there's other nasties that get patched regularly you need to patch against :p
[14:22] <DammitJim> yeah, I am trying to get our group on a schedule for patching different o/s in a regular basis
[14:22] <DammitJim> I got interrogated about: do you read all the release updates at all times to know if we need to patch our systems?
[14:22] <DammitJim> if someone can tell me how one can do that, please let me know!
[14:22] <teward> unattended-upgrades for Linux systems, exclude the Linux packages, set to run daily, don't force reboot
[14:23] <teward> email a given email address on the network when completed.
[14:23] <teward> unattended-upgrades is what keeps the mail server and a few other servers at the one workplace i work with up to date with security updates
[14:23] <teward> we patch the rest for bugs monthly
[14:24] <Ussat> teward, if you use unattended, I assume you test first, on a test system....
[14:26] <teward> On six systems, yes.
[14:26] <teward> THat said, the only things that we really just need patched are the kernel and a few other things, we disable all other updates.  Security-only, and those go through some pretty thorough tests, as I understand those security releases/updates.
[14:26] <teward> sarnold: ^ cc
[14:26] <teward> the only other thing we'd worry about is nginx, but that's usually patched within a day of me seeing a patch heh
[14:27] <teward> since I help the security team sometimes with that :)
[14:34] <DammitJim> teward, how do you test that the updates aren't breaking something?
[14:37] <teward> i have a test environment running the same services as production does, and a test suite that tests functionality every day an hour after updates complete.  If nothing fails, that doesn't issue a "Don'tUpdate" notice to the production systems
[14:37] <teward> lots of custom code
[15:24] <nacc> smoser: do you think it's reasonable (UX) to have `git ubuntu add-remote` only work with an explicit directory or from the current directory? (then we can derive, e.g., the srcpkg and such)
[15:37] <smoser> nacc, that seems fine to me.
[15:37] <smoser> add-remote user ?
[15:37] <smoser> you mean
[15:37] <nacc> smoser: yeah
[15:37] <smoser> git-ubuntu add-remote <thing>
[15:37] <nacc> smoser: so you'd only need to add the lp-user you want to add the remote of
[15:38] <nacc> smoser: we'd figure out everything else
[15:38] <smoser> i was thinkign <thing> could be a full remote, but then it takes a name too
[15:38] <smoser> i think its sane.
[15:38] <nacc> smoser: oh true, it could be -- although, imo, adding a remote with a full url is a better task for `git` itself :)
[15:38] <smoser> git ubuntu add-remote <user> [name-if-different]
[15:39] <smoser> but i think it should be remote-add
[15:39] <smoser> right ?
[15:39] <smoser> as that is gwhat it is to git
[15:39] <smoser> git remote add <name> <url>
[15:39] <nacc> smoser: hrm, true
[15:40] <smoser> git ubuntu remote-add <user> [url]
[15:40] <smoser> that follows pretty easily dont you think ?
[15:40] <smoser> if you give it url, it just calls git add remote
[15:41] <smoser> except fdor the case where you dont want your name the same as the user i guess.
[15:41] <smoser> :-(
[15:41] <nacc> smoser: yeah, but then i need to check the input for a url
[15:41] <nacc> smoser: your 'name' meaning the remote's name?
[15:41] <smoser> well, you need both remote name and user
[15:41] <smoser> right ?
[15:41] <nacc> right, we curently make them the same
[15:41] <nacc> we can take a remote-name as an optional parameter
[15:42] <nacc> or a flag, even
[15:42] <smoser> i think its probably reasonable to want to change the name
[15:42] <smoser> (ie, for that ~ubuntu user)
[15:42] <smoser> git ubuntu remote-add [--remote-name=name] user [url]
[15:42] <nacc> smoser: oh good point , i usually change racb to robie :)
[15:42] <nacc> smoser: yep
[15:42] <smoser>  remote name is user by default
[15:42] <nacc> smoser: thanks! that's good!
[15:43] <smoser>  if url is provided, then it just goes onto git remote add
[15:43] <nacc> smoser: yep
[15:43] <nacc> smoser: cool, thanks!
[15:43] <smoser> switfching location
[17:33] <sarnold> DammitJim: we publish USNs to https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce and https://www.ubuntu.com/usn/ -- and we're trying to get the hang of https://twitter.com/ubuntu_sec but no promises there
[17:48] <DammitJim> thanks sarnold!
[17:48] <DammitJim> sarnold, this is different than lists.ubuntu.com mailing lists, right?
[17:48] <mason> azidhaka: That's on lists.ubuntu.com.
[17:49] <mason> DammitJim: *
[17:49] <mason> Not sure how tab pulled up azidhaka.
[17:49] <DammitJim> I say that because I had forgotten that I have some kind of account and get the email every first of the month telling me what my password is LOL
[17:51] <sarnold> "gee thanks mailman"
[17:51] <sarnold> hehe
[17:51] <DammitJim> what I mean, though is that the link you posted seems to be a separate subscription?
[17:52] <DammitJim> or can I just add that subscription to my account?
[17:52] <sarnold> 'separate' to what? there's a billion lists hosted there..
[17:53] <DammitJim> meaning... if I go to my Membership configuration page
[17:53] <sarnold> iirc there's a button in one of the mailman fields for allowing you to turn off the monthly password reminders 'globally', but they're for the most part all independent from each other
[17:53] <DammitJim> I don't see an option to get security subscriptions ? I'm blind
[17:53] <DammitJim> and you are right, there is an option to NOT get your password
[17:54] <DammitJim> oh, interesting... so I guess my account is just for the ubuntu-us-fl mailing list
[17:54] <DammitJim> nothing to do with getting security announcements....
[17:55] <DammitJim> man, patching is a neverending story, isn't it?
[17:56] <mason> DammitJim: You can just subscribe to the security list. It's a plain vanilla Mailman.
[17:56] <mason> I subscribed, and it yelled at me because I was already subscribed.
[17:57] <DammitJim> LOL
[17:57] <DammitJim> I"m going to shut up now
[17:57] <sarnold> DammitJim: never-ending.. you have no idea.
[17:57] <DammitJim> :D
[17:58] <mason> Patching makes my cold heart warm.
[17:58] <sarnold> DammitJim: it's insanely demoralizing to have new issues reported against a packaage just when you're about to release updates for it for older issues..
[17:58] <DammitJim> hahaha... I don't have a problem patching a system
[17:58] <DammitJim> I have a problem testing all the systems after the patch
[17:58] <mason> True, doing things right is a beast.
[17:59] <DammitJim> I don't know why, but the company where I work wants all applications that we use on that server tested in a sandbox before the patch
[17:59] <mason> Containers will save us.
[17:59] <mason> heh
[17:59] <DammitJim> mason, I'd like to think that ;)
[17:59] <mason> Do you do dev → qa → prod and the sandbox is one of the first two?
[17:59] <DammitJim> sandbox is kinda like dev
[17:59] <mason> I'm a fan of organized promotion. That said, I don't do it for my home set-up, and I'm not an admin any more, so I've grown lax.
[18:00] <DammitJim> we've moved away from the dev being managed by my team and dev is more what the developers maintain, which is kinda nice
[18:00] <DammitJim> what do you do now, mason ?
[18:00] <mason> DammitJim: Technical Account Manager
[18:00] <DammitJim> I'm starting to get tired of the admin role
[18:01] <DammitJim> but heck, I have a job, so I shouldn't complain
[18:01] <mason> Being a TAM's like being an admin, but more use of soft skills, and issues don't follow me into evenings and weekends.
[18:01] <mason> Yar.
[18:01] <DammitJim> LOL
[18:01] <DammitJim> that's 1 of them... it gets in the way of my family life...
[18:02] <mason> Before I became a TAM, I was an admin, and right before I took the offer for my current job, I had an on-call week where I got four hours of sleep, once, during my on-call week. That was the peak of sleep, and most sleep periods were much shorter. Made it easy to accept the offer.
[18:02] <sarnold> DammitJim: definitely if you can put together enough of your environment in a VM or something, it can save some hassles. we do our best but mistakes happen, and, like you, it's quite difficult to test everything.
[18:02] <DammitJim> anyways, thanks for the info. I'm trying to assign someone in my team to review the security updates on a daily/weekly basis so we know if we need to accelerate patching for a system
[18:03] <mason> DammitJim: The list will be useful, and you probably already use something like apticron.
[18:03] <mason> ...or something centralized that does that.
[18:03] <DammitJim> sarnold, man, thanks for speaking from the heart. I know you guys are doing your best and I don't have anything about patches. it's just that sometimes developers and even admins make mistakes in putting configs where they shouldn't be and then an update (that needs to really fix something) changes how something works and then the developed app no longer works
[18:04] <mason> DammitJim: Do you use Ansible or Puppet or similar?
[18:04] <DammitJim> the hard part about the list is really understanding the impact or severity to determine if we need to go through the patching cycle
[18:04] <DammitJim> I use salt, so with that respect, things can be fixed quickly
[18:04] <mason> The whole cfengine-inspired trusted repository with admins only accessing the repo through version control is hugely good.
[18:05] <mason> kk
[18:05] <DammitJim> but that's not the problem... the problem is time spent testing and guess who ends up having to test? the support team
[18:05] <DammitJim> and letting the customers know that there will be an outage
[18:06] <DammitJim> I'll be honest in saying that in other companies, I patched w/o testing and this wasn't as much of an issue... out of patching hundreds of times, we probably only had an issue once
[18:06] <mason> Redundancy can help with outages, especially if your platform is using a stable API and you're just fixing bugs.
[18:06] <DammitJim> yeah!
[18:07] <DammitJim> do you guys have someone on your team that reads the security releases on a daily basis?
[18:07] <DammitJim> how do you determine if the patch needs to be applied ASAP?
[18:07] <DammitJim> I wanna say for Ubuntu servers, I patch every quarter *cringes*
[18:08] <mason> In admin teams I've been on, I tend to do that regardless of any formal activity. Varies a lot formally.
[18:08] <DammitJim> yeah, very subjective, right?
[18:09] <sarnold> DammitJim: we don't really judge -severity- since that can vary wildly from site to site. we do prioritize the order in which we work through the CVEs; here's the criteria we use http://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master/view/head:/README#L191
[18:09] <mason> Oh, you mean sarnold and the Canonical security team. Sorry for the noise. Heh.
[18:10] <DammitJim> no, I meant exactly what sarnold just said... for my company, how do I determine the severity of the security problem for which a fix has been released
[18:10] <sarnold> DammitJim: most of us do take most weekends :)
[18:10] <DammitJim> I'd drive myself nuts learning every single issue and understanding how it impacts me
[18:10] <sarnold> but tracking CVEs is almost a full-time position for us
[18:11] <mason> Gods, just reading the security-lists is a ton of work, let alone parsing for applicability.
[18:11] <DammitJim> right... that's my challenge, but it's a good one and one that needs to be dealt with
[18:12] <DammitJim> this week when this whole thing about WannaCry came out
[18:12] <DammitJim> I didn't know what to say about patching when I was asked about it
[18:12] <DammitJim> why haven't you guys patched the Windows servers?
[18:13] <DammitJim> well, we are in a 3 month cycle and we haven't gotten around to it since we patched back in March
[18:13] <DammitJim> oh, you need to patch them... sure, that's the plan
[18:13] <DammitJim> I'm digressing.... I'm going to stop
[18:13] <DammitJim> I hope you guys have a great Friday, though!
[18:15] <mason> DammitJim: You too!
[18:23] <DammitJim> I'm not going anywhere, just trying to keep the channel on-topic ;)
[18:56] <nacc> rbasak: i assume you're not around?