[02:00] <plus2equalsme> Feel like this is a silly question. I'm in need of some help fine-tuning my acpi settings (running 18.04.1 server on a laptop, and the defaults aren't doing what I want them to do)
[02:12] <plus2equalsme> basically, what I need to do is ignore the lid switch (aka, do nothing when the lid is closed) and blank the screen after a certain amount of time, without powering down anything else, and be able to bring the screen back up when I use the keyboard or trackpad
[02:13] <sarnold> plus2equalsme: https://wiki.debian.org/SystemdSuspendSedation HandleLidSwitch=ignore probably does the trick
[02:16] <plus2equalsme> thank you sarnold I will look at that. Not sure how I didn't find it before (almost everything I've looked at assumes running X)
[02:16] <sarnold> plus2equalsme: because there's only a thousand systemd manpages and how the heck would you know to look in the one for login.conf to find this :)
[02:17] <plus2equalsme> True that sarnold
[02:17] <plus2equalsme> :)
[02:17] <sarnold> honestly I stumbled on this by complete accident one day..
[02:17] <sarnold> I can't recall now what I was researching but it sure wasn't this ;) hehe
[02:23] <plus2equalsme> hehehe lucky me that you did! now if only I can figure out how to blank the screen but still be able to bring it back up if I need to (aka, if I can't get in via ssh)
[02:29] <sarnold> yah :/ I haven't just stumbled on that one
[02:36] <plus2equalsme> Oooooooo, I think I did, at least partway. the beginning of the "magical incantation" (as I saw it referred to not long ago) is setterm. Looking at manpage now
[02:42] <plus2equalsme> might also need to install vbetool, apparently
[02:47] <plus2equalsme> ok, gonna go check some things (machine is physically elsewhere
[02:55] <plus2equalsme> sarnold HandleLidSwitch=ignore worked. Currently waiting on the setterm (smallest interval is 1 minute)
[03:06] <plus2equalsme> for future referrence, in case anyone else ever asks and I'm not here, setterm also works. Tomorrow I'll have to look at scripting it so that it's automatic anytime the machine reboots.
[03:06] <plus2equalsme> thank you so much
[03:07] <plus2equalsme> but now it's time to start getting ready for bed
[13:46] <ShellcatZero> Hi, after an upgrade from 16.04 to 18.04, it appears dnsmasq was uninstalled and the machine lost all networking ability.  I managed to get internet back up on the server with a basic config for /etc/netplan, but the machine still cannot resolve local hosts from the DNS.  Any help is appreciated.
[14:28] <ShellcatZero> I ended up just adding entries to the /etc/hosts file, but this doesn't help me when the hosts move to other IP addresses, still looking for a better solution.
[14:31] <tomreyn> ShellcatZero: do you have a search domain configured?
[14:32] <ShellcatZero> how would I do that tomreyn?
[14:32] <ShellcatZero> or check?
[14:32] <tomreyn> i just installed 18.04.1 server using the live server installer to help you trouble shoot, it's booting now.
[14:33] <tomreyn> so /etc/resolv.conf contains the search domain configuration here
[14:34] <tomreyn> where /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf
[14:34] <tomreyn> this systems' NIC is configured via dhcp
[14:35] <ShellcatZero> right, and /etc/resolv.conf always gets overwritten from another config file, I didn't think the stub was supposed to be editted directly
[14:35] <tomreyn> you're right, it says "This file is managed by man:systemd_resolved(8). Do not edit."
[14:36] <tomreyn> it also says "To manage man:resolv.con(5) in a different way, replace this symlink by  a static file or different symlink"
[14:37] <tomreyn> and  "See man:systemd-resolved-service(8) for details about the supported modes of operation for /etc/resolv.conf"
[14:40] <ShellcatZero> right, I haven't found anything helpful from there so far.  Between netplan, NetworkManager, and systemd-networkd, I am not sure what the most appropriate method is proper DNS configuration.
[14:40] <ShellcatZero> or systemd-resolved
[14:43] <tomreyn> ShellcatZero: by default ubuntu *server* 18.04 uses systemd-networkd, optionally with netplan. https://netplan.io/examples#dhcp-and-static-addressing
[14:44] <ShellcatZero> Yep, that's what I used for my netplan config
[14:45] <tomreyn> and it didn't giver you a search domain in /etc/resolv.conf ?
[14:47] <tomreyn> AKA man:netplan(5) http://manpages.ubuntu.com/manpages/cosmic/man5/netplan.5.html -> "   Common properties for all device types" -> "       nameservers (mapping)"
[14:47] <ShellcatZero> that file shows "nameserver 127.0.0.53", but the file says to check "systemd-resolve --status" for the actual nameservers, and the output there is listing my router as the nameserver
[14:47] <tomreyn> i'm asking about search domain , not nameserver
[14:47] <ShellcatZero> by that file, I mean /etc/resolv.conf
[14:48] <tomreyn> ...since you said you can't resolve local domain names
[14:48] <ShellcatZero> it does not list a search domain in that file for me, but none of my other servers list a search domain there either
[14:49] <tomreyn> i see. so those local domains you said cant be resolved must be resolved by the nameservers the other servers have configured. are those the same nameservers you have configured on this server?
[14:50] <ShellcatZero> correct, but the other servers are on 16.04, and this one was just upgraded to 18.04
[14:51] <tomreyn> ok, but name resolution should still work the same. hmm. is this a virtual server maybe?
[14:52] <ShellcatZero> from the netplan man page you gave, I may indeed need to provide a search field in the YAML for this to work right. This is not a virtual server
[14:53] <tomreyn> if you don't have a search line in /etc/resolv.conf on the other servers, you wouldn't need add a 'search' record on the netplan YAML on this system either.
[14:53] <tomreyn> that's unless the 16.04 servers have the 'search' line on /etc/network/interfaces instead as 'dns-search'
[14:54] <ShellcatZero> they do not
[14:58] <ShellcatZero> the subtle difference in 18.04 is that systemd-resolved is managing the networking now
[14:58] <tomreyn> then i guess they resolve the 'internal domains' via their resolvers. you can test this using, for example, dig.   dig internaldomainname.lan @ubuntu1604serversresolver
[14:59] <tomreyn> replace "internaldomainname.lan" by an internal domain name, replace "ubuntu1604serversresolver" by a 'nameserver' configured on a ubuntu 16.04 servers' /etc/resolve.conf (and keep the @ character)
[15:00] <ShellcatZero> dig works
[15:01] <ShellcatZero> but I still cannot ssh or ping by hostname
[15:04] <tomreyn> that'd be a network configuration issue then
[15:05] <tomreyn> (outside of this server)
[15:05] <tomreyn> where 'network' can also mean 'firewall'
[15:06] <tomreyn> try to ssh and ping to an internal servers' ip address
[15:06] <ShellcatZero> this is the only server having this issue though, I can ping/ssh by hostnames from any of the other servers, and the other servers can resolve this hostname just fine, but this hostname cannot resolve names on the other machines
[15:07] <tomreyn> so "systemd-resolve internaldomainname.lan" fails?
[15:08] <ShellcatZero> it does indeed
[15:08] <ShellcatZero> according to "iptables -L", the firewall config matches the other machines as well
[15:09] <tomreyn> to confirm, "systemd-resolve --status" shows, for ths main NIC, the 18.04 servers' gateway as 'DNS Servers', and no 'DNS Domain'?
[15:10] <tomreyn> ths -> the
[15:10] <ShellcatZero> that is correct
[15:11] <tomreyn> when you ran dig, did you use the 18.04 servers' gateway ffor "ubuntu1604serversresolver"?
[15:12] <tomreyn> (i.e. is it the same ip address?)
[15:12] <ShellcatZero> Yes
[15:13] <tomreyn> hmm, i'm puzzled now :-/
[15:13] <ShellcatZero> the machine can ssh/ping by ip just fine as well
[15:15] <ShellcatZero> I'll keep looking into it, and possibly post to askubuntu about the issue
[15:15] <tomreyn> maybe try "systemctl restart systemd-resolvd.service" and keep an eye on syslog
[15:16] <tomreyn> ...also while you repeat the lookups for local hostnames
[15:19] <ShellcatZero> no errors observed in syslog
[15:26] <ShellcatZero> oh, wait a second, dig actually does not work
[15:27] <ShellcatZero> I misinterpreted the output
[15:27] <tomreyn> appending +short can help
[15:28] <tomreyn> if you run the same dig command on the 16.04 servers, does it work there?
[15:29] <tomreyn> and is the ";; SERVER: " responding the query identical
[15:31] <ShellcatZero> dig works fine on the 16.04 machines.  I'm not sure I understand your second question
[15:32] <ShellcatZero> the other machines are receiving the exact same response from the 18.04 machine, if that's what you're asking
[15:34] <tomreyn> the non shortened output (i.e. run dig without '+short') of the identical dig command you run on the 16.04 and 18.04 servers should contain a line starting ";; SERVER: "
[15:34] <tomreyn> i'm asking whether the rest of this line is identical on both the 16.04 and 18.04 servers
[15:35] <tomreyn> this is the resolver which responded to the dig query.
[15:38] <tomreyn> if the same resolver responded the same request (as indicated in the ";; QUESTION SECTION") differently for the 16.04 and 18.04 servers, then we have to assume that your 18.04 server's IP address is not considered to be allowed to make these requests / is considered to be part of a different zone. i.e. a misconfiguration on the resolver.
[15:38] <ShellcatZero> on the 18.04 system, the like looks like: ;; SERVER: 127.0.0.53#53(127.0.0.53)
[15:38] <ShellcatZero> on 16.04, it looks like: ;; SERVER: 192.168.1.1#53(192.168.1.1)
[15:39] <tomreyn> so you didn't specify the resolver when running dig
[15:39] <ShellcatZero> oh
[15:58] <evit> Anyone seen if there is an effort to update the PHP version to address this vuln https://www.cisecurity.org/advisory/multiple-vulnerabilities-in-php-could-allow-for-arbitrary-code-execution_2018-113/
[16:04] <evit> Very lively in here today... 8*P
[16:14] <mybalzitch> just sounds like fear mongering.
[16:36] <evit> mybalzitch, I don't understand what you mean by that.
[16:42] <tomreyn> evit: you'd need to identify the CVE IDs for these vulnerabilities, then look them up on https://people.canonical.com/~ubuntu-security/cve/
[16:42] <tomreyn> (and i don't know what mybalzitch means, either)
[16:43] <evit> tomreyn, I don't see that it has a CVE yet
[16:44] <tomreyn> evit: it lists php.net bug tracker IDs, and those have fields for CVE IDs.
[16:45] <tomreyn> example: "Bug #76796 (Compile-time evaluation of disabled function in opcache causes segfault)" is http://bugs.php.net/76796 , which says "CVE-ID: None". so in this case no cve id was assigned (yet?), but it may be the case for some of the other bugs.
[16:45] <ubottu> bug 76796 in evolution (Ubuntu) "evolutions consums lots of cpu while pinging imap server" [Low,Invalid] https://launchpad.net/bugs/76796
[16:46] <tomreyn> ^ ignore
[16:46] <evit> tomreyn, http://php.net/ChangeLog-7.php#7.2.11 Shows CVE-ID: None
[16:46] <evit> tomreyn, This is true for 7.1.x and 7.2.x - no CVE ID listed
[16:47] <tomreyn> evit: so if the php developers consider those not worth assigning cve id's then i doubt they'll get handled.
[16:48] <evit> tomreyn, Ahhh, I see. I was wondering why
[16:49] <tomreyn> that's unless someone else will request those bugs to be fixed by opening bug reports for each of them and tagging them security, in which case they *may* get a cve assigned by a linux distro instead, and *may* be considered important enough to have bugfixes developeed and backported.
[16:52] <mybalzitch> evit: there's no obvious remote code execution warned about in that "CVE", it's basically the PHP changelog for a newer version.
[16:53] <evit> mybalzitch, That what I figured you were hinting at but wasn't sure.
[16:58] <tomreyn> good point. those are (on a quick glance) just bug fixes, no security impact is indicated on the changelogs. so it's unclear what the "remote code execution" would be about.
[17:00] <tomreyn> well the memory corruption might have security impact
[17:07] <evit> tomreyn, DoS conditions aren't very good either. =)
[17:09] <tomreyn> evit: right, but did you spot one?
[17:11] <mybalzitch> and it's not like any of that means you can just go to a .php page and magically cause a dos/exploit just by visiting the page
[17:11] <evit> tomreyn, only going off of what I read
[17:16] <evit> mybalzitch, It depends on what you are using to visit the page. Kali has quite a few tools you can 'visit' a page with that can do just that
[17:17] <mybalzitch> and it works against the php version currently shipping in ubuntu-server ?
[17:19] <evit> I have not seen any manifestation of it but that is why I'm asking here if anyone else has...
[17:30] <evit> tomreyn, mybalzitch Thanks1 I gotta jet