salt removed from mirror
Hello everyone, I tried to install a system with Debian 11 and a preseed file today from our internal mirror and found out that the package salt-minion was gone. After some research (our mirror snapshots every day) I found out that between 2024-06-29 02:00 and 2024-06-30 02:00 the whole salt directory was silently dropped from the upstream mirrors. Even packages.debian.org does no longer display any information about it. I was under the impression that the software stack of a stable/oldstable release does not change anymore (safe for security updates and suchlike), so I'm pretty flabberghasted by this. More so as I cannot find a mention about this on debian-devel, where I would assume such decisions would be discussed prior to the actual doing. Can somebody please shed some light on this? Best regards JD signature.asc Description: This is a digitally signed message part
Re: salt removed from mirror
Am Freitag, dem 09.08.2024 um 15:27 +0100 schrieb Simon McVittie: > Caution: This is an external sender. Please take care when clicking > links or opening attachments. When in doubt, contact the IT > Department > > > > On Fri, 09 Aug 2024 at 13:31:02 +, Johannes Drexl wrote: > > I was under the impression that the software stack of a > > stable/oldstable release does not change anymore (safe for security > > updates and suchlike), so I'm pretty flabberghasted by this. More > > so as > > I cannot find a mention about this on debian-devel, where I would > > assume such decisions would be discussed prior to the actual doing. > > > > Can somebody please shed some light on this? > > debian-devel primarily deals with development of the next version > of Debian, and the (old)stable releases are managed by the stable > release team. Removals and other more major changes in (old)stable > are > intentionally rare, but can happen. > > In the case of salt, it was removed from Debian 11 in the 11.10 point > release, as announced in > < > https://lists.debian.org/debian-stable-announce/2024/06/msg0.html> > . > > This was requested by a security team member in > <https://bugs.debian.org/1070175>, prompted by its removal from > unstable > in <https://bugs.debian.org/1069654>, which appears to have been > caused by > not having any volunteers willing to take responsibility for > maintaining > this security-sensitive package. > While I get the idea behind this, having salt (as a machine management package) removed from the official mirror in a stable release strikes me a bit odd - the already installed packages won't be removed, and as it is a management package, one could expect this gets installed in automated setups. This wouldn't be a problem as such, if the preseed file would accept a multitude of mirrors, alas all tests I've done in the past only allowed for a single source, and using late_command in the preseed to first inject an additional mirror and then install the package from there did not work as far as I remember. It seems I need to fall back to an old version of mirror & PXE package for the installation. > Older versions of the salt package continue to be available from > <https://snapshot.debian.org/package/salt/> but will not receive any > security or bug-fix updates. The upstream developers have their own > newer Debian-compatible packages available, > https://docs.saltproject.io/salt/install-guide/en/latest/topics/install-by-operating-system/debian.html > (these are not supported by the Debian project). > > (Also note that Debian 11 comes to the end of its normal support > lifetime > in a few days' time, on 2024-08-14, although the Debian LTS > subproject > plans to provide limited security maintenance for an additional 2 > years.) > > smcv Thx, I'm aware I'm on oldstable here, but replacing old systems is sometimes not as fast as I'd hope it'd be ;) BR JD signature.asc Description: This is a digitally signed message part
Re: What are desired semantics for /etc/shells?
I don't really get the point here: > Few people would probably *change* /usr/bin/screen to /bin/screen. Yes, because screen is not a shell. Screen is terminal multiplexer which just uses a shell. And as such wrappers go, they're not essential to the OS, but mere a nice to have user command. And now taking a look what /bin is all about: Quoting FHS 3.0: 3.4. /bin : Essential user command binaries (for use by all users) 3.4.1. Purpose /bin contains commands that may be used by both the system administrator and by users, but which are required when no other filesystems are mounted (e.g. in single user mode). It may also contain commands which are used indirectly by scripts. (further down there /bin/sh is even listed as a mandatory asset) And quoting FHS 3.0 further: 4.4. /usr/bin : Most user commands 4.4.1. Purpose This is the primary directory of executable commands on the system. Be aware on that topic that FHS 3.0 does not require /usr to be on the same partition as the root FS, not even being a local FS of sorts nor being exclusive for the current machine. Shared network storage is a valid option. On the other hand it is mandatory for /bin and /sbin they be available when no other FS can be mounted (i. e. no uplink, damaged /etc/fstab ...), thus they have to be on the root partition, hence the condition there has to be at least one shell physically available there for rescuing purposes. Now one could argue that everything that is not explicitely a mandatory asset should go to /usr/bin, and I tend to agree to that, but talking about shells in particular (and not wrappers) I'd say they're quite essential to a OS, so there's a valid reason for them to be in /bin. But then, I'm known to be a little bit of a bean counter considering those issues, and thus maybe not the best of advisers here. So take my comment for what you consider it worth. BR Jo signature.asc Description: This is a digitally signed message part
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)
Am Freitag, dem 16.07.2021 um 10:09 +0200 schrieb Thomas Goirand: > Merging binaries in /usr and getting rid of /bin and /sbin, at the > end, > WILL be an improvement. Debian cannot be the last distro not doing > the > move, I hope you understand that. > > Also, I'm having a hard time understanding why moving binaries around > should just break any system Well, I'm only an interested SysOp here, but I share his reluctance to embrace getting rid of /sbin and /bin. FHS 3.0 explicitely states that /usr is allowed to be not only on a separate partition, but even on a network device shared by other machines: Quoting FHS 3.0, chapter 4.1, Purpose of /usr: '/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to.' On the other hand /bin and /sbin need to be on the root partition in case mounting of other partitions doesn't work (as in "no network available"). Quoting FHS 3.0, chapter 3.16.1, Purpose of /sbin: '/sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin. Programs executed after /usr is known to be mounted (when there are no problems) are generally placed into /usr/sbin.' So yes, with getting rid of /bin and /sbin you break the systems emergency resilience and deviate from a known and not really that old standard. I'm not quite sure how this is an improvement - rather I'm curious how one could perceive this as such. For all I've seen in my time as a SysOp, I'd rather have my emergency tools in /sbin and /bin than booting a live system every time a server has broken mounts. That all said, I'm not fully against the change, I just don't see the benefit but instead quite a lot of problems down the road. BR Jo signature.asc Description: This is a digitally signed message part
