[11:31] <aeon90> when installing slurm on ubuntu 18.04, how are you supposed to start slurmd and slurmctld? I can start them manually in the terminal, but systemd fails to start them, they simply time out
[14:25] <frickler> jamespage: coreycb: just stumbled about this old issue when updating our cookbooks for stein, any chance this still can get resolved? https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1567935
[15:32] <teward> does anyone know if the Apache web server sets up `www-data` user if the user/group don't already exist?
[15:32] <teward> need some server team input on some things
[15:32] <teward> cc sarnold
[15:35] <rbasak> teward: I'm not sure without looking, but you might find https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes helpful.
[15:36] <teward> yeah i know those classes...
[15:36] <teward> rbasak: the core problem is...
[15:36] <teward> bug #1860388
[15:36] <teward> where MaaS deploy fails because user removed www-data
[15:36] <teward> question is whether there's anything stopping us from recreating it, though I'm not fond of 'forcing' a user into existence if it's been removed by another process
[15:37] <teward> (the core problem there is there's some atypical 'user provided hardened ubuntu image' that has the default users in 0-99 UID groups stripped out
[15:37] <teward> and that's caused the issue.  Not sure it's an *nginx package fixable issue* though)
[15:38] <rbasak> Is www-data created by base-files?
[15:40] <teward> not sure
[15:41] <rbasak> It might be the installer
[15:41] <rbasak> https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes says only that "new ids in this range being added automatically as the base-passwd package is updated"
[15:42] <teward> base-passwd is different than base-files at source
[15:42] <rbasak> I'd say the bug is invalid then, just on the basis that www-data is globally allocated and is in passwd and group of all Debian systems by Debian policy. Removing that breaks your system and it's reasonable for packages to assume that they are present.
[15:42] <teward> checking base-passwd
[15:42] <rbasak> I can write that in the bug if you like.
[15:43] <teward> www-data is created by base-passwd
[15:43] <teward> so then yes, this would be a 'you broke your system' state.
[15:43] <teward> please do
[15:43] <teward> you'll word it better than I will :P
[15:43] <teward> *is exhausted*
[15:46] <teward> rbasak: mdeslaur at 'a glance' seems to agree with us that this is User Error
[15:46] <teward> and not something the packages should be fixing esp. since base-passwd populates those user datas, and not something we should be fixing if the user wants to torch their system :p
[15:47] <teward> which means that's the basis of 'Invalid'.  Have fun writing it up, I'm going to go find the nearest hard surface to blast my head through (E:ROUGHWEEK)
[15:49] <teward> rbasak: mdeslaur: well, this is explicitly *in* the Debian Policy:  Packages other than base-passwd must not modify /etc/passwd, /etc/shadow, /etc/group or /etc/gshadow.   **In theory** we could reject on that, since nginx asserting www-data exists would alter those files.  (9.2.1)
[15:49] <teward> esp. if it has to add that.  Ultimately, still user error :P
[15:50] <mdeslaur> well, I think that means modify the files directly without using a tool
[15:51] <rbasak> Yeah - plenty of packages modify /etc/passwd (indirectly) to ensure that a user they need exists
[15:51] <rbasak> If you want to use that interpretation, all those packages would be buggy and there'd be no way for packaging to do that.
[15:51] <teward> true.  (I'm tired, sue me xD)
[15:52] <rbasak> I have commented on the bug and marked it Invalid for nginx
[15:54] <teward> thank you very much
[15:54] <teward> *goes to find the largest cup of coffee he can in the workplace to consume it*
[15:58] <mdeslaur> teward: sounds like you need a shot of espresso with a coffee chaser ;)
[15:58] <teward> nah what i need is an extra five hours sleep
[15:58] <teward> if i had my way i'd have five shots of espresso
[15:59] <teward> three lattes
[15:59] <teward> and coffee
[17:41] <supaman> on a computer using ufw, would ufw deny IP, deny all connections from that computer to that IP?
[17:54] <Chuckfu> question, I have a ubuntu server 18.04 I have enable ufw and am trying to receive mail from an application who's log says the connection is being refused, I added port 587 by doing the following as root ufw allow 587/tcp says it updates any ideas
[17:56] <Chuckfu> beware I am a newbie trying to learn this by doing
[18:30] <supaman> Chuckfu: if you issue 'sudo ufw status' you should see a line on the note of '587    ALLOW    Anywhere'
[18:33] <Chuckfu> it show it ALLOW anywhere, but a telnet into that port 587 is still refused while on another system connect fine, really weird, probably something small I'm missing
[18:34] <jdstrand> Chuckfu: you should be able to see if another port needs to be opened (eg, port 25) too by looking at firewall denials in /var/log/ufw.log or dmesg
[18:36] <Chuckfu> I'll do
[18:37] <supaman> that depends on loglevel right?
[18:37] <Chuckfu> when I make change to ufw do I need to restart it
[18:37] <Chuckfu> ufw that is
[18:38] <supaman> I have mine set to low and don't see any logging when I issue a command that is blocked by firewall
[18:39] <Chuckfu> how did you set it to low
[18:39] <supaman> Chuckfu: nope, don't need to do that. ufw updaes the iptables immediately
[18:40] <supaman> Chuckfu: issuing 'ufw logging low'
[18:40] <Chuckfu> humm but when trouble shooting I should leave it like it is too see issues right
[18:41] <supaman> Chuckfu: if log level is set to high or medium then yes
[18:42] <Chuckfu> what is the command to see what level its at I have not done anything but add ports to it
[18:43] <Chuckfu> is there someway of filtering to only see port 587 block
[18:44] <supaman> Chuckfu: too see the current level look in /etc/ufw/ufw.conf
[18:45] <jdstrand> supaman: yes, but the default loglevel is low, which will show some stuff
[18:46] <jdstrand> "logs all blocked packets not matching the defined policy (with rate limiting), as well as packets matching logged rules"
[18:46] <Chuckfu> screwed up I did a nano ufw.log | grep "BLOCK" seems froze right now
[18:46] <jdstrand> they might be redirected somewhere
[18:46] <jdstrand> Chuckfu: ctrl+c that
[18:46] <Chuckfu> yeah nothing
[18:46] <jdstrand> Chuckfu: just do: grep "BLOCK" /var/log/ufw.log
[18:47] <Chuckfu> it locked up, oh well thats how you learn
[18:47] <supaman> Chuckfu: do ctrl-x
[18:47] <supaman> that exits nano
[18:47] <Chuckfu> nada
[18:48] <supaman> hmmm
[18:48] <Chuckfu> lol I just cold rebooted  not good, hopefully I didn't blow it up
[18:49] <supaman> :-)
[18:49] <supaman> it should have been in nano mode and the usual ctrl-x to exit nano should have worked
[18:50] <Chuckfu> ok back up
[18:50] <Chuckfu> no issues
[18:52] <Chuckfu> ok ufw is set to low
[18:53] <supaman> if you don't see anything in /var/log/ufw.log then issue 'ufw logging medium' and try doing the email again
[18:53] <supaman> then you should see a lot more info from ufw
[18:54] <Chuckfu> it said low and I just perform that command
[18:55] <supaman> you can also see ufw "realtime" messages with 'journalctl -f' or 'tail -f /var/log/ufw.log'
[19:00] <Chuckfu> is there a way to allow traffic IN/OUT on port 587
[19:03] <supaman> you originally did ufw allow 587/tcp ... don't remember if you need udp also ... so you could try 'ufw allow 587'
[19:04] <supaman> is this server a public server or just for your home use?
[19:04] <jdstrand> Chuckfu: the default policy allows all outbound traffic. it also uses connection tracking so traffic related to the initial connect on 587 is allowed
[19:05] <jdstrand> Chuckfu: if you changed the default (sudo ufw status verbose), then you would need to add egress (outgoing) rules from your system to somewhere else, port 587
[19:10] <Chuckfu> can I reset ufw to default
[19:14] <Chuckfu> or will disabling ufw allow all traffic to pass
[19:16] <supaman> if you disable ufw then all computers that have direct access to that computer can access all ports that are open on that computer
[19:17] <supaman> if that computer is behind a NAT then there is much less danger, but still whichever port is natted into the computer is accessable from outside the NAT
[19:18] <Chuckfu>  guess I need to reset the firewall and start from scratch, adding whatever is needed and creating the outgoing rules
[19:18] <Chuckfu> or I could put together a pfsense firewall before it, something with a gui so I can see whats going on
[19:19] <supaman> yeah, not sure how to reset ufw
[19:20] <supaman> https://www.digitalocean.com/community/questions/how-to-reset-the-firewall-on-ubuntu
[19:20] <sarnold>        reset  Disables and resets firewall to installation defaults. Can also give the --force option to perform the reset without confirmation.
[19:29] <Chuckfu> thank you very much for the help been awesome learning lesson
[19:30] <Chuckfu> be glad you don't live in Phoenix, I'd have you camping at my house teaching me
[19:31] <supaman> camping in Phoenix ... hmmm :-)
[19:31] <sarnold> phoenix, indeed, I'd be dead from heat stroke by june :)
[19:31] <supaman> considering I live close to 66°N yup, same here
[19:32] <sarnold> supaman: hehe, even december may be too hot for you then :)
[19:32] <supaman> yup :-)
[19:34] <Chuckfu> Oh but the fall, winter and spring months are awesome low of 50's high of 70's
[19:35] <Chuckfu> but yeah summer you go AC to AC
[19:35] <supaman> had -10°C here the other day, it was refreshing :-)