TommyPeanuts's questions

On Ubuntu 23.10, when I open a terminal and ssh in to a host I have like this:

ssh hostname.here.com

It logs me in straight away (even when I've first booted up my machine, not just after I've logged in for the frist time in a session). I have no details for the host in my ~/.ssh/config file either.

Now I need to work out what the username/password (and maybe the key file name) is for that host. I have a record but it's a bit confused (and so far no username/password combination works - but that's another matter).

I have looked at Seahorse, but it doesn't seem to list anything obvious for the host.

How do I find out at least what username and/or key file Ubuntu is using to log in to it? Is there something else Ubuntu uses for remembering terminal logins?

I'm following these instructions for setting up sftp and scp (although I'd like to add rsync too) but when the jailed account logs in, it immediately disconnects without any errors I can see.

The doc says that if this happens you need to journalctl|grep jk_, which gives this (nor errors):

jk_chrootsh[3157425]: now entering jail /home/jail for user jailtest (1001) with arguments -c /usr/lib/openssh/sftp-server

Most if not all of the information I can find on Jailkit seems pretty old, although I see jailkit itself was updated in Oct 2021. Does anyone know if it still works on Ubuntu or how I can track down what error is happening?

I have used Jailkit successfully in the past with Ubuntu 18. I'm starting to think that something fundamental has changed in 20 (snaps, perhaps?) which has disabled Jailkit in some way.

/home/jail/etc/passwd:

jailtest:x:1001:1004:tester,,,:/home/jailtest:/usr/sbin/jk_lsh

/etc/jailkit/jk_lsh.ini:

[jailtest]
paths= /usr/bin, /usr/lib/openssh
executables= /usr/bin/scp, /usr/lib/openssh/sftp-server

ldd /usr/sbin/jk_lsh

linux-vdso.so.1 (0x00007ffce6d11000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f91ffee6000)
/lib64/ld-linux-x86-64.so.2 (0x00007f920011f000)

strace chroot /home/jail/ /usr/sbin/jk_lsh and other things doesn't seem to show anything missing.

scp -v ./test.txt [email protected]:/home/jailtest/ from the client shows no errors and just hangs up:

debug1: Sending environment.
debug1: channel 0: setting env LANG = "en_GB.UTF-8"
debug1: Sending subsystem: sftp
debug1: pledge: fork
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 4172, received 4132 bytes, in 0.4 seconds
Bytes per second: sent 9390.9, received 9300.9
debug1: Exit status 3
scp: Connection closed

My sshd_config is:

PermitRootLogin no 
PubkeyAuthentication yes
PasswordAuthentication no 
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem       sftp    /usr/lib/openssh/sftp-server
AllowGroups ssh-users # I've put the jailed user into this, removing it causes a permissions error

I have a server that I would like to hand over to somebody else. It's currently attached the Ubuntu Pro free tier, registered to my Ubuntu One account so I'd like that to be on their ID.

What's the easiest way of doing that? Should I run pro detach then attach using their ID? Will that preserve the settings?

I have several machines running apcupsd which are network slaved to a master connected to the UPS. From time to time we get short (~5sec) power brown outs which the master sends out emails about. That's fine.

However, the problem is that the slaves also send out the same messages, which are redundant.

I see that in /etc/apccontrol actions are configurable like this:

    offbattery)
        echo "Power has returned on UPS ${2}..." | ${WALL}
    ;;

I can simply remove the pipe to wall, but is that the best way of doing it? The manual doesn't seem to cover suppression of messages.

If I have a RAID array configured (using mdadm), what's the best way of making sure I can tell which physical disk to replace in the event that one fails?

cat /proc/mdstat will tell me that (say) /dev/sda has failed. That's OK.

But when I look at the physical disks, which one is /dev/sda?

If I use lshw -class disk, I see it returns a logical name (eg /dev/sda) and a serial number. If that serial number corresponds to the number given on the disk casing, and the logical name doesn't change, I could write both somewhere visible on each disk.

However, I see that for some reason the serial number given by lshw is sometimes not the serial number given on the casing of the drive. I also suspect the logical name may change under some circumstances.

So is there a better way? Some script that can tell me which of the labelled disks to switch out, perhaps?

I've just installed canonical-livepatch on Ubuntu Server 16.04.6 LTS and when I try to register the machine I get this on the enable command:

2019/10/20 11:33:55 error executing enable: cannot enable machine: cannot send request: Post https://livepatch.canonical.com/api/machine-tokens: proxyconnect tcp: dial tcp: lookup "http: no such host

And this in syslog:

Oct 20 11:27:18 lorina canonical-livepatch[3287]: during refresh: cannot check: No machine-token. Please run 'canonical-livepatch enable'!
Oct 20 11:27:29 lorina kernel: [701248.639128] audit: type=1400 audit(1571567249.885:210): apparmor="DENIED" operation="open" profile="snap.canonical-livepatch.canonical-livepatch" name="/sys/kernel/mm/transparent_hugepage/hpage_pmd_size" pid=3420 comm="canonical-livep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Oct 20 11:29:04 lorina kernel: [701343.340206] audit: type=1400 audit(1571567344.591:211): apparmor="DENIED" operation="open" profile="snap.canonical-livepatch.canonical-livepatch" name="/sys/kernel/mm/transparent_hugepage/hpage_pmd_size" pid=3552 comm="canonical-livep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

If I run host livepatch.canonical.com it resolves fine. The proxy also allows the http request OK, and the error still happens when I disable the firewall.

Does anyone know where to start on this?

I am installing 18.04 Server with the network mini.iso as a VM and using IPv6 DHCP. I have no IPv4 WAN addresses available.

The installation works fine. I give the installer the DNS servers and it configures the rest over DHCP. All packages are downloaded OK over the WAN during the install (at least, I assume they are!). However, when the installation finishes, I have no network and I have to configure it manually. Note that networking is configured after install (as IPv6 DHCP in my case), but with no DNS servers.

Why is this? Should not the installer apply the network configs it used?

Installing Ubuntu Server 18.04, I see the networking config in /etc/netplan has a .yml file that talks about CloudInit and networking configuration not persisting across instances.

I have read https://help.ubuntu.com/community/CloudInit but am unsure what the exact use case for CloudInit would be, and why it would be on by default. My server is not on AWS nor any cloud platform.

So I've disabled this with /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg as per the comment at the start of the config file, and assigned a simple static IP and that works fine.

To be clear: I am not asking how to disable it (I have done that, and am happy with the result). I just don't understand the reason for its existence, nor can I make that out from the documentation for it. Is it intended to replace DHCP in some way?

I've recently done a clean install of 17.04 on a machine with an Nvidia 750Ti card and a Dell 4K monitor. I'm using the Nvidia binary driver 381.09.

All this works great apart from the fact that the display scaling I set in the Ubuntu Screen Display settings always reverts back to 1 when the machine resumes after suspend. I need to set it at 1.5 otherwise everything goes tiny (BTW why doesn't Ubuntu scale to a sensible default with 4K monitors?)

Does anyone else get this? I can't find any mention of it elsewhere.

BTW I've tried the Nouveau driver and that doesn't wake up my screen at all after suspend. So that route's a non-starter.

Edit: Looks like it's been reported as a confirmed bug here Will monitor to see if anything happens.

I have two installations of Ubuntu server 14.04.2 LTS, both installed from the same media (I just checked - the DVD used for both is still on the drive of one of them), but a couple of months apart. All packages appear to be up to date, but see the kernel version on one is higher than that on the other:

root@bud:~$ uname -r
3.13.0-55-generic

root@mud:~$ uname -r
3.16.0-40-generic

Why is this? Shouldn't I be running the 3.16 kernel on the first one?