sxc731's questions

Back in the days of 20.04, we managed to get the Yaru designers to improve the contrast of the ALT+TAB task switcher's selected app just in time for the release.

22.04 is out now and it looks like this has regressed, again...

I admit I'm lucky to work in a bright office but the current contrast (dark gray on black) makes me squint every time I use the thing (and I use a good quality "productivity" monitor).

Hopefully there is a way to improve the contrast by editing some .css file? If this is too hard (really?) I'd be happy to install an extension but don't feel I need to replace the whole UI as suggested here.

Having recently upgraded my Wifi router's firmware to one that supports WPA3, I tried to adjust the corresponding WiFi connection settings on my laptop running 20.04.1 by selecting "WPA3 Personal" on the 'Security' tab (the 'Details' tab shows that WPA3 support is advertised by the router as expected).

Despite deleting and re-creating the connection profile and multiple reboots, my laptop always connects over WPA2 (as reported by the router's UI). A telltale sign is that the drop-down setting on the 'Security' tab flips back to "WPA & WPA2 Personal".

My laptop's hardware supports WPA3; the router had to be setup in mixed mode (WPA2+WPA3) due to some legacy devices that don't yet support WPA3. My iPhone and other iOS devices immediately took advantage of WPA3 after the firmware upgrade.

Other WPA3 questions relate to 18.04; the version of network-manager (1.22.10) shipped with 20.04 ought to support WPA3 out of the box.

I'm quite positive that this used to work flawlessly in 19.04 (and past releases) but no longer does after a release-upgrade to 19.10 (kernel 5.3.0-24, ThinkPad X1 Carbon gen 5 in case this matters).

I have the corresponding switch set in GNOME-Tweaks and have also attempted to manually edit /etc/systemd/logind.conf as suggested here, namely uncomment and adjust the following lines, followed by a reboot:

$ grep -v '^#' /etc/systemd/logind.conf
[Login]
HandleLidSwitch=suspend
HandleLidSwitchExternalPower=suspend
HandleLidSwitchDocked=suspend
LidSwitchIgnoreInhibited=yes

(strictly speaking, only the first one ought to be required but, just in case, I also added lines 2 & 3, as well as #4 for good measure...

Looking at the output of systemctl status systemd-logind, I see the following:

Dec 17 17:56:50 x1c5 systemd-logind[8959]: Lid closed.
Dec 17 17:57:03 x1c5 systemd-logind[8959]: Lid opened.

So the lid events are correctly detected. To rule out any issue with the suspend process itself, I have also set my power button to suspend in Settings->Power->Suspend & Power Button, for testing purposes. Pressing the power button now results in this in the output of systemctl status systemd-logind (after a successful suspend-resume cycle):

Dec 17 18:13:58 x1c5 systemd-logind[8959]: Power key pressed.
Dec 17 18:14:28 x1c5 systemd-logind[8959]: Delay lock is active (UID 121/gdm, PID 9215/gsd-power) but inhibitor timeout is reached.
Dec 17 18:14:39 x1c5 systemd-logind[8959]: Operation 'sleep' finished.

Bottom line: lid events are detected correctly and suspend works flawlessly - but not on lid close...

Any idea how I can get the suspend on lid-close feature back to life? I can of course use the workaround with the power button but it's a little too easy to forget and result in laptop overheating in bag etc...

--- edited to add ---

Got a little further courtesy of this ticket, although the issue isn't the exactly as described. Here's a smoking gun:

$ systemd-inhibit --list --mode=block
WHO       UID  USER      PID  COMM           WHAT                                                     WHY                                                         MODE 
gdm       121  gdm       2231 gsd-power      handle-lid-switch                                        External monitor attached or configuration changed recently block
gdm       121  gdm       2252 gsd-media-keys handle-power-key:handle-suspend-key:handle-hibernate-key GNOME handling keypresses                                   block
user      1000 user      3017 gsd-media-keys handle-power-key:handle-suspend-key:handle-hibernate-key GNOME handling keypresses                                   block

This suggests that the lid close action is being blocked because "External monitor attached or configuration changed recently". I do connect my laptop to a monitor using a USB-C cable but as I write this, it's been undocked and running on batteries for nearly 3 hours (GNOME settings only shows my laptop display as available). However it looks like systemd or whichever component is responsible for this still incorrectly believes the external display is attached and - per the ticket - suspend isn't supported by GNOME in such scenarios...

Interestingly the gsd-power process (PID 2231) is owned by gdm rather than my UID. Killing it restores the suspend-on-lid-close functionality. Need to figure out why this process exists... When actually connected to external display, systemd-inhibit --list --mode=block reports a 2nd gsd-power process owned by the interactive user; which appears correct and sufficient.

I have some SuperMicro servers which I use MAAS to provision.

I'm intrigued that upon PXE-booting them, they auto-magically gain a 'maas' user in their local BMC users DB, with a random password which is clearly set by the MAAS server, as it's then able to control the servers over IPMI.

This happens despite having modified the factory default 'admin' credentials on the BMCs. It's very convenient but leaves me wondering how MAAS achieves this? Some kind of in-band interface between the main server and the BMC?

So my questions are:

1. Is this safe/expected behaviour or does it suggest the servers haven't been properly secured?
2. Is there a way to influence the role of the user MAAS creates on the BMC? At present it's created with 'Administrator' role; I'd rather have smth less privileged, such as 'Operator', which would still allow power operations that MAAS requires.

Related question: How do you add a machine to MAAS with IPMI power using CLI Note that I did not use the CLI mentioned on that question; all I did was PXE-boot my servers on a network enrolled in MAAS DHCP.

MAAS 2.3 (2.0-2.2 had same behaviour)

On my Ubuntu (17.04) desktop, GNOME keyring (GK) aka "Seahorse" has my SSH private key (~/.ssh/id_rsa) loaded in. The key is protected by a password and GK prompts me for a password to unlock it after logging out of my session (eg: after rebooting my box).

So far so good but in order to improve security, I'd rather get prompts a little more often, eg: after the computer unlocked, which would also catch resuming from sleep/hibernation. This might help mitigate attacks against a laptop stolen while suspended.

Is there a way to achieve this? A time-based setting similar to ssh-add -t <duration> would also work.

Bonus: I have to say I don't fully understand the relationship between GK and ssh-agent (despite trying to parse available documentation). Considerations on whether using GK in this scenario is a serious security risk also welcome. Cheers!

I recently used official images to install bare metal servers and VMs (using a cloud image) and found out they install quite different kernels out of the box:

• 14.04.4 server iso (from here) installs "Wily" kernel 4.2
• 14.04.4 cloud-image (from here, "daily" build 20160512) installs original "Trusty" kernel 3.13

I understand that both are supported as of 14.04.4 (which is great!) and that I can upgrade them but this still begs a couple of questions:

1. Which should be installed by default?
2. Should it be different for the baremetal ISO vs the cloud image?

I ran into this because I'm trying to simulate a baremetal environment with VMs for testing purposes and assumed that images listed above would yield a reasonably similar environment...

(note: although this q relates to 14.04.4, I suppose the question might apply to future point releases, eg: 16.04.x later)

I have a 12.04 box running postgresql 9.1.8-0ubuntu12.04, which serves a Java webapp (an Atlassian Confluence wiki). I'm trying to take advantage of powernap's IOMonitor feature. However, if I uncomment the corresponding line in /etc/powernap/config:

[IOMonitor]
postgres-io = "postgres"

... powernap never allows the box to go to sleep, the logs (with DEBUG=3) show this:

Looking for [postgres-io] IOMonitor
Activity found, reset absent time [0/60]

One thing I have noticed is that postgres appears to be respawning processes every 2-3 mins (even without any user activity against the wiki); every time this happens, powernap prints:

<powernap.monitors.IOMonitor.IOMonitor instance at 0xXXXX> - adding new PID 16783 to list.

The PIDs in questions appear to be the ones serving my wiki DB, eg:

postgres 16783  1067  0 11:05 ?        00:00:00 postgres: confluence confluence 127.0.0.1(50689) idle

I presume this is getting in the way? Is this an issue with Postgres (is it supposed to respawn processes that often, even w/o activity?). Any pointer as to how I go about debugging this would be most appreciated (maybe starting with how powernap infers I/O activity - since there are many postgres processes, perhaps I can find a regexp that will target just the right one?).

PS: If I comment out the Postgres IOMonitor, powernap works a treat but then it does suspend the box while the Wiki is being used...