ubuntu

apt-key is deprecated, part 2

/ bronto / 1 Comment

In my first article about the deprecation of apt-key I illustrated a few ways of adding APT repository keys to your system without using the apt-key command. A good follow-up discussion to that article started on twitter (thanks to Petru Ratiu). The topics we discussed were: the use of the signed-by clause and if it really helps increasing security; the use of package pinning to avoid third-party packages taking over official packages; and the pollution of system directories.

In this post we dig a bit deeper into these topics and how they help, or don’t help, making your system more secure. A TL;DR for the impatient is included at the end of each section.

Continue reading →
Advertisement

apt-key is deprecated, now what?

/ bronto / 2 Comments

It’s only a few weeks since I upgraded one of my systems from Debian 10 to Debian 11. In fact, I use to apply a “Debian distribution quarantine”: when a new major version of the distribution is out, I usually wait until a “.1” or “.2” minor version before installing it, as I don’t have enough time to debug problems that may have escaped Debian’s QA process at the very first release.

One of the first things that catch one’s attention when I ran the apt-key command in Debian 11 (e.g. a simple apt-key list) was a warning:

Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8))

“Deprecated” usually means that a certain functionality will be eventually removed from the system. In this case, Ubuntu users will be hit already in 2022 with the release of 22.10 in October as the command will be available last in the next LTS (22.04) to be released in April. Debian users will have more time, as the command won’t available in the next major release of Debian (supposedly Debian 12, that may be a couple of years away). This is written in clear letters in the man page:

apt-key(8) will last be available in Debian 11 and Ubuntu 22.04.

So, what are you supposed to do now in order to manage the keys of third party APT repositories?

Continue reading →

On systemd

/ bronto / 1 Comment

ReligiousWarsUNIX init systems are not a topic people discusses a lot about, usually. There is some buzz when a new one is out, some more buzz when it is adopted in other shops than those where it was born, then most OS keep on with their old solution (usually the System V init system, or sysvinit) and everything falls back to radio silence. Other times, I assume, things cut short from some buzz and directly into the radio silence phase. I’ve been into the Upstart buzz, before that I’ve been into the Solaris SMF buzz and even played with it until our friend OpenSolaris was mercilessly killed by their new father. But, honestly, the heated arguments about systemd took my by surprise.

I really don’t know how I had not heard about systemd before. Maybe I was just looking in another direction, or maybe the fact that it was so controversial suggested systemd’s detractors not to talk about it in the hope that it would be yet another of those attempts that cut short from their offspring to radio silence. I don’t know. Anyway, it didn’t go that way. To me, it’s like systemd flew steadily under the radar and kept growing until the Debian project decided to adopt it as their init system. My brain just filtered the news as yet another thing I could safely ignore for the moment and I’ll have to learn about when it comes. And then the sky fell down.

What happened after that announcement was kind of the burst of a religious war, with people debating harshly, insulting each other, death threats spewed here and there, people resigning from their role in important organizations. Then came the Devuan fork of Debian. For now.

A bit too much for “just another init system”, right?

What follows is the outcome of my Christmastime readings about systemd and my own considerations about what I’ve read. I hope it will help you make up your own opinion on whether or not systemd is a good thing or a bad thing. As an extra, you can read my own opinion (for what is worth).

Continue reading →

Installing OpenOffice.org 3.3.0

/ bronto / Leave a comment

Currently I am using Ubuntu Linux 10.04 LTS on my workstation. I will switch back to Debian as soon as I have time, but for now this is what I have to bear with.

Recently, I've been annoyed by a stupid bug in OpenOffice's presentation effects. This distribution ships with 3.2.0. Once I verified that 3.3 was not affected by this bug, I decided to install it on my system using the official DEB packages.

Unfortunately, the installation instructions in the installation guide are not completely accurate. Since I am going to do this installation on all my PCs, it's better I make a note. And I'll do it here.

The dpkg line in the installation procedure should actually read as:

dpkg -i --force-overwrite openoffice.org*.deb desktop-integration/openoffice.org3.3-debian-menus_3.3-9556_all.deb ooobasis3.3-*.deb

(prefix it with sudo if you are not root).

That will install openoffice on your system, and also update GNOME menus.

locales and Ubuntu 10.10

/ bronto / 2 Comments

Today, during an upgrade of my workstation's 10.10, I noticed that a lot of unneeded EN locales were being generated, and I wanted to get rid of them. Coming from a debian background, I confidently ran dpkg-reconfigure locales, but instead of getting the usual interface I got

root@brabham:~# dpkg-reconfigure --priority=low locales
Generating locales...
  en_AG.UTF-8... up-to-date
  en_AU.UTF-8... up-to-date
  en_BW.UTF-8... up-to-date
  en_CA.UTF-8... up-to-date
  en_DK.UTF-8... up-to-date
  en_GB.UTF-8... up-to-date
  en_HK.UTF-8... up-to-date
  en_IE.UTF-8... up-to-date
  en_IN.UTF-8... up-to-date
  en_NG.UTF-8... up-to-date
  en_NZ.UTF-8... up-to-date
  en_PH.UTF-8... up-to-date
  en_SG.UTF-8... up-to-date
  en_US.UTF-8... up-to-date
  en_ZA.UTF-8... up-to-date
  en_ZW.UTF-8... up-to-date
  it_CH.UTF-8... up-to-date
  it_IT.UTF-8... up-to-date
Generation complete.

Odd, isn't it? Well, it turns out that, in order to get rid of the locales you don't want, you have to manually change the files in /var/lib/locales/supported.d. Oh, dear…

OK, Canonical claims to create "Linux for the human beings". I partially agree with that. But I would like to know how removing the ncurses interface to locales could possibly make the system simpler. I mean: "common" users just won't care if they have 100 locales instead of 10, so it doesn't matter for them. We "advanced users" can edit plan text files, for sure, but is that a good reason to remove a convenient interface from the system?

Ubuntu really puzzles me sometimes…

Activating XDMCP in Ubuntu (Karmic)

/ bronto / Leave a comment

Once upon a time, there was a small program called gdmsetup that allowed you to fully set-up the graphical login manager. For reasons that it would be too long to explain here, I wanted to enable the XDMCP protocol in my workstation's gdm and… surprise: gdmsetup now is just a single, small, almost useless window…

So, being Ubuntu the "Linux for human beings", how are human beings supposed to enable XDMCP? Editing a configuration file, like we old people used to do. Perfect!!! Let's check: /etc/gdm contains a custom.conf that is the place where you are supposed to write your custom configurations. Ah, it references a sample file, good! What? It doesn't exist??? 😦 And no useful man page?

OK, I have no problem in configuring services by editing a configuration file, that's what I do for living after all 😉 But what about leaving some documentation around to let us human beings learn what to do? Must we really trust Google for things that the Operating System itself should provide?

By the way, it turns out that the [xdmcp] section in custom.conf should look like this:

[xdmcp]
Enable=true
DisplaysPerHost=2

Thanks peppertop, thanks Google, and… $ubuntu– 😦

Update: It turns out that I am very lucky that I was running Ubuntu Karmic, since the GDM that ships with Lucid doesn't support XDMCP at all…

I am starting investigation for my new Linux distro of choice…