gerlos's questions

How can I centralise the management of ~40 PCs that will be running Ubuntu Desktop 20.04 LTS?
Those PC will be used by ~100 users (students, teachers and staff) in 3 different locations, so I expect to setup some sort of central authentication.

Currently we have one Ubuntu 20.04 LTS server providing dns, dhcp and samba file sharing to ~10 Ubuntu 20.04 LTS desktops that are essentially single-user machines. Everything is running in our headquarters.

It's the first time I'm asked to do something similar, so I'm quite confused and I'm not sure what I need to setup.

I guess I'm missing something here, perhaps I need to do some configuration to enable my hardware full speed under Linux - here's my problem.

I recently got this Intel NUC 9 Extreme kit.

I added 64 GB of RAM, and since I wanted to setup a RAID1 drive, I put two Samsung 970 EVO 1TB M.2 NVME drives in it:

Since they are PCIe Gen 3 x4 devices, I was expecting to be able to get something close to 3 GB/s in sequential reads from a single drive and a little less than 6 GB/s from a RAID1 device, but actual speeds disappointed me, since I couldn't get more than 2.1 GB/s, even in RAID1.

To test storage speed I used dd, like this:

$ dd if=/dev/zero of=/path/to/test/64GB bs=1G count=64 && dd if=/dev/zero of=/media/ubuntu/evo/fill-cache bs=1G count=64 && dd if=/path/to/test/64GB of=/dev/null
64+0 record dentro
64+0 record fuori
68719476736 bytes (69 GB, 64 GiB) copied, 43,3462 s, 1,6 GB/s
64+0 record dentro
64+0 record fuori
68719476736 bytes (69 GB, 64 GiB) copied, 49,6182 s, 1,4 GB/s
134217728+0 record dentro
134217728+0 record fuori
68719476736 bytes (69 GB, 64 GiB) copied, 139,781 s, 492 MB/s

I run these commands 6-7 times and sequential write speeds were less than 1.2 GB/s. Sequential read speeds were always less than 1.9 GB/s. Running bonnie++ I got similar results.

I did my tests booting that system from an external USB drive running Ubuntu 20.04 with kernel 5.4 and from a Fedora 33 install disk running kernel 5.8, with similar results (in Fedora speeds were even worse). I tried both with ext4 and xfs, with no appreciable difference.

Since the results are the same in RAID1 and even when I create a striped LVM volume, I guess there must be a bottleneck somewhere that prevents my hardware to run at full speed.

The hardware seems to work fine, since when I tried to boot that system from an external USB disk running Windows 10, I got the expected performance:

------------------------------------------------------------------------------
CrystalDiskMark 8.0.0 x64 (C) 2007-2020 hiyohiyo
                                  Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
  SEQ    1MiB (Q=  8, T= 1):  2924.425 MB/s [   2788.9 IOPS] <  2865.38 us>
  SEQ  128KiB (Q= 32, T= 1):  3523.300 MB/s [  26880.6 IOPS] <  1179.77 us>
  RND    4KiB (Q= 32, T=16):  2077.373 MB/s [ 507171.1 IOPS] <  1005.95 us>
  RND    4KiB (Q=  1, T= 1):    53.885 MB/s [  13155.5 IOPS] <    75.87 us>

[Write]
  SEQ    1MiB (Q=  8, T= 1):  2208.972 MB/s [   2106.6 IOPS] <  3788.09 us>
  SEQ  128KiB (Q= 32, T= 1):  2117.792 MB/s [  16157.5 IOPS] <  1978.06 us>
  RND    4KiB (Q= 32, T=16):  1962.843 MB/s [ 479209.7 IOPS] <  1067.32 us>
  RND    4KiB (Q=  1, T= 1):   130.946 MB/s [  31969.2 IOPS] <    31.13 us>

Profile: Default
   Test: 64 GiB (x5) [G: 0% (0/932GiB)]
   Mode: [Admin]
   Time: Measure 5 sec / Interval 5 sec 
   Date: 2020/12/15 10:18:14
     OS: Windows 10 Professional [10.0 Build 18363] (x64)

My devices are also running latest firmware.

Should I do something special on my linux system to to enable these speeds?

Update

Someone suggested me that my benchmark approach with dd could be wrong, and to try the benchmark feature of Gnome Disks.

I tried and got read speeds closer to the specifications, so I was doing things the wrong way. Still, write speeds are 1/4 of those I saw with CrystalDiskMark on Windows, so I'm still puzzled.

I recently upgraded from Ubuntu 18.04 to Ubuntu 20.04 and got a strange problem with byobu, tmux, Vim and ncurses applications: Enter doesn't work, and I need to use CTRL+M instead.

For example, if I edit a file in Vim inside a Byobu (or Tmux) window in a Gnome-Terminal, typing Enter doesn't insert a newline character, but inserts a new line with a M character. To insert a new line I need to type CTRL+M. AS a result, to exit Vim I need to type ESC :q CTRL+M.

This happens also in ncurses applications such as ncdu: instead of Enter I need to use CTRL+M.

Changing the TERM environment variable seems to help, but not 100%. The default value I get in byobu and tmux is TERM=screeen-256color, but if I change it to TERM=xterm-256color everything seems to work fine in Vim, but not in ncdu.

In addition to this, Enter key doesn't work when I use F9 to change Byobu configuration - as I said above, I need to use CTRL+M to select items in the configuration.

I tried also to add the following line in both ~/.tmux.conf and ~/.byobu/.tmux.conf, but it helped only with Vim:

set -g default-terminal "xterm-256color"

The problem happens on xterm also.

How can I solve this?

Update

I tried again with a new user, and experienced the same problem, so my guess is that it could be something system-related.

Update 2

Tinkering around with xev I found that there's something odd with this laptop's keyboard - it's an ANSI keyboard even though I'm in Italy (standard Italian keyboard layouts are ISO), and Enter button sends the wrong keycode.

When I press the Enter button it sends a kyecode 104, KP_Enter, instead of usual keycode 36, Return. So it's an hardware problem, perhaps unrelated to Ubuntu itself. Not sure why I didn't realise it before.

When we try to print N copies of a document and enable collation, we get N² copies of the printed document.
For example, if we request to print 2 copies, we get 4 copies printed (3 gives 9 copies, 4 gives 16, and so on).

I guess this may be related to CUPS and/or printer driver, how can I troubleshoot this problem?

Disabling collation we get the right number of copies, but this can be quite inconvenient when one needs to print several copies of long documents.

This happens in all our ~20 desktop PCs running Ubuntu 18.04 LTS.
We have a HP PageWide MFP P57750 XC network printer that is automatically detected and enabled by Ubuntu, and users can print documents to it.

It seems to be unrelated to any specific user, document, application or system, since it happens on everywhere, even newly installed PCs. We tried both in Evince, Firefox, Thunderbird and Gedit, and from the command line, using commands like this:

$ lp -o collate=true -n 2 test.pdf

In our experience the only application that prints the correct number of copies when we enable collation is LibreOffice, that uses its own print dialog.

I'm not sure where to look to solve this problem. Any hint?

I tried to install 19.10 on a VM and it isn't affected by the problem - it prints the correct number of copies, so the problems seems to be solved in recent releases. But I don't want to upgrade our network to a non-LTS release.

I'm configuring Ubuntu 18.04 LTS PCs for a school in Italy, and I've seen that more than 200 fonts got installed as dependencies of ubuntu-desktop package.

We don't need most of them, we don't expect tipycal users to write or read documents in Bengali or Thai, for example. Actually, so many fonts make font choices more difficult for our users (for example in LibreOffice), because it makes difficult for them to find useful fonts.

Is there a way to disable those non-Latin fonts system wide, so they don't appear in applications?

I know I could manually remove them (for example purging fonts-tlwg-* packages), but I want to keep them installed, so single users can enable them later on if needed, without affecting other users of the same system.

I've a group of Ubuntu Trusty desktop PCs in my office, and usually I ssh to them and install updates remotely from the command line. Unfortunately, sometimes local users decide to shutdown those PCs, breaking the update process.

I'd like to prevent those users to shutdown, reboot or suspend their PCs when there's an SSH session active. How can I do it?

I've tried molly-guard, but doesn't prevent GUI users from shutting down the system (it doesn't seem to affect GUI users).
I've seen also this question, but didn't understand if it's applicable also to Ubuntu 14.04 LTS or not (and I'm not sure how to apply it):
disable shutdown/suspend if there is other user logged in via ssh