[00:37] <cyphermox> is this a known thing? https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1700826
[00:37] <cyphermox> (I can update the seed, but I want to make sure it's agreed upon before)
[00:57] <hehehe> hey folks
[00:57] <hehehe> who here knows git well? :D
[04:46] <nacc> cyphermox: i'll ask at our standup tmrw
[05:22] <cpaelzer> good morning
[12:55] <[J]oules_> local ubuntu 16.04 acting as syslog server for LAN. rsyslog.conf is setup for udp and tcp on port 514 to enable syslog server. ufw is disabled. iptables -nL shows accept for the 3 default chains. However no lan device/computer is able to communicate with this ubuntu server.
[12:58] <lordievader> At all, or only the rsyslog service?
[12:58] <lordievader> [J]oules_: ^
[12:58] <Ussat> different vlans ?
[12:58] <Ussat> firewall between them
[12:59] <[J]oules_> no vlans
[12:59] <Ussat> FW's between them ?
[12:59] <Ussat> how are you checking connectivity ?
[13:00] <[J]oules_> trying to debug sip phone. have sip phone syslog pointing to this ubuntu 16.04. disabled ufw and rebooted. don'
[13:00] <[J]oules_> see anything in /var/log/syslog, /var/log/messages from phone at all
[13:01] <[J]oules_> changed sip  phone syslog to send to remote centos server, remote centos shows logs from sip phone
[13:02] <[J]oules_> just dont want those logs going to remote server. want them to come to this local ubuntu server
[13:07] <lordievader> [J]oules_: Could you answer my quesiton?
[13:08] <lordievader> question even
[13:09] <[J]oules_> lordievader: since rebooting only see very few entries in syslog and messages like: Jul 13 09:01:42 myomie colord[1430]: (colord:1430): Cd-WARNING **: failed to get session [pid 3889]: No such device or address
[13:09] <[J]oules_> Jul 13 09:09:01 myomie CRON[3928]: (root) CMD (  [ -x /usr/lib/php/sessionclean ] && /usr/lib/php/sessionclean)
[13:09] <[J]oules_> thats it
[13:10] <lordievader> That was not my question... is there any network response when pinging it from another host, for example?
[13:11] <[J]oules_> i can ping the ubuntu server, ssh to it, cannot telnet port 514 to it
[13:11] <lordievader> What does nmap report about that port?
[13:11] <[J]oules_> nmap not installed
[13:12] <[J]oules_> from other server on lan: ping myomie
[13:12] <[J]oules_> PING myomie.internal (192.168.25.15): 56 data bytes
[13:12] <[J]oules_> 64 bytes from 192.168.25.15: icmp_seq=0 ttl=64 time=0.306 ms
[13:12] <lordievader> Could you install nmap and check?
[13:12] <[J]oules_> telnet myomie 514
[13:12] <[J]oules_> Trying 192.168.25.15...
[13:12] <[J]oules_> telnet: connect to address 192.168.25.15: Connection refused
[13:12] <[J]oules_> yup
[13:13] <lordievader> Also, use some pastebin service for pasting console output.
[13:14] <[J]oules_> lordievader: do you know the syntax to nmap port 514?
[13:14] <lordievader> [J]oules_: Assuming you want tcp: `nmap -p 514 <host>`
[13:15] <[J]oules_> thx
[13:15] <[J]oules_> 514/tcp closed shell
[13:16] <[J]oules_> if iptables shows accept for everything, ufw shows disabled why is it blocked?
[13:16] <[J]oules_> i tried before to open 514/tcp and it still did not help
[13:16] <[J]oules_> fw status
[13:16] <[J]oules_> Status: inactive
[13:19] <lordievader> Could you pastebin the output of 'sudo iptables-save'  and 'sudo ss -tnl'?
[13:28] <coreycb> jamespage: most of the pike failures for CI are due to needing the new python-sphinx
[13:29] <coreycb> jamespage: I checked with the maintainer and he said he's planning on uploading but will be a few weeks
[13:44] <cyphermox> nacc: ta
[13:46] <Adri2000> hello
[13:47] <Adri2000> anyone knows why https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1699010 is marked for lxd instead of lxd/lxcfs?
[13:47] <Adri2000> and if there is some kind of SRU in progress for xenial?
[13:49] <[J]oules_> https://www.irccloud.com/pastebin/PunCQwY1/
[13:50] <hehehe> hey hey
[13:50] <[J]oules_> lordievader: i see 514 is not listed
[13:50] <hehehe> lordievader: heya :)
[13:53] <hehehe> lordievader: do u know git?
[13:54] <hehehe> I am encountering some silly error yet to see what is it
[13:55] <[J]oules_> lordievader: i take it that since this ubuntu server is not listening on 514 is the reason. Question then is, how to get it to listen on port 514?
[13:55] <hehehe> you  can install use ufw
[13:55] <hehehe> easy to use
[13:56] <hehehe> then you cal simply sudo ufw allow 514
[13:56] <hehehe> :)
[13:56] <hehehe> and it will auto adjust iptables rules
[13:56] <hehehe> u can also allow in only or out only and to a specific ip and or protocol
[13:58] <[J]oules_> hehehe: i did that before ... ufw allow 514/tcp and ufw allow 514/udp and no syslog messages were coming in
[13:59] <hehehe> you using ossec?
[13:59] <hehehe> then you need to open 1 more port
[14:00] <hehehe> 1514?
[14:00] <hehehe> you can google which port :D
[14:01] <[J]oules_> i am not using ossec
[14:02] <hehehe> well then why u need 514 open?
[14:02] <[J]oules_> just whatever installs with ubuntu server
[14:02] <hehehe> whatever what?
[14:02] <[J]oules_> because we need to debug a device on LAN
[14:02] <hehehe> whats it called?
[14:02] <hehehe> well then open it and thats it
[14:02] <hehehe> :D
[14:02] <[J]oules_> the iso for ubuntu 16.04
[14:02] <hehehe> yes fine
[14:02] <[J]oules_> there was no extra security added
[14:02] <hehehe> thats fine
[14:02] <hehehe> you can add it yourself
[14:02] <hehehe> :)
[14:03] <[J]oules_> add what?
[14:03] <hehehe> whatever u want to add
[14:03] <hehehe> security wise
[14:03] <[J]oules_> you mean even if ufw/iptables is disabled it still blocks?
[14:04] <[J]oules_> put it this way, how to get it to listen to 514 ?
[14:04] <teward> [J]oules_: run a service that binds to port 514
[14:04] <[J]oules_> from what i read ....
[14:04] <teward> have a firewall rule to include port 514 as allowed
[14:04] <teward> you can't send traffic to a port that doesn't have something to receive the data - that's the core issue there.
[14:04] <teward> to have something listen on <= 1024 you usually need to run something as root
[14:05] <[J]oules_> rsyslog
[14:05] <[J]oules_> https://www.irccloud.com/pastebin/ZXy2gFy2/
[14:05] <hehehe> yes what teward said :D
[14:05] <hehehe> use common sense dude
[14:06] <teward> [J]oules_: that usually doesn't run as root, IIRC.  you may need to use a higher port number like 10514, and then set up a local port-forward for the firewall
[14:06] <[J]oules_> everything i searched said to enable rsyslog with what is in the p/b and restart rsyslog
[14:06] <teward> hehehe: that's not necessary, please refrain from rudeness.
[14:06] <hehehe> common sense is rude?
[14:06] <hehehe> dude get lost
[14:06] <hehehe> :)
[14:06] <teward> >.>
[14:06] <teward> this is why I hate IRC sometimes
[14:06] <[J]oules_> no kidding
[14:07] <[J]oules_> usually because the answer is not known
[14:07] <hehehe> Joule simply do something like  ssh root@example.com -p514  from any other box
[14:07] <hehehe> :)
[14:07] <hehehe> -p is port
[14:07] <hehehe> wait nope
[14:07] <[J]oules_> teward: the firewall ufw/iptables is disabled
[14:08] <[J]oules_> hehehe: i showed earlier, telnet port 513 connection refused
[14:08] <[J]oules_> hehehe: i showed earlier, telnet port 514 connection refused
[14:08] <[J]oules_> sorry
[14:08] <hehehe> yep
[14:08] <[J]oules_> port 514
[14:08] <hehehe> 1 moment :)
[14:10] <[J]oules_> getting rsylog working on a centos server which is remote works, but dont want these logs going remote
[14:10] <[J]oules_> basically same setup with rsyslog.conf and restarting rsyslog
[14:10] <[J]oules_> for some reason on ubuntu its like pulling teeth
[14:10] <hehehe> https://superuser.com/questions/397892/utility-to-open-tcp
[14:11] <teward> [J]oules_: you may want to use a higher port.
[14:11] <teward> such as 1051X, because <= 1024 usually has issues
[14:11] <teward> [J]oules_: is the system you're working on ubuntu or centos?
[14:11] <ogra_> [J]oules_, usually it is "uncomment 4 lines in rsyslog.conf, restart rsyslog"
[14:11] <teward> because if it's not ubuntu i'mma throw you to the ##linux channel.
[14:12] <hehehe> nc -4 -k -l -v localhost 1026
[14:13] <[J]oules_> the box is ubuntu, i am chatting here from it
[14:13] <[J]oules_> ubuntu 16.04 LTS
[14:13] <ogra_> [J]oules_, http://paste.ubuntu.com/25082196/ ... uncomment these four lines (the ones without spaces after the hash sign) in rsyslog.conf and restart rsyslog (works everywhere here ...)
[14:13] <ogra_> and on the sending machine, create a file in /etc/rsyslog.d/ containing one line:
[14:14] <ogra_> *.*   @remote.server:514
[14:14] <ogra_> where "remote.server" is the machine from the first step
[14:14] <[J]oules_> https://www.irccloud.com/pastebin/jHiUD2K7/
[14:14] <ogra_> it isnt different in ubuntu than in any other machine
[14:14] <ogra_> s/machine/linux distro/
[14:15] <hehehe> Joules lol next time say it clearly - I want to send syslog to other machine
[14:15] <hehehe> not I want to test some lan device :D
[14:15] <ogra_> did you try dropping the "AllowedSend
[14:15] <ogra_> er
[14:15] <ogra_> for a test ?
[14:17] <[J]oules_> just did it now ogra_  and restarted rsyslog
[14:17] <[J]oules_> nothing different
[14:18] <ogra_> weird, never had any probs with that
[14:18] <hehehe> provide copy of your firewall rules on both machinese
[14:18] <hehehe> :)
[14:18] <hehehe> machines
[14:18] <hehehe> or use ufw
[14:18] <ogra_> do you have any other modifications of the syslog config ?
[14:18] <[J]oules_> i did enable ufw and enabled 514/UDP and 514/TCP and it still did not work
[14:18] <hehehe> ufw oki
[14:18] <hehehe> *oki
[14:19] <ogra_> any reason to run ufw ?
[14:19] <hehehe> Joules and why 514?
[14:19] <hehehe> ufw is easier
[14:19] <hehehe> thats all
[14:19] <ogra_> sigh
[14:19] <ogra_> hehehe, you are not being helpful
[14:19] <hehehe> Joules you simply want to send syslog from 1 machine to another?
[14:19] <ogra_> [J]oules_, any reason to run a firewall on that machine ?
[14:19] <[J]oules_> https://www.irccloud.com/pastebin/S6cCJ2Sy/
[14:20] <ogra_> (assuming it sits in a LAN that is firewalled anyway from the outside world)
[14:20] <[J]oules_> this ubuntu server is also my workstation. It's behind a mikrtotik router. It is not blocking LAN <-> LAN
[14:21] <hehehe> Joules so what exactly do you want to do?
[14:21] <ogra_> sure, but hopefulls WAN->LAN ;)
[14:21] <ogra_> *hopefully
[14:21] <[J]oules_> hehehe: have my sip phone send it logs via syslog to this ubuntu server/workstation
[14:22] <hehehe> oki
[14:22] <[J]oules_> like i mentioned before, if i set the syslog on the phone to send to one of our pbx's it logs just fine. All our pbx servers are either centos 6 or centos 7
[14:23] <[J]oules_> just this ubuntu server
[14:23] <[J]oules_> i think i will just create a centos 7 vm on this ubuntu server via virtualbox
[14:23] <[J]oules_> this is too much of a PITA
[14:23] <hehehe> https://www.debuntu.org/how-to-remote-syslog-logging-on-debian-and-ubuntu/
[14:23] <hehehe> nah dont give up
[14:23] <hehehe> dont be such quitter :D
[14:25] <ogra_> [J]oules_, http://paste.ubuntu.com/25082249/ ... just uncommenting the four lines and restarting syslog gets me this on 16.04
[14:25] <ogra_> [J]oules_, theer must be something additionally that stops rsyslog from opeing the port
[14:26] <[J]oules_> i do have those lines uncommented
[14:26] <[J]oules_> hehehe:  /etc/default/syslogd  does not exist
[14:26] <[J]oules_> ogra_:  agreed, just dont know what it is
[14:27] <ogra_> yeah ...
[14:27] <[J]oules_> one thing for sure, this ubuntu box is not listening on port 514 udp/tcp
[14:27] <ogra_> well, if you tinkered with firewall stuff it might be related ... though then i would expect at least some complaint from syslog in the logs that it cant bind to the port or some such
[14:28] <[J]oules_> ok i will turn on ufw and then show you
[14:28] <hehehe>  pastebin /etc/rsyslog.d/50-default.conf
[14:28] <hehehe> :)
[14:28] <[J]oules_> https://www.irccloud.com/pastebin/uUW6redV/
[14:28] <[J]oules_> yet nothing comes in...
[14:29] <ogra_> sudo netstat -anp|grep :514
[14:29] <ogra_> ?
[14:29] <[J]oules_> https://www.irccloud.com/pastebin/PwXrSVWQ/
[14:29] <hehehe> this is on receving box?
[14:29] <ogra_> does your host actually listen ?
[14:29] <hehehe> post your 50-default.conf :D
[14:29] <hehehe> to double check
[14:30] <[J]oules_> sudo netstat -anp|grep :514
[14:30] <[J]oules_> [lnb@myomie]:/var/log>
[14:30] <[J]oules_> nothing
[14:30] <ogra_> so rsyslog definitely doesnt listen
[14:30] <[J]oules_> correct
[14:30] <hehehe> then its setup error
[14:30] <hehehe> as simple as that
[14:30] <ogra_> anycomplaints in syslog when you restart it ?
[14:30] <hehehe> *config
[14:30] <[J]oules_> https://www.irccloud.com/pastebin/vr8LHekq/
[14:31] <[J]oules_> i think that rsyslogd should be -r not -n
[14:31] <hehehe> did u use *.* @syslogserverhostname:514 ?
[14:32] <ahasenack> rbasak: I think samba's ubuntu/zesty-devel is behind in the git repository: rmadison shows 17.04.3, but git has 17.04.2 if I'm not mistaken
[14:32] <hehehe> and restart service?
[14:32] <ogra_> [J]oules_, it is -n here as well
[14:32] <hehehe> http://www.randomhacks.co.uk/how-to-configure-an-ubuntu-server-to-log-to-a-remote-syslog-server/
[14:32] <hehehe> :)
[14:32] <hehehe> read this :)
[14:33] <[J]oules_> hehehe: that log to REMOTE
[14:33] <[J]oules_> i need log to LOCAL
[14:33] <hehehe> ogra_: DUDE
[14:33] <hehehe> hmm
[14:34] <hehehe> so sip phone soft running  on same box?
[14:34] <hehehe> right
[14:34] <hehehe> then it would likely have own log
[14:34] <hehehe> somewhere  in configs
[14:34] <ogra_> [J]oules_, anything non-standard  in /etc/rsyslog.d/ ?
[14:34] <hehehe> you dont need to open any ports
[14:34] <hehehe> blah
[14:34] <[J]oules_> ogra_: no
[14:35] <ogra_> any other changes in rsyslog.conf ?
[14:36] <ogra_> http://paste.ubuntu.com/25082303/ is the default config as the package ships it
[14:36] <[J]oules_> telnet localhost 514
[14:36] <[J]oules_> Trying ::1...
[14:36] <[J]oules_> Trying 127.0.0.1...
[14:36] <[J]oules_> telnet: Unable to connect to remote host: Connection refused
[14:36] <rbasak> ahasenack: that's odd. samba is in our whitelist. Shall we wait for nacc to come online and check the importer?
[14:36] <hehehe> remote host?
[14:36] <hehehe> dude u said its local
[14:36] <hehehe> which one is it?
[14:36] <[J]oules_> hehehe: local
[14:37] <[J]oules_> i ran the command from the ubuntu server i am on
[14:37] <ahasenack> rbasak: so you did confirm it's behind?
[14:37] <rbasak> No.
[14:37] <hehehe> Joules so to make it clear you got sip phone one the box and u want it to send its log to syslog on same box?
[14:37] <hehehe> right?
[14:37] <hehehe> *on the box
[14:38] <[J]oules_> sip phone is not a box, its a physical telephone
[14:38] <braziercustoms> Ist that just a generic can't connect message hehehe?
[14:38] <[J]oules_> it is on same LAN as ubuntu server
[14:38] <hehehe> oki
[14:38] <rbasak> ahasenack: yeah confirmed
[14:38] <hehehe> so land hardware sip phone using asterix?
[14:39] <[J]oules_> plain and simple, this ubuntu server is not listening on port 514
[14:39] <ahasenack> rbasak: thanks
[14:39] <[J]oules_> pbx servers are all remote
[14:39] <hehehe> Joules plain and simple unless some server uses 514
[14:39] <ahasenack> rbasak: I'll bring it up in standup, it's just half an hour away
[14:39] <hehehe> some server soft
[14:39] <rbasak> Looks like it was published on the 5th.
[14:39] <hehehe> 514 wont be listening
[14:39] <rbasak> So perhaps the importer wasn't running then?
[14:39] <[J]oules_> hehehe: yes agreed, RSYSLOG
[14:39] <hehehe> braziercustoms: which one
[14:40] <hehehe> Joules this hardware sip phone got a software config file
[14:40] <teward> rbasak: and server team: NGINX 1.12.0-1ubuntu1 (merge from the 1.12.0-1 packaging that was in Debian then replaced with 1.13.x) merge completed, and uploaded.  once that builds and lands, i'll push the latest patch for a security issue (Security team is aware, cc: sbeattie)
[14:40] <hehehe> to where does this config file direct logs?
[14:40] <ogra_> [J]oules_, i'd really start from scratch .. drop all ufw stuff (uninstall it), flush iptables ... and first of all try to get the standard working that works for everyone else
[14:40] <hehehe> maybe it sends them to a separate log file instea of syslog
[14:40] <hehehe> :)
[14:41] <hehehe> and folks anyone here good with git? :D
[14:41] <teward> hehehe: i know a bunch, so does rbasak, what's up?
[14:41] <ogra_> [J]oules_, once you have that, re-enable the firewall bits and configure it (if you really feel you need to dis-trust devices in your LAN that is)
[14:41]  * teward also runs a GitLab instance for himself
[14:42] <ogra_> [J]oules_, on any Ubuntu machine i worked with in the last 13 years just uncommenting the 4 lines and restarting rsyslog was enough, be assured this usually works :)
[14:42] <hehehe> when I do git checkout -b origin and later want to build and make - local box will look for files on the githib repository where branch files are?
[14:43] <hehehe> so say initially I git clone master branch and then I run checkout -b origin
[14:43] <hehehe> to select a specific branch
[14:43] <[J]oules_> ogra_: i cant agree with you more, uncomment those lines and presto
[14:43] <[J]oules_> ogra_: but this box flatly says 'not in my lifetime'
[14:44] <[J]oules_> brb have to help someone
[14:44] <ogra_> well, there must have been some tinkering that broke it i guess
[14:44] <hehehe> Joules post you /etc/rsyslog.d/50-default.conf :)
[14:44] <hehehe> just to check
[14:44] <hehehe> *your
[14:44] <ogra_> hehehe, what would you expect to find there ?
[14:44] <hehehe> I dont know some mistake :)
[14:44] <hehehe> maybe typo
[14:45] <ogra_> then rsyslog would complain in the logs on startup
[14:45] <hehehe> oki
[14:45] <hehehe> so using occam razor what can it be?
[14:46] <rbasak> hehehe: I don't understand your question. What are you trying to achieve?
[14:47] <hehehe> rbasak: oki - I want to compile modsecurity from a specific branch
[14:48] <hehehe> as per howto here https://help.dreamhost.com/hc/en-us/articles/223608748-How-to-Install-libmodsecurity-Nginx-on-Ubuntu-14-04
[14:48] <rbasak> Those instructions look a bit broken to me.
[14:48] <hehehe> yes
[14:48] <rbasak> I wouldn't create a local branch called "origin/v3/master". That's confusing.
[14:49] <hehehe> rbasak: so whats the best way then?
[14:49] <rbasak> git will do it, but thereafter lies confusion.
[14:49] <rbasak> git clone v3/master https://github.com/SpiderLabs/ModSecurity
[14:49] <rbasak> then git submodule init, etc.
[14:49] <rbasak> Sorry
[14:49] <rbasak> git clone -b v3/master https://github.com/SpiderLabs/ModSecurity
[14:49] <rbasak> then git submodule init, etc.
[14:50] <coreycb> jamespage: looks like python-sphinx 1.6.3 upload to experimental is just blocked by sphinxcontrib-websupport in NEW
[14:50] <jamespage> coreycb: ack
[14:50] <hehehe> rbasak: yes thats the command I was missing :)
[14:50] <hehehe> how to git clone a branch :)
[14:50] <hehehe> thanks!
[14:50] <rbasak> You're welcome :)
[14:51] <hehehe> well at least last night I had time to read php intro since I was stuck on this front :)
[14:52] <hehehe> Joules I think if we carefully look at all setup - there is a logical way to find mistake - its just I am new to linux but I can think logically sometimes :)
[15:03] <hehehe> rbasak: usually if make encounter any mistakes it will log then to syslog or not?
[15:03] <hehehe> I wonder how people double check that make run correctly
[15:07] <nacc> rbasak: i made the same importer change for your bugfix locally as soon as i woke up, will ack/merge it now
[15:07] <rbasak> hehehe: if it's done well, it should stop with an error if there's a problem.
[15:07] <rbasak> nacc: thanks!
[15:08] <hehehe> cool
[15:12] <hehehe> is there a simple way to pull all logs (as per user choice) from a box to remote server, as per event (so simply adding new entries to a logs incrementally in real time)
[15:12] <hehehe> or it will consume a lot of client server resources?
[15:13] <nacc> rbasak: done (but you prob. got notified already)
[15:13] <rbasak> hehehe: A periodic rsync is probably the easiest trade-off close to that.
[15:13] <rbasak> nacc: thanks!
[15:19] <gimmic> it is unfortunate that MAAS is free, but Landscape is not
[15:30] <dpb1> gimmic: landscape is free for up to 10 physical hosts and 50 containers
[15:33] <gimmic> Yeah.. Who wants to use an OS management platform for >10 systems?
[15:34] <gimmic> "This car functions, but only drives 10 mph, please pay if you want to go faster than 10 mph"
[15:34] <gimmic> that's a trial.
[15:36] <ogra_> gimmic, well, something has to pay the salaries ;)
[15:38] <ogra_> gimmic, i bet a lot of people would take such a car if you get it for $0 at the vendor and only have to pay if you go above 10mph ;)
[15:38] <gimmic> seems antithetical to the open source community.
[15:38] <nacc> open source != free
[15:39] <ogra_> geez ...
[15:39] <gimmic> You could make the same argument about any of the projects. MAAS could be licensed the same way
[15:40] <ogra_> sure
[15:40] <nacc> gimmic: what argument?
[15:40] <andol> gimmic: If you don't like the way landscape is licenced and/or priced, then don't use it?
[15:40] <nacc> gimmic: i think you are the only making a principled arguemnt here :)
[15:40] <gimmic> :) Just venting an opinion
[15:41] <Ussat> antiethical....seriousely ?
[15:41] <gimmic> not antiethical.. antithetical.
[15:42] <gimmic> Although I guess it's really not any different than the rhel environment
[15:42] <Ussat> I have no problem payinf for software that I use if it gets the job done
[15:43] <nacc> gimmic: it's not different than anyone trying to make money, if you want to use *only* free software, that's a different discussion than relevant here
[15:43] <gimmic> Of course. All I said was that it was unfortunate
[15:43] <Ussat> I dont see how it is unfortunate
[15:44] <Ussat> unless you mean its unfortunate you cant leech
[15:44] <gimmic> that's a bit of a strawman, unless you consider anything you don't exchange money for is leeching
[15:44] <gimmic> back to the opensource ethos..
[15:45] <Ussat> opensource ethos......please
[15:46] <Ussat> I use the best tool for the job. open/closed, it does not matter
[15:46] <nacc> gimmic: again, you're conflating open and free
[15:46] <nacc> gimmic: IMO
[15:47] <gimmic> Yeah.
[16:00] <nacc> rbasak: ahasenack: `git ubuntu lint --for-merge` of the samba merge (so far): http://paste.ubuntu.com/25082678/
[16:00] <nacc> messaging needs some massage
[16:03] <aatish> Hi everyone. i want to install ubuntu server on a HP ProLiant ML10 Gen9. I really need the RAID functionality. I read on forums that i should set controller to AHCI. IS there a workaround? thank you
[16:07] <Ussat> use ahci and Linux raid
[16:08] <Ussat> https://en.wikipedia.org/wiki/Mdadm
[16:08] <rbasak> nacc: nice!
[16:09] <aatish> Ussat, Is there a guide for mdadm?
[16:10] <dpb1> lots of them!
[16:10] <dpb1> the linux raid one is what I remember starting with.
[16:10]  * dpb1 googles
[16:12] <dpb1> here: https://raid.wiki.kernel.org/index.php/RAID_setup
[16:14] <aatish> dpb1, got it. thank you. But now i got the error: variable 'prefix' isnt set :( when installing ubuntu from a usb
[16:25] <nacc> rbasak: do we want emit 'pass' or something for checks that pass?
[16:27] <dpb1> aatish: would need more details.  I'm not familiar with that particular failure mode
[16:27] <rbasak> nacc: I feel that would be more noisy
[16:27] <rbasak> s/more/too/
[16:27] <nacc> rbasak: ack, just checking :)
[16:27] <rbasak> nacc: except maybe with a -v or something?
[16:27] <nacc> rbasak: we can leave it for not
[16:28] <nacc> *now
[16:28] <rbasak> Agreed
[16:28] <nacc> rbasak: about to add the versioning check
[16:28] <nacc> rbasak: reading your code, what function should i call to check the version? i guess for a merge, i should pass the debian version?
[16:28] <nacc> rbasak: next_development_version(debian_version) ?
[16:29] <rbasak> Yes, I think so.
[16:29] <nacc> rbasak: ack, doing it now
[16:31] <[J]oules_> created a new ubuntu 16.04 lts server. uncommented the 4 lines in rsyslog.conf, restarted rsyslog, phone IS logging to the new ubuntu server
[16:31] <[J]oules_> something on this ubuntu server is not working right and is blocking incoming syslog
[16:37] <nacc> rbasak: did you ever figure out what you meant by unapproved in http://paste.ubuntu.com/25039931/ ?
[16:41] <rbasak> nacc: I think I must have meant the version in the unapproved queue, but then changed tack and now intend it to mean the version currently highest in the given series.
[16:41] <rbasak> nacc: maybe s/unapproved/current/ unless you can think of something better than "current"?
[16:42] <nacc> rbasak: but w/in the context of the importer, that function can obtain the value of uannproved given a repository and a series name (aiui)?
[16:42] <nacc> rbasak: or do you want to query lp for it?
[16:42] <rbasak> before = [max(series.pocket_versions) for before_series in serieses if before_series < series]
[16:42] <nacc> rbasak: and/or what does after mean?
[16:42] <rbasak> sorry: before = [max(before_series.pocket_versions) for before_series in serieses if before_series < series]
[16:43] <rbasak> sorry: before = [max(after_series.pocket_versions) for after_series in serieses if after_series > series]
[16:43] <rbasak> Argh
[16:43] <rbasak> Take 3:
[16:43] <nacc> heh
[16:43] <rbasak> before = [max(before_series.pocket_versions) for before_series in serieses if before_series < series]
[16:43] <rbasak> after = [max(after_series.pocket_versions) for after_series in serieses if after_series > series]
[16:44] <nacc> so we're trying to use that to sandwich our versioning, in case the prior series has bumped, etc/
[16:44] <rbasak> nacc: does that make sense?
[16:44] <rbasak> Right
[16:44] <nacc> e.g., to detect if we need to do 16.04.1 rather than .1
[16:44] <nacc> rbasak: ok, that makes sense
[16:44] <rbasak> And current (formerly unapproved) = max(series.pocket_versions)
[16:45] <nacc> right, i guess in my mind, this (next_sru_version) is a lower level API and the actual api is (next_sru_version(series)()
[16:45] <rbasak> Yes. That's reasonable.
[16:45] <nacc> as the above values for a repo are all derivable given the series :)
[16:45] <rbasak> Your actual API would look up in Launchpad.
[16:45] <nacc> yep
[16:45] <rbasak> And my lower level API is the pure testable version comparison bit.
[16:45] <nacc> understood
[16:47] <rbasak> nacc: a reminder: I believe next_sru_version is incomplete. But we can use it and add test/fix when we hit those cases for now I guess.
[16:47] <nacc> rbasak: ack
[16:47] <rbasak> Yeah it doesn't actually examine before or after at all.
[16:49] <nacc> right, but the spec means it can (and should eventually) :)(
[16:49] <nacc> s/(//
[16:50] <nacc> rbasak: fyi, i have a commit in this series which turns GitUbuntuRepository into a wrapper for pygit2.Repository. It's really handy (and let's us drop a bunch of accessor properties). But now if we need some pygit2.Repository function/attribute, it's just  there immediately
[16:52] <rbasak> I do think that the wrappers are not worth it any more.
[16:52] <rbasak> But why not just expose the underlying pygit2.Repository object as a well known property to GitUbuntuRepository?
[16:53] <nacc> rbasak: that's basically the same thing in this case
[16:53] <rbasak> So just switch from _local_repo to raw_repo or something.
[16:53] <nacc> rbasak: we do that already
[16:53] <nacc> but no caller actualy needs that object
[16:53] <nacc> they need some method or attr of that object
[16:53] <rbasak> Yes but it's explicit then.
[16:53] <rbasak> A caller will do repo.raw_repo.foo()
[16:54] <nacc> rbasak: tbh, i think what i have is a lot cleaner than expecting callers to know if something is a method of repo or of repo.raw_repo
[16:54] <rbasak> I'm not keen on inheritance or __getattr__ magic if that's the way you're thinking.
[16:54] <nacc> rbasak: ok, is there a specific reason?
[16:54] <rbasak> I disagree. It means that someone less familiar with the code and APIs won't know where to look to find a particular implementation of something.
[16:55] <rbasak> The name raw_repo could be better.
[16:55] <rbasak> Also it means that if we need to change something, it's easier to find what callers are doing by just searching for raw_repo.
[16:55] <nacc> i give you the latter point
[16:56] <nacc> i suppose it's not a big deal either way -- i found the wrapper object pattern handy to not have to type so much and to not have to add any new methods. It's implicit, though, as you suggest, and I can make it explicit instead
[16:58] <nacc> rbasak: i'll retool the change, thanks for the feedback
[17:01] <dannf> hey dpb1 - would you be able to seed numactl for the 16.04.3 server iso now that the MIR is approved?
[17:02] <nacc> dannf: we discussed it this AM in our standup
[17:02] <nacc> rbasak: --^
[17:02] <nacc> dannf: would be good to subscribe the server team to that bug to get our attention
[17:02] <dannf> nacc: ok
[17:03] <dpb1> dannf: thsx
[17:09] <rbasak> dpb1: so the question for you here is: are you willing for your team to take on the maintenance for this?
[17:10] <rbasak> (from a general process perspective)
[17:10] <nacc> and shouldn't that have been resolved in the MIR rather than in the seeding discussion?
[17:10] <rbasak> Really that should happen before the MIR approval...
[17:10] <rbasak> Yeah
[17:10] <nacc> i guess the theory was src:numactl is main'd, so we are on the hook for it already
[17:10] <nacc> but i don't think server is subscribed to src:numactl
[17:10] <nacc> not sure if anyone is?
[17:10] <rbasak> It missed it in this case because our process (the team bug subscription being the gate) doesn't account for binary only movements.
[17:11] <nacc> oh we are, nm
[17:11] <rbasak> Another example of this is php fpm, which has a bigger maintenance issue.
[17:12] <rbasak> Perhaps the MIR process should have a requirement for a documented team commitment in addition to the subscription.
[17:15] <rbasak> cyphermox: FYI ^
[17:19] <cyphermox> well, in a way we do, that's why I'm asking if you guys are aware of that request for numactl (which is already in main)
[17:20] <cyphermox> numactl was MIRed some time ago already, the other MIR was to make sure the binary numactl package was also promoted, and then seeding (which triggers me checking that it's really what you want)
[17:21] <ahasenack> nacc: ok for me to push the tags on that samba merge branch? Or should I leave it as is?
[17:21] <nacc> ahasenack: you can push it
[17:22] <ahasenack> nacc: old/debian new/debian old/ubuntu reconstruct/<ubuntu version> \
[17:22] <ahasenack> deconstruct/<ubuntu version> logical/<ubuntu version> ?
[17:22] <ahasenack> these, right?
[17:22] <cyphermox> rbasak: in my view, MIR doesn't need to gate on something being seeded, as if it's not, things will just get migrated back to universe anyway next time someone goes to look at component-mismatches
[17:22] <nacc> ahasenack: yeah
[17:22] <rbasak> cyphermox: it's not gating on something being seeded I'm requesting. But I do think that MIRs should be gated on a team committing to support it.
[17:23] <rbasak> Usually the team subscription check suffices for that.
[17:23] <rbasak> But not for a binary only movement, as in this case.
[17:23] <cyphermox> rbasak: it is
[17:23] <cyphermox> if you already subscribed to the source, why would you not maintain also one of the binaries that come from it?
[17:23] <rbasak> cyphermox: take php fpm as an example.
[17:23] <cyphermox> you'll need to look at the bugs anyway
[17:23] <rbasak> cyphermox: https://bugs.launchpad.net/ubuntu/+source/php7.0/+bug/1267255
[17:24] <rbasak> cyphermox: in that case, we're not prepared to have a mess dropped on us.
[17:24] <ahasenack> nacc: pushed
[17:25] <rbasak> Once the issues are fixed (by us or others), then we can consider what burden ongoing maintenance of that binary might have on our team.
[17:25] <cyphermox> rbasak: we review the things every time there is a MIR anyway
[17:25] <cyphermox> so if it looks like a mess, it seems rather obvious that one should double-check
[17:25] <rbasak> cyphermox: sure. What I'm asking is an explicit gate on the team who is being given the work.
[17:25] <cyphermox> I mean, I don't disagree that I would check with you guys again if some random person asks for a new binary in a huge package that looks like a mess
[17:26] <cyphermox> in the case of numactl however, it's a tiny thing
[17:26] <rbasak> I agree it probably doesn't matter for numactl.
[17:26] <cyphermox> (in the grand scheme of already maintaining libnuma, which is where the magic really happens)
[17:26] <rbasak> But from a process perspective, I'm pretty sure that's a hole.
[17:26] <cyphermox> what do you mean?
[17:26] <rbasak> Through which something big will slip sooner or later, as it's not a documented part of any process.
[17:27] <cyphermox> anything that looks messy in a package in a big red flag anytime you review a MIR
[17:27] <rbasak> That decision should be down to the team being landed the work, not the MIR team.
[17:28] <cyphermox> yes
[17:28] <cyphermox> if the team isn't asking for the MIR themselves, we check
[17:28] <rbasak> It shouldn't rely on the MIR team deciding if something has a red flag or not.
[17:28] <rbasak> The decision should go to the subscribing team in all cases.
[17:28] <cyphermox> in all cases, the MIR team is supposed to do a check that something is generally maintainable without too much pain
[17:29] <rbasak> That's not what I'm asking for.
[17:29] <rbasak> In all cases, I'd like the MIR team to check that the subscribing team is OK with the MIR.
[17:29] <cyphermox> presumably, if you're writing the MIR for your team, you're already OK with it?
[17:29] <rbasak> In this case, the MIR wasn't written by us.
[17:29] <nacc> cyphermox: in this case, we didn't write the MIRs
[17:29] <nacc> in either of these two cases, actually
[17:30] <cyphermox> which one are we looking at?
[17:30] <rbasak> Both numactl and fpm.
[17:30] <cyphermox> I'd rather we deal with numactl as a different case, since src:numactl was already reviewed before
[17:30] <rbasak> I disagree.
[17:30] <cyphermox> again, this one is a tiny binary, and the real magic happens in the lib
[17:30] <rbasak> numactl is an example of exactly the case where the hole in the process is present.
[17:31] <cyphermox> and fpm is not?
[17:31] <rbasak> It's also present for fpm.
[17:31] <rbasak> The two examples are in the same category: binary only movement.
[17:31] <rbasak> In all cases, I'd like the MIR team to check that the subscribing team is OK with the MIR.
[17:31] <cyphermox> I don't think you're looking at things the right way
[17:31] <cyphermox> I don't care if it's binary only or what, a MIR request is a MIR request, the package should be reviewed
[17:31] <rbasak> Do you disagree with this statement?
[17:32] <rbasak> Sure, by all means, review it.
[17:32] <cyphermox> I don't
[17:32] <rbasak> I'm not saying that you shouldn't review it.
[17:32] <cyphermox> I agree, the subscribing team should be OK with the MIR
[17:32] <rbasak> I'm saying that as part of the review I'd like the MIR team to check that the subscribing team is OK with the MIR before approving it.
[17:32] <cyphermox> heh, fine
[17:33] <cyphermox> my point in numactl is so tiny it's ridiculous to do back-and-forth about it aside from whether you really want it to be seeded, as the seeding or depends is what will really make it stay in main
[17:33] <cyphermox> that definitely doesn't apply to anything with php in the name
[17:33] <dpb1> right, that was my understanding
[17:33] <dpb1> almost a no brainer
[17:33] <rbasak> I accept that it seems ridiculous for numactl if you consider that case on its own.
[17:33] <rbasak> My point is that we should agree the general case while we're here.
[17:34] <dpb1> I thought it was the general case, actually, this is the first one I have seen
[17:34] <cyphermox> rbasak: I'm not, I'm talking generally, tiny things that seem obvious are obvious. Things that require a bit more thought, you ask the team responsible, especially if the team didn't create the MIR themselves.
[17:35] <rbasak> The fpm example is one I happened to spot during triaging. I suspect it'd have gotten approved without consultation with the server team had I not noticed.
[17:35] <cyphermox> ie. if you file a MIR for something php and the team is subscribed already, I will review and expect that you didn't file the MIR for kicks
[17:35] <cyphermox> rbasak: I strongly disagree
[17:35] <rbasak> Sure. If you see that comments are made by active/responsible members of ~ubuntu-server, you can take that to mean that we're OK with it.
[17:35] <cyphermox> anything php is a huge ugly in my mind
[17:36] <cyphermox> so we agree
[17:36] <rbasak> cyphermox: it may be for you, but others have different thinking processes.
[17:36] <rbasak> That's why we have a written list of requirements - so that your predecessors, you, and your successors will all be able to be consistent.
[17:36] <rbasak> *You* may not have approved it, but someone else might have.
[17:36] <cyphermox> rbasak: I think doko works the same way, though I haven't seen his MIR reviews recently
[17:36] <sarnold> btw what's the sticking point with fpm? it feels better to me than executing php directly in e.g. apache's address space
[17:36] <rbasak> That's why I'd like this check to be explicit in the process.
[17:36] <rbasak> sarnold: just a pile of bugs that I'd like to see fixed.
[17:36] <cyphermox> rbasak: that is the extent of the MIR team, if we don't count nacc who we've been trying to onboard
[17:37] <sarnold> rbasak: aha :)
[17:37] <rbasak> sarnold: so we might well end up doing it, it's just another thing on the backlog.
[17:37] <cyphermox> nacc: speaking of that, sorry, I kind of just pushed some wiki pages to you and didn't get back on that
[17:37] <nacc> cyphermox: it's ok, we've all ben busy :)
[17:37] <rbasak> cyphermox: like I say: it's not just who's on the MIR team today. It's about who will be on it in five years' time.
[17:38] <cyphermox> rbasak: if you think it's insufficiently obvious, you can add it to the wiki
[17:38] <cyphermox> or better, nacc can write it in the perspective of someone very new to the MIR team
[17:38] <rbasak> cyphermox, nacc: please :)
[17:39] <cyphermox> rbasak: I rather rely on the good sense of people on the team, given that they are appointed specifically for their good sense
[17:39] <cyphermox> or, "rely" is perhaps not the right word
[17:40] <cyphermox> but I trust others on the team to be able to use their own judgement when reviewing MIRs
[17:40] <rbasak> cyphermox: sure, though there's also a written checklist of things to verify. Someone with good sense might assume that the process is designed to catch mundane errors, and so not think too hard about this kind of edge case.
[17:40] <cyphermox> rbasak: well, the MIR team's mandate is not to catch mundane errors really
[17:40] <rbasak> We have a checklist; this is missing from the checklist; therefore we should add it to the checklist.
[17:41] <rbasak> cyphermox: I'm defining missing checking to see if the team has committed as a mundane error.
[17:41] <cyphermox> it's to make sure that things that make it to main are maintainable in main, and won't cause us pain in the long run. I think that goes with making sure those who are signed up to maintain a package know that they are signed up for it and agree to it
[17:41] <rbasak> Right, and therefore it should be in the checklist.
[17:41] <rbasak> Right now, it's not.
[17:42] <rbasak> QED.
[17:42] <nacc> rbasak: for next_sru_version, is it sufficient to check active series only? or do we need to check any published series?
[17:42] <cyphermox> rbasak: the MIRTeam wiki page is not a checklist.
[17:42] <cyphermox> rbasak: more like guidelines of known issues. It could never contain all things to check and be relied on to catch all issues
[17:42] <cyphermox> so like I said, if you think it needs to be added, fine, I'll never be against that
[17:43] <cyphermox> but in some cases it's important to be flexible too, and things in that list of red flags may be acceptable given some packages and horribly bad given others
[17:44] <cyphermox> rbasak: similarly, as an archive admin if you catch something reviewing a MIR to do the promotion dance that was missed and isn't on the wiki page, by all means you should add it
[18:08] <nacc> ahasenack: do you have a pending MP that fixes a bug i can lint?
[18:09] <ahasenack> nacc: does it have to be a debian merge?
[18:09] <nacc> ahasenack: no, specifically not a merge, if possible
[18:09] <nacc> ahasenack: as in, a bugfix MP
[18:09] <ahasenack> nacc: https://code.launchpad.net/~ahasenack/ubuntu/+source/samba/+git/samba/+merge/326073
[18:10] <ahasenack> nacc: another one: https://code.launchpad.net/~ahasenack/ubuntu/+source/squid3/+git/squid3/+merge/326860
[18:11] <nacc> ahasenack: thanks
[18:21] <nacc> ahasenack: hrm, your new/debian is still pointing to the wrong point
[18:21] <ahasenack> in samba?
[18:21] <nacc> it's at -2 and -3 is in debian :)
[18:21] <nacc> ahasenack: yeah
[18:22] <ahasenack> hm
[18:22] <ahasenack> I have a bunch of samba branches, I just updated the merge one I think
[18:22] <ahasenack> but wait, this is only about the merge branch, right?
[18:22] <nacc> ahasenack: http://paste.ubuntu.com/25083516/
[18:22] <nacc> ahasenack: yeah
[18:22] <ahasenack> locally I have:
[18:22] <ahasenack> f717b66 (tag: pkg/import/2%4.6.5+dfsg-2, tag: new/debian, tag: ahasenack/new/debian) Import patches-unapplied version 2:4.6.5+dfsg-2 to debian/sid
[18:23] <ahasenack> let's see
[18:23] <ahasenack> f8ed728 (tag: pkg/import/2%4.6.5+dfsg-3, pkg/debian/sid, debian/sid) Import patches-unapplied version 2:4.6.5+dfsg-3 to debian/sid
[18:24] <ahasenack> ok, I rebased that one on debian/sid
[18:24] <ahasenack> should I just run that git ubuntu merge command with the tags-only parameter?
[18:25] <nacc> ahasenack: it's ok for now
[18:25] <nacc> ahasenack: i mean, the linter is rightfully complaining :)
[18:25] <nacc> ahasenack: let's leave it for a bit
[18:25] <ahasenack> good :)
[18:25] <ahasenack> hey, every linter needs a failing test case :)
[18:28] <rbasak> nacc: sorry, connection flapping
[18:28] <rbasak> 18:43 <rbasak> Good question
[18:28] <rbasak> 18:43 <rbasak> I think we need to go backwards until we see a version that is lower than the current version (in the proposed series).
[18:28] <nacc> ahasenack: :) ... and line 3 was a bug in my code
[18:29] <rbasak> 18:44 <rbasak> It might be easier to just do all series.
[18:29] <rbasak> 18:44 <rbasak> Though that is a little unbounded, so I don't like it.
[18:29] <nacc> rbasak: in order to support eol folks dtrt?
[18:30] <nacc> rbasak: also, in http://paste.ubuntu.com/25083516/, should we allow for an empty newline in a second hunk relative to merge-changelogs?
[18:32] <nacc> oh it's a bug in git ubuntu merge :/
[18:48] <hehehe> rbasak if I get make error make: *** No rule to make target '3317'.  Stop. - any idea how to debug it? I am following same tutorial, configured nginx with modsecurity nginx module and not run make
[18:48] <hehehe> *and now
[18:48] <hehehe> http://nginx.org/en/download.html
[18:48] <hehehe> sorry https://help.dreamhost.com/hc/en-us/articles/223608748-How-to-Install-libmodsecurity-Nginx-on-Ubuntu-14-04 :)
[18:50] <nacc> hehehe: you should ask the owner of the software you are trying to build how to build it
[18:50] <hehehe> yes I did try to ask in #nginx its difficult to get reply :)
[18:51] <hehehe> I was thinking maybe i can debug myself
[18:51] <sarnold> I bet they respond better to pastebins that show commands and error output
[18:51] <hehehe> I take you bet :)
[18:51] <hehehe> how much you bet :D
[18:51] <hehehe> I bet 1 kg of banana
[18:51] <sarnold> I hate bananans no thanks that's not a bet I want to win
[18:52] <hehehe> lol really?
[18:52] <hehehe> whats your fav fruit then?  and dont say its stake :)
[18:52] <hehehe> steak
[18:52] <sarnold> mmm steak
[18:53] <nacc> hehehe: debugging a build error requires understanding what make was trying to run and why
[18:53] <nacc> hehehe: your oneline of output is completely insufficient for that
[18:53] <hehehe> agree
[18:53] <hehehe> sarnold: lol when i was like 10 I loved steaks
[18:54] <hehehe> anyways I managed to make it
[18:54] <hehehe> @ nginx etc
[18:54] <hehehe> who here uses grantite to monitor ubuntu server?
[18:55] <hehehe> mainly to see bottlenecks
[19:17] <hehehe> no one? :P
[19:17] <hehehe> o wel
[19:29] <nacc> ahasenack: http://paste.ubuntu.com/25083923/
[19:29] <nacc> dpb1: --^ lint running against andreas' branch
[19:34] <ahasenack> nacc: is there a --verbose to see what checks it did?
[19:34] <ahasenack> looks nice!
[19:37] <nacc> ahasenack: not yet :)
[19:37] <nacc> ahasenack: i think i will add that as it's confusing for now to not see what passes :)
[19:37] <ahasenack> nice
[20:03] <DammitJim> how do I know if the samba I installed was compiled using embedded heimdal kerberos?
[20:03] <DammitJim> apparently there is a new security update from samba for those versions
[20:07] <ahasenack> I'm not sure
[20:08] <ahasenack> I think that samba AD DC will use that heimdal
[20:08] <ahasenack> samba's ./configure doesn't mention this explicitly, there is only an option to build *without* samba ad dc
[20:08] <ahasenack> support
[20:09] <ahasenack> found this:
[20:09] <ahasenack> "we support building against a Heimdal or system MIT
[20:09] <ahasenack> Kerberos library, provided the version is recent enough (otherwise we
[20:09] <ahasenack> will use our internal version of Heimdal)"
[20:09] <DammitJim> ahasenack, you are right
[20:09] <DammitJim> I just found info on that and I'm using samba with kerberos for work with AD
[20:09] <ahasenack> and that samba ad dc funcionality requires heimdal (doesn't work with mit)
[20:09] <DammitJim> where can I see when Ubuntu releases a patch?
[20:10] <ahasenack> work *with* AD is different
[20:10] <ahasenack> even samba3 had that as a client/member
[20:10] <DammitJim> oh
[20:10] <DammitJim> then how can I verify I"m using that flavor of samba?
[20:10] <ahasenack> it's CVE-2017-11103 right?
[20:11] <DammitJim> yeah
[20:11] <DammitJim> I think Debian doesn't even have that patched
[20:11] <ahasenack> better ask in #ubuntu-hardened, that's the secteam channel
[20:11] <DammitJim> thanks ahasenack
[20:13] <ahasenack> I'm not yet fully versed on samba acting as an AD DC
[20:14] <ahasenack> and it's not clear to me if that vuln affects the client or the server. I think it's client
[20:14] <ahasenack> "Use of the unencrypted version provides an opportunity for successful server impersonation and other attacks"
[20:16] <DammitJim> I'm pretty sure we are using that
[20:16] <DammitJim> but samba is not exposed to the outside world
[20:18] <DammitJim> yeah, this is kinda confusing because I don't know that we do DRS replication service for replication of passwords
[20:19] <ahasenack> DammitJim: what ubuntu release are you on?
[20:19] <DammitJim> LST 14 and 16
[20:19] <ahasenack> trusty and xenial you mean?
[20:20] <DammitJim> yes
[20:22] <ahasenack> DammitJim: you use winbind then?
[20:22] <DammitJim> yeah
[20:25] <ahasenack> samba does ship what looks like its own kerberos libraries
[20:25] <ahasenack> like
[20:25] <ahasenack>  /usr/lib/x86_64-linux-gnu/samba/libcom_err-samba4.so.0
[20:25] <DammitJim> yes
[20:25] <ahasenack>  /usr/lib/x86_64-linux-gnu/samba/libkrb5-samba4.so.26
[20:25] <ahasenack> and others
[20:26] <ahasenack> and winbind and other tools are linked to that
[20:26] <DammitJim> yes, it's actually a lot that one configures to use AD authentication
[20:26] <ahasenack> so I'd say it's affected yes
[20:26] <DammitJim> I think I'm going to have to schedule patching since I'm not 100% sure
[20:27] <ahasenack> ubuntu also has the heimdal code as separate packages, I just wasn't sure which one samba was using
[20:27] <ahasenack> i.e., if updating just the system heimdal would suffice to close the bug for samba
[20:27] <ahasenack> *looks* like no, but I will defer to the security team's evaluation
[20:27] <DammitJim> yeah, I asked them and they said it's in progress
[20:29] <ahasenack> DammitJim: found this: https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-11103.html
[20:30] <DammitJim> so, needs triage means it needs to be worked still
[20:31] <ahasenack> I think so
[20:31] <ahasenack> you can check the status there
[20:31] <DammitJim> what is DNE?
[20:31] <ahasenack> I'm guessing "does not exist", but better ask
[20:32] <hehehe> :)
[20:49] <DammitJim> is there a reason why I would want to use ubuntu-server vs ubuntu-desktop for a database server?
[20:50] <hehehe> yes
[20:50] <hehehe> less libraries
[20:51] <hehehe> so less potential holes
[20:52] <DammitJim> thanks
[20:52] <DammitJim> any other?
[20:54] <hehehe> it will be a bit faster
[20:54] <hehehe> eat less ram :D
[20:57] <hehehe> and sarnold try to ask for any advice in nginx channel and see :)
[20:57] <hehehe> its veryyy slow
[20:59] <DammitJim> sarnold, patch nginx on your ubuntu server, dude ;)
[21:05] <sarnold> DammitJim: eh?
[21:31] <Epx998> more driver woes :D
[21:32] <ZSplat> I need some help.  I have a 16.04 server that has ceased to allow write access, even with sudo and multiple reboots.  Two 3TB drives are LVM'd  together, smartctl from recovery says both drives pass.
[21:32] <Epx998> Nothing in dmesg after boot?
[21:33] <ZSplat> Epx998 http://sprunge.us/ZAQb
[21:33] <sarnold> definitely check dmesg
[21:33] <ZSplat> I didn't see anything
[21:33] <ZSplat> But I'm not amazing
[21:33] <sarnold> [    9.347176] EXT4-fs (dm-0): Couldn't remount RDWR because of unprocessed orphan inode list.  Please umount/remount instead
[21:33] <Epx998> what does sudo mount -o remount,rw / do?
[21:33] <Epx998> aha logs ftw
[21:34] <sarnold> Epx998: uncanny -o remount,rw advice :)
[21:35] <ZSplat> Doing it, just a sec
[21:36] <ZSplat> "mount: / not mounted or bad option"
[21:36] <ZSplat> sarnold
[21:37] <sarnold> :(
[21:37] <Epx998> toshiba drive, udma133 wowza
[21:37] <sarnold> I think I'd boot into a USB stick, fsck the thing
[21:38] <ZSplat> Is that a bad kind of drive to have?
[21:38] <ZSplat> It's a remote server, but I can boot into a recovery
[21:38] <Epx998> im not a fan of toshiba, we do a lot of new hardware POC here and tosh's always give me headaches
[21:38] <Epx998> im sure its a good drive :D
[21:39] <sarnold> aside frmo the deathstars I think I always had good luck with toshibas
[21:39] <ZSplat> btw, here's dmesg | tail -50 from that http://sprunge.us/iCRO
[21:40] <sarnold> very confusing
[21:40] <Epx998> sarnold: you'll like this driver issue, im testing out un-released HP hardware on UB12 :D
[21:40] <ZSplat> So that unprocessed orphan inode list thing is the likely culprit?
[21:40] <sarnold> Epx998: sheeeesh
[21:40] <sarnold> ZSplat: yes
[21:40] <ZSplat> thanks, I'll do some digging
[21:42] <Epx998> ZSplat: did you hard power off before or something?
[21:42] <ZSplat> Epx998 , I don't have physical access to it, it's in a data center.  But not that I am aware of.
[21:42] <Epx998> hope you have idrac or ilo access :D
[21:44] <ZSplat> Epx998 , I can boot to a rescue OS.  Doing that now
[21:45] <ZSplat> Epx998 https://puu.sh/wIRCL/de084ec098.png
[21:45] <Epx998> fancy
[21:45] <sarnold> that's beautiful
[21:46] <Epx998> our guys in austin still use flash drives to deploy *nix servers .....
[21:47] <sarnold> Epx998: they may like to skim the maas docs while waiting for slow-ass usb read speeds one of these days :)
[21:49] <ZSplat> ok, here's my lsblk: http://sprunge.us/TCQDso am I just going to '#fsck
[21:49] <ZSplat> oops
[21:49] <ZSplat> mangled
[21:50] <ZSplat> Am I just going to '#fsck /dev/sda1' then '# fsck /dev/sdb1'?
[21:50] <ZSplat> This is what I get in either instance: https://puu.sh/wIRU8/4e6ca21817.png
[21:51] <Epx998> i honestly dont use fdisk often
[21:51] <ZSplat> nor do I, lol
[21:51] <Epx998> what does fdisk /dev/sda do?
[21:51] <ZSplat> e2fsck: Cannot continue, aborting.
[21:52] <ZSplat> \/dev/sda is in use
[21:52] <ZSplat> That makes no sense because "umount: /dev/sda: not mounted"
[21:52] <ZSplat> Right?
[21:53] <ZSplat> sarnold
[21:53] <sarnold> ZSplat: the errors came from vg something or other right?
[21:54] <sarnold> ZSplat: or md?
[21:54] <sarnold> sigh stupid memory
[21:54] <sarnold> anyway, the errors were on some raidy-thing, not directly from the block devices
[21:54] <ZSplat> It's an LVM of two drives
[21:54] <ZSplat> Ok, so I need to fsck the LV?
[21:54] <sarnold> yeah
[21:55] <ZSplat> heh, ok
[21:58] <ZSplat> Looks like we might be in business - https://puu.sh/wISgC/7283b24303.png
[22:01] <Epx998> whats the server do?
[22:01] <Epx998> im just being nosey btw
[22:02] <ZSplat> http://sprunge.us/dcdb
[22:02] <ZSplat> Epx998 Plex, rtorrent, sickrage, couchpotato, ZNC, and a few other things
[22:02] <ZSplat> Nextcloud
[22:03] <Epx998> interesting
[22:03] <ZSplat> I used to piece it all together myself, this time I just used the quickbox script - quickbox.io
[22:06] <ZSplat> EVERYTHING WORKS AGAAAAAAIIIIN
[22:07] <Epx998> ZSplat: woot thats the best kind of result
[22:07] <ZipSplat> Epx998, and now I'm back through ZNC
[22:08] <Epx998> now make this 408i controller work for me
[22:11] <sarnold> ZipSplat: sweet :)
[22:12] <sarnold> ZipSplat: Ican't recall if fsck makes it explicit if it re-parents objects to lost+found or not -- go looking through the lost+fond directories and make sure nothing shows up
[22:15] <ZipSplat> sarnold, if lost+found is empty then... am I good?
[22:16] <sarnold> yeah
[22:16] <sarnold> well, the fsck shows things -were- wrong, you might ye find files shorter than you expect, or wrong data, or whatever, but there's not much you can do about that except compare against backups
[22:21] <hehehe> :))))))))))))))))))))))))))))))))))
[22:53] <Epx998> Getting a weird message, "Volume group name already in use" on a new deploy - should be no VG's on these disks
[22:54] <Epx998> VG is specified in my preseed, but if kicks me out, wht wouldnt i be able to set a different name manually
[22:55] <Epx998> wonder if the clear isnt working correctly
[23:20] <tomreyn> Epx998: is the vg name something generic? something which might already be present in /dev ?
[23:20] <tomreyn> e.g. 'null' or 'sda'
[23:52] <nacc> rbasak: did you want to do a sync real quick? I'm about to EOD