Re: Debian openssh option review: considering splitting out GSS-API key exchange
Am Di, Apr 02, 2024 at 13:30:43 +0200 schrieb Marc Haber: from being vulnerable to the current xz-based attack. Just having to dump an ALL: ALL into /etc/hosts.deny is vastly easier than having to maintain a packet filter. Stupid question, but if you put „ALL: ALL” into hosts.deny, couldn’t you stop the ssh daemon instead? ALL: ALL will block your ssh access, so it doesn’t matter if the daemon is running or not. Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
Am So, Dez 24, 2023 at 10:06:09 +0100 schrieb Gioele Barabucci: After the installation there would be no /usr/bin/gpg. Once the user installs, say, ggp-is-gnupg then /usr/bin/gpg will point to /usr/bin/gpg-gnupg. Users (and scripts) are still free to install the And if you want to change it, you have to download and install a new package (and remove another) instead of using a local command (update-alternatives) that doesn’t need an internet connection? Sorry, this is bullshit. -100. Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
Am Mi, Sep 14, 2022 at 08:41:32 -0400 schrieb Jeremy Bicha: I believe you are significantly overstating the consequences of this switch. It is just a dependency swap in meta-gnome3. The vast majority Maybe, but I remember when pulseaudio was forced upon us, even when it was not really ready because other distributions made the switch and to get more testing. Since PA ist now working very well (at least for me), I’m not interested in getting PipeWire as long as the upstream of PA is not dead. Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: The future of src:ntp
Am Mi, Jan 19, 2022 at 13:34:13 -0600 schrieb Richard Laager: For people that want something more than systemd-timesyncd, e.g. to get NTS, I think either are acceptable choices. It seems that the consensus Well, most people will use the default NTP server of the package and don’t have a NTP server in their network. And since Debian is trying to be as secure as possible, the default NTP server should be ntpsec with as much activated NTS entries as possible. Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: The future of src:ntp
Am Di, Jan 18, 2022 at 23:16:46 +0100 schrieb Marco d'Itri: I have no objections if somebody wants to work on packaging ntpsec, but I do not think that either ntp or ntpsec should be promoted over chrony nowadays. Besides from the fact that ntpsec is already packaged: Does chrony support NTS? If no, it should be clear which package should be promoted over the other. Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: Cancel "culture" is a threat to Debian
Am Di, Mär 30, 2021 at 12:15:54 +0200 schrieb Stephan Lachnit: It's supposed to represent everyone who fights for a future where You will never be able to represent everyone. Calling for RMS to step back, and everyone who was involved in that decision, really has nothing to do with cancel culture. We as a project that believes that diversity and democracy is important should *at least* publish a statement addressing these issues without signing (e.g. like KDE or the FSFE). Doing nothing is just straight ignorant, it's like saying "yeah we do free software but we don't really care what *the* free software foundation does". It just doesn't fit together. This is bullshit as well. The DFSG states that Debian software must be free for everyone, even it is used for evil purposes (like murder weapons). Any software with such upstream restrictions would be considered non-free. I consider this far worse than the RMS problem. letter. There is no problem with that even if the project as a whole signs the opposite letter. I wouldn’t be part of an organization that publishes such a letter. Shade and sweet water! Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: Release status of i386 for Bullseye and long term support for 3 years?
Am Sa, Dez 12, 2020 at 20:27:16 + schrieb Steve McIntyre: It's still quite new, but we have a package in the archive for this now: https://tracker.debian.org/pkg/debian-crossgrader Well, yes, but it is only in unstable. I tried to install it but apt wanted to replace many packages. Using aptitude with --without-recommends was less scaring but still not something I want to do on a stable system. Shade and sweet water! Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: Release status of i386 for Bullseye and long term support for 3 years?
Am Sa, Dez 12, 2020 at 18:09:02 +0200 schrieb Adrian Bunk: 4. People who wrongly installed i386 on amd64-capable hardware. Well, some releases ago befor multi-arch I used to install i386 even on am64-capable hardware if ram was quite low (=< 8GB) and if the chance wasn’t that low that you needed to install ia32-codec to watch ancient video formats. I wouldn’t do it anymore but at least one system is still in use, and there isn’t a real supported way to upgrade from i386 to amd64. Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
On Do, Okt 08, 2020 at 22:54:32 -0400, calumlikesapple...@gmail.com wrote: is probably very handy. Even more handy is the fact that you don't really need to learn the command name of your image viewer and your pdf viewer and your html viewer and you .dia viewer and your .mp3 player and every other viewer you might need to handle: only the 'open' command. I don’t know about that. Normally I use mupdf for pdf, but mupdf doesn’t allow copy & paste. So if I want to do this, I need another pdf program. For my FLAC music I use audacious for my playlists and ogg123 for CLI playing. If I want to open an image, I’m using qiv or gimp. Other rules apply for attachments in mutt, so mutt is using its own mailcap definitions. That’s why I need to know the different programs anyway. Why would I go for something like open which can only use one program for the file type? Many greetings, Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: Heads up: persistent journal has been enabled in systemd
On Do, Feb 06, 2020 at 13:25:06 +0100, Ansgar wrote: Given you wrote earlier that you moved all but one of your machines away from Debian, whatever Debian installs by default doesn't affect you anyway. Well, I still use Debian. In Testing you have elogind now as a complete systemd replacement. So I’m certainly not interested in too much activated systemd features, that could make things more difficult I have no problem installing a different MTA than Debian's default (exim), my preferred shell, my preferred editor and so on either. As long as you can do it, it’s fine. But you’ll certainly find more MTA or editors in the Debian archive than init systems… Shade and sweet water! Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: migration from cron.daily to systemd timers
On Mi, Jan 08, 2020 at 02:57:51 -0500, Noah Meyerhans wrote: visible to administrators. IMO the migration to systemd timers can be done more smoothly, so it's still preferable. Well, since you need to support non-systemd systems as well (like mine) the cron script is still needed (I don’t think these timers work with elogind). So the migration can only take place on systems running systemd. Shade and sweet water! Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: Integration with systemd
On Di, Nov 05, 2019 at 05:45:34 +0100, Ansgar wrote: Simon Richter writes: Yes, that's one of the questions I have asked: is systemd a core system component that we want to provide a stable release for, or is it one of the peripheral packages that users can upgrade to a backported version if they need a new feature, or has Debian relaxed its standards to accomodate systemd? I guess it can work the same as for src:linux? That is a core system component, but users can upgrade to a backported version. Well, you can have different linux kernels installed at the same time and choose from grub. So installing a newer kernel from backports won’t delete the kernel from the stable release. This won’t work for systemd. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | |If your life was a horse, you'd have to shoot it.|
Re: Please stop hating on sysvinit
On Fr, Aug 09, 2019 at 11:00:03 +0200, Ondřej Surý wrote: Unprivileged access to port < 1024. The socket-activated services can start as user since the port binding is done by the systemd, not the daemon. If the daemon supports different platforms, it needs a wrapper to bind to a port < 1024 and then drop privileges anyway. Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: default firewall utility changes for Debian 11 bullseye
On Di, Jul 30, 2019 at 01:52:30 +0200, Arturo Borrero Gonzalez wrote: Ok, after a couple of weeks, lets try to summarize: 1) switch priority values for iptables/nftables, i.e, make nftables Priority: important and iptables Priority: optional Nobody seems to disagree with this point. So I will be doing this soon. I’ve migrated my iptables scripts to nft. In the end it was easier than expected, and everything is running fine. What I’m missing: There was an iptables addon for using geoip databases. This is missing. I found https://aur.archlinux.org/packages/nftables-geoip-db/ It is not part of Debian, but I managed to use it. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | If your life was a horse, you'd have to shoot it. |
Re: default firewall utility changes for Debian 11 bullseye
On Mi, Jul 17, 2019 at 12:32:31 +0100, Thomas Pircher wrote: # iptables-translate -A INPUT -s 1.2.3.4 -p tcp --dport 587 -j DROP nft add rule ip filter INPUT ip saddr 1.2.3.4 tcp dport 587 counter drop Ah, thank you very much! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: default firewall utility changes for Debian 11 bullseye
On Di, Jul 16, 2019 at 11:23:43 +0200, Guillem Jover wrote: On Tue, 2019-07-16 at 11:07:15 +0200, Arturo Borrero Gonzalez wrote: as you may know, Debian 10 buster includes the iptables-nft utility by default, which is an iptables flavor that uses the nf_tables kernel subsystem. Is intended to help people migrate from iptables to nftables. Yeah, this was a great way to migrate, thanks! What is the problem with using iptables-nft compared to the new nft syntax? According to the documentation nft seems quite more complex. What would be the replacement for a simple single line like iptables -I INPUT -j DROP -s -p tcp –dport 587 ? What about other packages like fail2ban? Does it „hurt” if different programs are using iptables-nft or nft? Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: usrmerge -- plan B?
On Mo, Nov 26, 2018 at 11:05:02 +0100, W. Martin Borgert wrote: I personally don't care about usrmerge, but if it is useful to a relevant minority, we should not reject it. Who says we should reject the usrmerge package? The minority who wishes for it can install it for years. But I don’t want to get the /usr-merge forced upon my systems because this minority is obviously too stupid to install the package and migrate their systems on their own. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: usrmerge -- plan B?
On Mo, Nov 26, 2018 at 03:08:09 +0100, Marco d'Itri wrote: snapshot as well) would be hard and I disagree that the benefits of merged-/usr would be minor. There are no benefits of a merged /usr for users who don’t want to export /usr via NFS or want to use clusters/docker images/etc. And this is the majority of Debian users. So if a minority of users wants a merged /usr for their special cases they can use your package. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: PGP signature
Re: usrmerge -- plan B?
On Mo, Nov 26, 2018 at 09:24:40 +0100, Didier 'OdyX' Raboud wrote: usrmerge is in the archive for 3+ years now. What seems to be needed now is for a lot of us to actually _try_ it, find and report bugs, and get this through. Why, if it was intended as an optional package for people who want a merged /usr? If I don’t need or want a merged /usr I won’t install and test the package. The problem is that people are now talking to forcing the package on everyone. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: usrmerge -- plan B?
On Fr, Nov 23, 2018 at 03:14:44 +0100, Matthias Klumpp wrote: There are always unforseen issues to be expected when upgrading. And Of course, and since a dist-upgrade will bring newer software you may already have to fix configuration files. at the moment, the only issues that are known when installing the usrmerge package is when there are different binaries with the same name in /bin and /usr/bin (or /sbin), and I really don't think that this is actually a likely scenario. I don’t know but I’ve seen enough strange installations. It would be good if the usrmerge package would do a dry-run as part of the installation. If there are duplicate files the list will be printed (or mailed) and the installation will fail without breaking the whole upgrade process. The the admin can fix the problem later. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: usrmerge -- plan B?
On Fr, Nov 23, 2018 at 03:02:00 +0100, Hans wrote: Am Freitag, 23. November 2018, 14:47:28 CET schrieb Stephan Seitz: And how do you revert this change? As far as I have understand you can’t remove the usrmerge package and have your system in the old state again. Making an image of the whole hard drive is always a good idea. While this is easy done if the system is a VMware VM I know my fellow admins well enough that they will simply cancel the update because they are not interested in debugging the upgrade process for a single package they don’t need. So, that is, where "testing" is standing for. Testing before release You know I don’t have doubts that you won’t have problems (or very few) if you do a new testing installation. I don’t like Marco’s attitude but he is doing a good job. If he has tested his package as he said this isn’t the problem. But Debian/testing doesn’t mean testing on real servers which have „survived” different Debian releases, where different admins copied files from one location to another, or with some third-party software. If the update of 2% of our systems won’t work because of failing usrmerge I would be asked if Debian is the right distribution. Good point. However, this should be told to Microsoft admins or their deciders. ;-) But while there are no alternative Windows distributions Debian isn’t the only one and can be changed. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: usrmerge -- plan B?
On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote: If there are actual issues encountered, we can always revert a change And how do you revert this change? As far as I have understand you can’t remove the usrmerge package and have your system in the old state again. As others in the thread have mentioned they don’t see the risk with new installations but with old systems with different admins and third-party software. anyway. During distribution upgrades there is a lot that can be wrong and a lot of stuff the administrator needs to care about (config file Right, and it means he has enough to do and doesn’t want to debug the usrmerge. I don’t want to have a usrmerge at a dist-upgrade. You don’t really know the sequence of the package updates. I think the risk is too big to have a partial upgraded system. with information to the system administrator on what to do in case of an error, and works for 98% of all users anyway, I see no reason not If the update of 2% of our systems won’t work because of failing usrmerge I would be asked if Debian is the right distribution. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: usrmerge -- plan B?
On Mi, Nov 21, 2018 at 01:09:47 +0100, Marc Haber wrote: Debian, is, btw, also losing quickly for not keeping pace with the world around it. Or maybe it scares people away with its bullshit decisions. Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Should the weboob package stay in Debian?
On Do, Jul 26, 2018 at 01:59:08 +0200, Martin Steigerwald wrote: Stephan Seitz - 26.07.18, 11:10: I don’t understand the problem. No one forces anyone to keep the package in Debian. Upstream made clear it isn’t interested in changing the names. The point is that it currently is in Debian, binary names unchanged: Yes, obviously neither FTP masters nor maintainer had a problem with the names. Of course it can be changed. Exactly. Debian has already removed packages, so it can remove weboob as well. The question is who can decide the removal if the maintainer doesn’t want to remove it? TC? Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Should the weboob package stay in Debian?
On Do, Jul 26, 2018 at 09:32:34 +0200, Martin Steigerwald wrote: Adam Borowski - 26.07.18, 03:09: I for one don't protest inclusion of the Bible in Debian, despite that text having been the cause of 100M deaths, nor Quran with its 75M. I That text did not *directly* cause anything. It were still human beings killing one another. The book is not responsible for anything. Human beings are. Sounds like the US weapon industry. But they are equal. Which means are to be treated equally fair and with respect. I do not see that with the weboob package being included in Debian with binary names unchanged. I don’t understand the problem. No one forces anyone to keep the package in Debian. Upstream made clear it isn’t interested in changing the names. How would a world free from power struggle between men and women look like? (Or even free from power struggle between any of the expressions of that one consciousness?) Such a world will never exist because this struggle is part of the human being. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Should the weboob package stay in Debian?
On Mi, Jul 25, 2018 at 09:25:11 +0200, Ole Streicher wrote: Obviously we renamed packages (which made us incompatible with the rest of the world) already if needed. Rememver iceweasel or icedove? Yes, I do. And I remember the problems with this renaming. And do you remember the reason? This was not a „I don’t like the name” case, it was a legal one. And I believe everyone is glad that we can use firefox and thunderbird again. In other cases there were name clashes. And this could go to the TC. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Should the weboob package stay in Debian?
On Di, Jul 24, 2018 at 01:19:35 +0100, Matthew Vernon wrote: Stephan Seitz writes: He certainly should NOT rename any parts of the package without upstream consent. Why not? I can see an argument about not confusing users (though transitional packages / a weboob-offensive could be made for the old names / etc), but I don't think that's where you're going here. Well, upstream has chosen these names. Besides from the fact that the project and its applications are known by these names (how would you tag the package, so that someone who knows the project would find the right package with apt or apt-file?) it has something to do with politeness (in my opinion). If you wish to package the work of others you should use the right names (we don’t have any name clash). If you have a problem with the names but upstream doesn’t (it seems to be a Frensh project, even with female developpers), you’re free to drop the package. Or, as Marvin Renich noted, you can fork the project. Then you can do as you please as long as you do the work. Then time will tell if you win the users of the old project. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Should the weboob package stay in Debian?
On Di, Jul 24, 2018 at 11:49:55 +0100, Matthew Vernon wrote: accept that they are authoritative in this regard. Therefore, you should rename the offensive parts of this package. He certainly should NOT rename any parts of the package without upstream consent. If upstream doesn’t approve (and it seems that these names are part of upstream’s working culture), then the other choices are removing to package or keeping it as it is. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Firefox 60esr on Stretch ?
On Fr, Mai 04, 2018 at 09:12:39 +0200, Moritz Mühlenhoff wrote: Same as all previous extension breakages incurred by ESR transitions; not at all. Apart from enigmail those are all not updated along in stable, this doesn't scale at all. If you want your extensions to be kept compatible, get them from the Mozilla addons page like every other Firefox/Thunderbird user. Then drop firefox/thunderbird from debian as well. If you don’t want to do it right (meaning with all the extensions), then don’t do it. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Please do not drop Python 2 modules
On Mi, Apr 25, 2018 at 07:30:15 -0400, The Wanderer wrote: The simple, obvious means of installing Python in Debian - either manually, or as a dependency of another package - is via the package named 'python'. At present, in current testing, doing this will pull in I don’t think you can see it this way. For now /usr/bin/python is a link to python2 and, as was mentioned on this list, always will be until a time comes when version 2 will be so long dead that no one remembers it. If you want version 3 you have to install python3. [stse@osgiliath]: dpkg -s python Package: python This package is a dependency package, which depends on Debian's default Python version (currently v2.7). [stse@osgiliath]: dpkg -s python3 Package: python3 This package is a dependency package, which depends on Debian's default Python 3 version (currently v3.6). As you can see both packages pull in their default version of python. Of course someone can make a transition so that python will be renamed to python2 and python3 will be renamed to python. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Bits from the release team: full steam ahead towards buster
On Do, Apr 19, 2018 at 11:00:37 +0200, Christoph Biedl wrote: But being human I prefer names over numbers, even if it's just for aesthetic reason - "buster" is just more comfortable than "debian10". No, it’s not. I know that my systems are running Debian 8 or 9, but I always have to think if stretch is 9 or was it jessie. I have to look up the name not the number. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Bits from the release team: full steam ahead towards buster
On Mi, Apr 18, 2018 at 08:52:25 +0300, Adrian Bunk wrote: On Wed, Apr 18, 2018 at 11:14:50AM -0400, Michael Stone wrote: specifically, what locale sorts english words differently than LANG=C? Estonian (et_EE) sorts z between s and t. Boah, thanks for all the examples. I didn’t know you could sort so differently. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Bits from the release team: full steam ahead towards buster
On Mi, Apr 18, 2018 at 11:14:50 -0400, Michael Stone wrote: specifically, what locale sorts english words differently than LANG=C? Since English words (or texts) can have 8bit characters you may get a different sorting in in different locales. If you mean ASCII words I don’t know of any sorting difference. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Bits from the release team: full steam ahead towards buster
On Mi, Apr 18, 2018 at 02:47:11 +, Holger Levsen wrote: On Wed, Apr 18, 2018 at 10:23:29AM -0400, Michael Stone wrote: really? there's more than one alphabetical order for english words? yes, sorting depends on the locale... :) Can you please give an example for the sorting difference in different locales if you only have english words (and I would say it means only ASCII in this case)? I know that there are differences if you have words containing non-ASCII characters like ü. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: OpenSSL disables TLS 1.0 and 1.1
On Mo, Aug 07, 2017 at 08:52:41 +0200, Marco d'Itri wrote: I think that I live in a real enough world (commercial web hosting), and my customers have been asking for a while to disable at least TLS 1.0 Well, if I understand it correctly, apache/openssl in SLES11 SP4 only support TLSv1. Long term support for SP4 ends in 2022. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: OpenSSL disables TLS 1.0 and 1.1
On Mo, Aug 07, 2017 at 11:18:38 -0500, Michael Lustfield wrote:
Is there an actual need for the removal of TLS v1.{0,1}? Are either
considered broken or unsupported by upstream? If not, I'd be much more
That’s I like to know as well.
Doing a quick check on my appliances I could find the following
TLSv1-only devices:
- some iDRAC (Dell)
- Netapp Filer
- Cisco Web Security Appliances
And what about mail appliances? If they offer only TLSv1 then the Debian
mailserver will fallback to unencrypted transfer. I don’t think this is
a good idea.
Shade and sweet water!
Stephan
--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |
smime.p7s
Description: S/MIME cryptographic signature
Re: "not authorised" doing various desktoppy things [and 1 more messages]
On So, Jan 15, 2017 at 04:43:11 +, Ian Jackson wrote: I have just uploaded systemd-shim 10-3~exp1 to experimental. I seems to fix the problem for me. Depending on feedback, I will upload this to sid in the next few days. Thank you very much. I don’t have problems either. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: [Letsencrypt-devel] Certbot in Debian Stretch
On Fr, Nov 25, 2016 at 10:34:32 +0100, Thijs Kinkhorst wrote: FWIW certbot from jessie-backports has been working fine for me in several contexts. Yes, here as well. The only problem was the renaming from letsencrypt to certbot. Many greetings, Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: OpenSSL 1.1.0
On Mi, Nov 16, 2016 at 02:31:28 +0100, Marco d'Itri wrote: ChaCha20 is hardly obscure: if it is to you then I fear that your opinion on this issue is not informed enough to be useful. It doesn’t matter in the end. If no one wants to delay the next release until all applications support OpenSSL 1.1.0 in a secure way even is upstream may not be interested in patching the software for now then we can’t have version 1.1.0. And there is still the problem that 1.1.0 is not supported as long as the available LTS version. Many greetings, Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: support for merged /usr in Debian
On Fri, Jan 08, 2016 at 10:11:07AM +, Jonathan Dowland wrote: grml is packaged and is an apt-get away. It's third-party in just the same way that the linux kernel, or exim are. Wrong. You have a wrapper package that adds grml iso from /boot/grml to the grub.cfg. You have to download the grml images yourself and you need the space to save the images in /boot/grml. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: support for merged /usr in Debian
On Fri, Jan 08, 2016 at 11:49:48AM +0100, Michael Prokop wrote: We've an open wishlist bug report for the "download the Grml ISO" part (#754393) which we plan to resolve soonish, jfyi. Ah, thank you very much. That still leaves the space problem. Only my newer systems where I knew that I wanted to have grml in /boot are having enough space. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: PGP signature
Re: vlan support en* or br*?
On Wed, Jan 06, 2016 at 04:07:40AM +, Ben Hutchings wrote: On Wed, 2016-01-06 at 12:46 +0900, Seyeong Kim wrote: I checked vlan source http://anonscm.debian.org/cgit/collab-maint/vlan.git/ debian/network/if-pre-up.d/vlan, if-post-up.d/vlan … and not support en* or br* which are quite common nowadays. need to file a bug or just customize and use it myself? The vlan package is obsolete. You could perhaps replace it with something based on iproute. I don’t think that the vlan package is obsolete. It provides you with stanzas for your /etc/network/interfaces to easily configure vlan interfaces. You can do this with the ip command but you have to do everything manually. The same goes for the ifenslave package. So, yes, someone can file a bug. Greetings, Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: PGP signature
Re: pro-active removals (was: Re: suggestion to add package vlan to default instalation DVD)
On Thu, Sep 17, 2015 at 10:55:58AM +0200, Andreas Henriksson wrote: this, I think it would be a *service* to our users if we removed this (and many other packages in similar situation) from the archive so that we don't fool users into using (or wasting time even looking at) long-deprecated software. If the package is no longer available that means It is not a service if you remove packages without replacement strategy. I don’t care if I use the package iproute2 or vlan/ifenslave to configure VLAN interfaces and/or bonds as long as I have documentation how to do this in /etc/network/interfaces in an easy way. The packages vlan and ifenslave are working very well. That said I think it would be very cool if I could configure VLANs and bonds with the Debian installer. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Proposal v2: enable stateless persistant network interface names
On Wed, Jun 03, 2015 at 12:01:34PM +0200, Martin Pitt wrote: However, on a desktop you don't ever care about the device names, and Of course you do. How will you use tcpdump or tshark without the device names? In most desktop setups a „tcpdump -i eth0” is the right command. higher-level firewall tools will also hide this. After all, we survived the step from /dev/sda1 to UUID=112233DEADBEEF... as well :-) Well, but /dev/sda1 is still available. And I prefer /dev/sdaX because I have far less problems with it than with UUID=XXX. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: Proposal: enable stateless persistant network interface names
On Sat, May 09, 2015 at 02:36:30PM -0700, Josh Triplett wrote: Why? What does a stable name matter in the case you mentioned? Because I don’t want to look up the interface name of the day when I use wireshark/tshark? Because I don’t want to change my iptables scripts which is working very well the way it is? Were you actually using ifupdown to manage the varied set of wireless networks? Because if not, then the name shouldn't matter. Yes, I’m using ifupdown. Besides USB NICs don’t have to be WiFi. You may switch the the naming scheme in virtual environments, but only here. SLES is using some strange interface names like em1 or p1p2, but I hate it. I prefer my eth0 name. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Proposal: enable stateless persistant network interface names
On Sun, May 10, 2015 at 07:09:41PM +0200, Marc Haber wrote: On Sun, 10 May 2015 17:11:03 +0200, Vincent Bernat ber...@debian.org wrote: The disease is that actual servers running actual free software can break at each boot because we cannot have both a persistent naming scheme and use the eth* prefix is worse Just for the record, an unexpected interface name change hasn't happened in my professional career in more than ten years. Plugging persistent network naming with -this- imminent danger destroys the pro-faction's credibility. Same here. I have never seen unexpected interface changes. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Bug#775436: ITP: xlennart -- An XBill fork but with Lennart and SystenD instead of Bill and Wingdows
On Fri, Jan 16, 2015 at 07:32:41AM +1100, Riley Baird wrote: (Also, in any case, don't you think that this game is going a little too far? It's fine to be opposed to systemd, but don't do to Lennart Well, do you see a difference to the original game with Bill Gates? Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: DE features dependent on Systemd
On Wed, Dec 03, 2014 at 03:08:55PM +, Simon McVittie wrote: Feature 2: if the first user created via the installer logs in via a non-local mechanism (typically ssh) [3], they can still play and record audio. If you expect that the first user created via the installer is Yes, and playing audio via ssh is a feature I used since the 90s. Anti-feature 3: while a second user is logged in, the first user can log in via ssh or whatever, turn on the microphone and listen to the second user, violating reasonable privacy expectations (and, less important, True, but completely irrelevant for this case. If this ssh-user is not a ssh-only user then he has physical access to the system/room and can use any other kind of bugging device he wishes. So if you don’t trust your users, don’t give them accounts or access to the system. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie
On Fri, Nov 28, 2014 at 02:41:23PM +0100, Marco d'Itri wrote: On Nov 28, Svante Signell svante.sign...@gmail.com wrote: a) Upgrades should _not_ change init: whatever is installed should be kept. I disagree: upgrades should get the default init system unless the system administrator chooses otherwise. Of course not. syslog-ng was not replaced by rsyslog when Debian changed the default syslog. The grub1 bootloader was not replaced when Debian changed to grub2. If Debian changed from exim to postfix the existing MTA would not be changed. So keep your hands of the init system on upgrades. b) New installs should get systemd-sysv as default init with a debconf message about alternative init systems. It would be totally unacceptable to waste the time of every Debian user with pointless advertisement. This question could be part of the expert menu. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie
On Fri, Nov 28, 2014 at 04:00:42PM +0100, Thorsten Glaser wrote: On Fri, 28 Nov 2014, Stephan Seitz wrote: Of course not. syslog-ng was not replaced by rsyslog when Debian changed the default syslog. Note that syslog-ng was not the default, but sysklogd (which was) wasn’t replaced either. Thankfully. Are you sure that we didn’t have syslog-ng between sysklogd and rsyslog? I’m getting old… The grub1 bootloader was not replaced when Debian changed to grub2. Actually, it was, unless you installed the fresh “grub-legacy” package before upgrading, which was mostly a no-op though. And forgetting to do so *did* hose some obscure systems. Hm, I got the info that a new menu entry was added to the grub1 menu to chainload into grub2 (not the boot default). After some testing you had to enter a command to install the grub2 bootloader. Without it grub1 was active with its menu.lst. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: init system policy
On Thu, Nov 20, 2014 at 09:16:46PM +, Philip Hands wrote: Would it perhaps make sense to have etckeeper additionally keep track of files in /lib directories for packages that have this /etc overrides /lib scheme? Such packages could add their config-outside-etc I don’t think so, especially since those kind of files are scattered over the fs (other files are in /usr/share). We can discuss what those files should be: - configuration files that were not put in /etc because of shortcomings in the rpm conffile handling - „outsourced” defaults of the application In the first case the files should be moved backed to /etc. In the second case changed defaults should be documented in the changelog or readme. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: free choice in installer?
On Tue, Nov 11, 2014 at 12:19:06PM +0100, Andreas Tille wrote: From what research are you taking this generalisation? All non-IT experts I know (proof by counter-example) would be really happy to have no choice but rather one single option which works. You might also like Of course, but the problem is that they don’t share the same opinion about the working solution. Or we wouldn’t have different editors, window managers, desktop environments, monitoring tools, etc. to think about all those Win+OSX users who have no problem to accept what they get. I admit regarding init system I feel like them and Well, that’s the reason why I’m using Linux because I don’t accept what I get with Windows. And if you have noticed the complains about the ribbon in Office or the Win8 GUI then you’ll see that Windows users don’t always accept what they get. So please be careful to do generalised statements about people by assuming that all people are thinking like you. If you don’t want choices you can stay with Windows. There is no reason to make Linux like Windows. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Migration from cron to cron-daemon?
On Sat, Oct 18, 2014 at 08:07:25AM +0200, Andreas Metzler wrote: Now systemd-cron is supposed to be fixed and bcron was changed in August to provide the virtual package instead of cron which is why there are new bug reports cropping up. So, if I want to write bug reports, what is now the correct expression for cron? cron-daemon|cron? Is this a release critical bug? As a testing user I now have problems using bcron. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Migration from cron to cron-daemon?
Hi! I sent the attached message to debian-release, but I was told to ask in debian-devel. So here is the mail. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | ---BeginMessage--- Hi! Is there currently a migration from „cron” to „cron-daemon” as virtual package? New packages like brcon-run don’t provide cron anymore but cron-daemon. And many packages like exim4-base or mgetty-fax haven’t changed their dependencies (and other packages their recommends). Some packages have already bug reports for this case. But shouldn’t this be a reason for a mass bug filling? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature ---End Message--- smime.p7s Description: S/MIME cryptographic signature
Re: systemd is here to stay, get over it now
On Thu, Jul 03, 2014 at 08:40:59PM +0200, Matthias Urlichs wrote: The problem is that some people bitch endlessly abut how evil systemd is _instead_of_ producing software (not just patches) to replace what systemd offers. But if they don’t want the systemd features why should they write software to replace systemd? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: systemd-fsck?
On Tue, May 13, 2014 at 11:06:10AM -0700, Russ Allbery wrote: Thorsten Glaser t...@mirbsd.de writes: • no /etc/init.d/$foo (to tabcomplete, no less!) any more I've been telling people to stop using this for years. You should stop Doesn’t matter in mixed environments. Suse SLES11 has the service command as well but no tab completion and no package bash-completion. So what do you think people will use in the end? service foo action works across Linux distributions, with or without systemd, and does the right thing. Of course, as long as you know the name foo. And of course foo in Suse may be an other name as in Debian (sshd - ssh). • the init system breaking init scripts hand-written by people who don’t really know what they’re doing, have not even heard of LSB, much less “units” This was indeed a more difficult transition... which we already did years ago when we switched to dependency-based boot. Which did cause We still have init scripts without LSB headers in our environment. No one is planning to fix them. There is even new third party software shipping init scripts without LSB headers. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Debian default desktop environment
On Fri, Apr 04, 2014 at 10:03:46AM -0300, Undefined User wrote: This involves personal taste. But when talking about new users or not-that-advanced users, I'm really suggesting Gnome 3 to be the choice of the project. But what are your definitions of „new users”? Someone who has never used Linux before (but maybe Windows and wants to change from his old XP, I don’t think he will like Gnome3)? Or really a new user? As far as I understand Gnome3 needs more resources than XFCE and modern hardware. The default desktop should be moderate. If you want more eye candy and bells and whistles you can install bigger desktop environments. As far as I know the installer can’t do a hardware check and switch desktop environemnts fitting to the system. I know that its size is bigger than Xfce and it takes more resources, but it represents the evolution of a great desktop environment. And it is (and looks like) today. No, it’s terrible and keeps you from getting your work done (at least in my case). As I said before, we can't deny that a lot of people hate changes. But it's part of the process. Each product, when getting big changes, faces it. Windows 8 is a good example. Yes, Win8 is horrible. But you don’t have to go that far. I know people who refused a new system with Windows 7 because it didn’t work the same way as Windows XP. So they kept the old hardware and the old system. My mother is using Debian 6 with Gnome 2. I don’t know if I will ever update this system. Gnome 3 is not a solution, and I’m not interested in teaching XFCE. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Debian default desktop environment
On Fri, Apr 04, 2014 at 04:13:27PM +0200, Josselin Mouette wrote: Le vendredi 04 avril 2014 à 15:25 +0200, Stephan Seitz a écrit : and modern hardware. This is no longer a requirement in jessie, at least on x86 where llvmpipe is now accepted as a GL engine. Ah, thank you. The default desktop should be moderate. If you want more eye candy and bells and whistles you can install bigger desktop environments. The default desktop should be functional and easy to use. I don’t call Yes, and what means „functional”? XFCE is of course functional, heck, even fvwm is functional, and I know people who still use it because they only have one config file to copy to a new machine and their desktop is ready. My mother is using Debian 6 with Gnome 2. I don’t know if I will ever update this system. Gnome 3 is not a solution, and I’m not interested in teaching XFCE. Looks like you are deciding in place of your mother what is good for her. And I don’t think you should in this case. GNOME 3 is very popular Of course I do because she will ask me what she has to do now. She doesn’t try and she doesn’t experiment. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Bits from the Security Team
On Thu, Mar 06, 2014 at 12:21:06PM +1100, Craig Small wrote: On Thu, Mar 06, 2014 at 12:54:00AM +0100, Vincent Danjean wrote: I'm not sure I will let this setup (hidepid=1) on my computers. My current POV (that can change) is that I prefer to be able to do the maximum of thing as a normal user (top, ps, read log (I'm in the adm group), ...) ans switch to root when I really need to do some modifications. You apparently can have a special group that can see everything. Aren’t there PAM modules which can grant capabilities to certain users? That might be worthwhile for a default. It makes things like pstree look odd, so I'll be expecting some new bug reports. It will break software like nagios with check_procs. Any ideas how one can solve this? dpkg-stateoverwrite doesn’t support capabilities, only the standard chmod commands. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Bits from the Security Team
On Thu, Mar 06, 2014 at 04:32:34PM +0100, Guido Günther wrote: Luckily this is not the case. :) root can see other users' /proc entries just fine. Perhaps the documentation should be improved. I should have checked the code first. If I read that correctly CAP_SYS_PTRACE is necessary here. I've forwarded a patch upstream. I did a „setcap cap_sys_ptrace+eip /usr/lib/nagios/plugins/check_procs”, but a normal user can’t still check for running programs of another user. What did I wrong? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Bits from the Security Team
On Fri, Mar 07, 2014 at 02:51:41PM +0100, Matthias Urlichs wrote: I did a „setcap cap_sys_ptrace+eip /usr/lib/nagios/plugins/check_procs”, but a normal user can’t still check for running programs of another user. What did I wrong? check_procs is a script, not a real executable. Wrong. [stse@osgiliath]: file /usr/lib/nagios/plugins/check_procs /usr/lib/nagios/plugins/check_procs: ELF 64-bit LSB shared object… If I do a „chmod u+s check_procs” it works. But I think capabilities are a safer solution than s-bit. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: pulseaudio related problems....
On Mon, Feb 17, 2014 at 04:26:31PM +0800, Chow Loong Jin wrote: On Mon, Feb 17, 2014 at 09:18:51AM +0100, Matthias Urlichs wrote: As an example, most users who use systemd probably still restart services using /etc/init.d/service restart, just because it works. It's simply less to type if you don't otherwise like bash-autocomplete. :-P Really? I've been using service service restart which autocompletes well too, and is even less to type. Works well with systemd, upstart, and sysvinit. But only if you have the package bash-completion installed and activated. /etc/init.d/service is always working with auto completion. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: FFmpeg vs. libav packaging
On Fri, Feb 14, 2014 at 01:03:02PM +0100, Moritz Mühlenhoff wrote: But we still try to minimise such cases as much as possible. And for libav/ffmpeg this simply isn't managable at all due to the huge stream of security issues trickling in. We need definitely need to pick one solution only. And how is this problem solved? The library which most software can use or the library which has a maintainer? I’m using the Multimedia repository anyway because I want MythTV which is only available there. So I have ffmpeg. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Wed, Feb 12, 2014 at 11:39:06AM +, Darac Marjal wrote: But the normal case is that uninstalling a software you also stop getting the functionality it provides, with pulseaudio you START getting the functionality it claims to provide by uninstalling it. Really? Uninstalling Pulseaudio gives you a graphical interface for moving streams of audio between devices? Uninstalling Pulseaudio gives you software mixing of audio streams? Uninstalling Pulseaudio gives you Alsa is using the DMIX plugin for years, and before that I always had soundcards with hardware mixing. Simply buy the proper tools. the ability to stream your audio across the network? And if you don’t need these features? Well, yes, if you've done the work to set all that up externally to Pulseaudio, then of course you don't need Pulseaudio(!) Most people simply want to play audio, no streaming, no stream moving, etc. I have a USB soundcard. If I power it on pulseaudio doesn’t recognize it or only the analog output (I want to use the digital output). I have to restart pulseaudio (even with the current version in Debian Testing). And now guess what is always working? Right, Alsa. If necessary it takes less than 10 seconds to reconfigure the sound device in the application. So why should I use pulseaudio? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Wed, Feb 12, 2014 at 01:36:14PM +0100, Matthias Urlichs wrote: Snarkiness aside, IMHO it makes much more sense to have the most-featureful init system be the default, because then those features actually get used and tested -- and thus the situation will be more reliable than if only those users/sysadmins switch to systemd who actually _are_ desperate for its features (as opposed to, say, those who are skeptics but find that they won't want to miss those selfsame features once they get used to them …). Well, sounds like pulseaudio which got „forced” on the users and broke many setups to find bugs. Users (at least users from Debian Stable) are not beta testers. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: GnuTLS in Debian
On Mon, Dec 23, 2013 at 10:54:49AM -0800, Russ Allbery wrote: but I think we should ask a real lawyer and not rely on careful parsing Yes, this is true, but I’m wondering how many lawyer you mean to ask? Is one enough? After all this is a difficult question, and you will only get the final answer from a judge in the end. Or do we need to ask different lawyers in different countries? Is the answer in one country enough? This may affect mirror operators. Merry christmas! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Sun, Nov 10, 2013 at 11:25:32AM +, Matthias Urlichs wrote: Want more features in your init script? Like, say, a reliable way to figure out if any parts of your server are still running after it crashed? Or a way to determine that it has started up correctly? You don’t want anything like these in your local init service. For such tests you have Nagios, Icinga or similiar daemons. And they can do much deeper checks, e.g. can you login into your webservice because your database backend on a different server is available. I don’t mind if you want systemd, but don’t force it on others. There are no features in systemd that I would dump the well known sysvinit. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: systemd .service file conversion
On Sat, Jun 01, 2013 at 09:44:05PM +0200, Wouter Verhelst wrote: FWIW, I happen to agree with Marc. Having everything in /etc makes it *much* clearer what the actual current configuration is; it also means that if the defaults change on upgrade, your environment doesn't suddenly start acting differently or inconsistently. Not only this, you see if this service can be configured via /etc by looking in /etc for fitting files. How should I know that I have to look for configuration files in some lib directory and know to which place I have to copy them in /etc? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Mon, Nov 05, 2012 at 06:12:53PM -0200, Henrique de Moraes Holschuh wrote: I would like to bring to your attention the improved support for system processor (CPU) microcode updates, for x86/i686/x86-64/amd64 systems that was recently added to [non-free] Wheezy. Alas, this will not work for XEN users because I can’t update the microcode in Dom0 with xen-hypervisor 4.1. There exist kernel patches (over a year old), but according to the xen-devel ML they are not good enough to be included in the kernel. With XEN 4.2 the hypervisor can load the CPU microcode. Would this be a reason to include XEN 4.2 in Wheezy? Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning
On Sun, Aug 19, 2012 at 07:59:00PM -0400, Chris Knadle wrote: Related note: I likewise repeatedly have confusion over how to deal with testing Network Status from within shell scripts for doing operations that require network access. As a for instance a common suggestion for keeping GPG keys up to date is to set a 'gpg --referesh-keys' operation as a cron job, which doesn't make sense to do if the device the script is run on is offline, And how do you want to do this check? Even if ethtool says, the interface is up, this doesn’t mean, your DSL router has a WAN connection running. And if it has, it doesn’t mean you can reach the keyserver. So you can use something like „fping -q keyserver”, if the keyserver is pingeable. Any other check is not really usefull. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning
On Mon, Aug 20, 2012 at 01:08:53PM +0200, Bjørn Mork wrote: Never mind wireless lan where you've got a well defined kernel API. Try to configure a modern 3G/LTE modem using ifupdown, and you will see the Is this something different from an UMTS usbstick? I plug it in, get a /dev/ttypUSB0 and do a „pon umts”. No need for NM and Co. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning
On Mon, Aug 20, 2012 at 02:19:19PM +0200, Bjørn Mork wrote: Stephan Seitz stse+deb...@fsing.rootsland.net writes: On Mon, Aug 20, 2012 at 01:08:53PM +0200, Bjørn Mork wrote: Never mind wireless lan where you've got a well defined kernel API. Try to configure a modern 3G/LTE modem using ifupdown, and you will see the Is this something different from an UMTS usbstick? [Good explanation snipped] Thank you very much. But yes, if „pon umts” is enough for you then you don't need NM (or even ifupdown - pppd and vim will do). Right, that is enough for me. I use the UMTS stick only in the holidays about three weeks each year. And I’m glad I will get GPRS in the Austrian mountains. Different LED colours show me the kind of connection. It seems I have to be careful if I have to buy a new one. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: can we (fully) release-goal decommissioning of trolls
On Mon, Aug 20, 2012 at 12:38:07PM +0200, Josselin Mouette wrote: It seems the desired scenario for NM is that /e/n/i is empty Yes. This is actually what happens on usual setups (one interface, DHCP without any special options) upon NM installation. Well, until some weeks ago I never had a desktop system (even at work) with DHCP, simply because the Linux system are developer systems with different VLAN interfaces. At home my systems have static IPs as well. “wonderful” ifupdown… I guess some of us around here have other words to describe it. Maybe. For me NM was always a PITA, I always got better results with ifupdown. It is not perfect, certainly, but it works very well for me. 10 years ago, we had people complaining about ORBit. Then later they complained about D-Bus and pmount. Recently it was about PulseAudio. Now Well, Pulseaudio has its problems (you can ask the MythTV guys what they think of it). It never really worked for me with MythTV. And if you only have one audio device, chances are high that you don’t need it anyway. they don’t want to see their precious 30-year-old systemv and ifconfig crap replaced. Well, if it isn’t broken, don’t fix it. There seem to be enough people who don’t have any problems with your „systemv and ifconfig crap”, no matter how old. And they are not interested in getting new buggy software for the core system by force. So if you think, you need something new, fine, make it. But don’t break other people’s setup. These people are the disease. They are toxic to the community and tend Why, thank you. I think that these people are a disease who are always trying to drag down Linux to Windows level and are forcing their software crap on others, because they think it is so good that every one has to use it. And I would wish those people would go away to Windows. There they can play with shiny new software which doesn’t really work. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning
On Sun, Aug 19, 2012 at 07:26:46PM +0200, Christoph Anton Mitterer wrote: Until recently all that wasn't a big problem, because one was easily able to simply not install NM, but nowadays more and more packages start to depend on it (of those I know, most notably gnome-core) or at least use it's functionality to determine whether one is online or not. I don’t use NM, but I have it installed (you mentioned the dependencies). I have a „exit 0” in the init script, so NM won’t be started. I don’t see any problems with other applications (e.g. Pidgin). So try it, and if it works for you, you can ignore NM. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Future of update-rc.d in wheezy+1
On Thu, Jun 28, 2012 at 10:52:23AM +0100, Roger Leigh wrote: On Thu, Jun 28, 2012 at 10:44:53AM +0200, Goswin von Brederlow wrote: The numbers specified for update-rc.d must be well ordered according to the dependencies specified in the LSB headers. That means that that update-rc.d could keep a record of the numbers specified and check that the numbers are valid even though sysv-rc/insserv then ignore them. While we could expend the time and effort to do this, I do have to question why. What would be the point of this? No one is using those numbers, so why retain them? It seems, to me, to be an entirely pointless waste of valuable developer time. And not just my time, but for every developer who would need to continue to test and validate the numbers for their scripts. We have dependencies for a reason, and the sequence numbers are now nothing more than a historical artifact. Well, I’m using file-rc on all my systems for many years. - „vi /etc/runlevel.conf” is easier than working with strange symlinks; - if I don’t want a service to start, I can replace „2,3,4,5” with „-”; - third-party software without Debian package doesn’t use update-rc.d; getting it to start is easier if I only have to edit one file (runlevel.conf); I have never used dependency based booting. - old systems had to many old init scripts without LSB headers, so the upgrade failed; - some software needs a database, but the database server may not be the same server, so the software can’t have a dependency on the database server; so I have to overwrite the dependency configuration in some way; - third-party software doesn’t have any LSB headers; IIRC the upgrade to dependency based booting doesn’t fail anymore if you have initscripts without LSB headers (they are now running at the end of the boot process), but for now I still don’t see any reason to change. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sat, Jun 23, 2012 at 11:43:03PM +0200, Wouter Verhelst wrote: On Thu, Jun 21, 2012 at 03:46:16PM +0200, Stephan Seitz wrote: So most of your Debian systems have several users working at the same time on the same system? Okay, then you have a different user base. webserver. Sorry, I ignored servers. I don’t think that anyone will install a server with a default installation because you have more special cases (separate database partition, separate mailbox partition, etc.). I still think that the SSD problem is not a valid concern as long as we don’t have solutions for /var and log daemons. There is more traffic in /var than in /tmp. Yes, /var produces changes to storage, too, but that doesn't mean we shouldn't optimize /tmp because we can't optimize /var. That makes no sense. But if you move the /tmp access away (see below), then you don’t need tmpfs at all. I'm not saying we should optimize for SSDs. I'm just saying that storing on tmpfs is beneficial for SSDs. See below. [/ramtmp not a good idea] Well, why? Because it would end up being a directory that nearly nobody would use directly. Those who want to use a ramdisk will just remove that directory (or make it a symlink) and mount /tmp on tmpfs instead, and those who don't want to use it will probably just ignore it. I don’t think so. Having a disk based /tmp that gets cleaned after reboots and having a ramdisk /ramtmp will give you the choice which directory you want to use for a special application. Your video encoder example could certainly use /ramtmp, even if you have to patch the encoder in Debian to do so. The temporary video files of the web browser can stay in /tmp, as well as big powerpoint temporary files of libreoffice. And I don’t think that most user only want one solution. Also, if deciding on a reasonable default for /tmp is difficult, think about deciding on a reasonable default for individual packages. That's going to be even harder. Sometimes maybe. But you will certainly get some hundred of megabytes of tmpfs space. So if you know that your temporary file will be smaller, you can use /ramtmp. Besides we can look for other places to use tmpfs. What about /var/lib/amavis/tmp? The initscript could create a tmpfs. Meanwhile, you've got a non-FHS directory on your system that is of no immediate use. Your later suggested /store as a user /tmp replacement is a non-FHS directory as well. /tmp has always been about 10-20GB big, because I expect users to store big temporary images in /tmp. I won’t get this with tmpfs and I would have to train the users to change their behaviour. I believe this is part of our disagreement: I don't think system-wide directories are meant for users to use directly. In other words, I don't think users should put large downloads in /tmp; instead, they should put Now this thread is the first time someone mentions that /tmp should not be used by users but is only for system services. I don’t know of any documentation to support this claim. On the contrary all documentation about Unix/Linux I know say that /tmp is for all temporary files. But let’s say, /tmp is only for system services. Temporary user files belong to $HOME/tmp (which would be a special case in Debian only). So besides from teaching all users to not use /tmp, we need a cleaning job for $HOME/tmp and have to patch all software (browser, libreoffice, libpam-tmp, etc) to use the new tmp. But then most of your examples for tmpfs will be void because no user will use it. Your video encoder is a user application, so the temporary statistic file will go to $HOME/tmp, not to /tmp. And if you say that noone will use a combination of /tmp and /ramtmp, why do you think that someone will suddenly use a combination of /tmp (tmpfs) and $HOME/tmp? So I still think that my /ramtmp additional to /tmp are for now the best of both worlds without the risk of breaking applications and user expectations. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
SSDs and discard (was: Summary: Moving /tmp to tmpfs makes it useless)
On Sat, Jun 23, 2012 at 06:00:15PM +0300, Touko Korpela wrote: Tollef Fog Heen wrote: You need to enable it in all layers (fstab, crypttab, lvm.conf), yes. For now you shouldn't use discard option with SSDs, it's bad for performance. Better is to run fstrim periodically. Does this mean you shouldn’t use discard in fstab, but you need the option in crypttab and lvm.conf (or TRIM requests are filtered)? Or don’t you need any discard options in any layer to get fstrim to work? Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Summary: Moving /tmp to tmpfs makes it useless
disk is 250GB, my biggest 2TB, still all my systems have only 4GB RAM. At my company there are some systems with 8GB RAM, some even with 16GB (eclipse user), but the disks are at least 500GB. /tmp has always been about 10-20GB big, because I expect users to store big temporary images in /tmp. I won’t get this with tmpfs and I would have to train the users to change their behaviour. And it can happen with /var as well. I’ve seen programs logging so fast that /var had no space left breaking the logging and the database. Absolutely, I'm not contesting that (in fact, I've recently had a very similar situation at a customer). But this discussion is not about /var, it's about /tmp. Yes, it is, but if tmpfs is seen as an advantage because /tmp can’t block the system anymore and prevent DOS attacks (among others), this doesn’t sound so good anymore if you can as easily block the system by filling /var/tmp or /var/log. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Summary: Moving /tmp to tmpfs makes it useless
On Thu, Jun 21, 2012 at 10:20:03PM +0200, David Weinehall wrote: because I think it'd be impossible to convince some people that /tmp isn't a random dumping ground for anything and everything. But what is /tmp for you? Since my first Unix experience in the 90s, /tmp was always the local disk for temporary things. Yes, it is limited by the disk size. At university your $HOME was a NFS share (and I don’t know what you have against NFS for a shared filesystem; do yo prefer CIFS?), /tmp was always local like swap. If /tmp isn’t a „dumping ground für anything and everything” as long as there is enough space, what directory is more fitting? /tmp is cleaned at every reboot (configurable by TMPTIME), so a user doesn’t have to worry about it. Do you want something similiar for your /home/user/tmp? Should we now have different definitions of „temporary file”? Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Summary: Moving /tmp to tmpfs makes it useless
On Mon, Jun 18, 2012 at 11:42:06PM +0200, Wouter Verhelst wrote: If you write to /tmp on disk and someone or something calls sync at precisely the wrong moment, you're stuck, and your performance suffers. Not so with tmpfs. Maybe, but we are talking about defaults. Please correct me, but I think that most Debian systems are in some way single user systems. I'm not saying the speedup will be extreme, but it will be there, and (cumulated over loads of programs using /tmp) it will be significant enough to be noticeable. If you train the user to keep away from /tmp, because it may be too small with tmpfs, how much programs will use it then? - Any data transformation or filtering which needs to be done in multiple passes over a file would use a temporary file for intermediate results, which it then reads in again for the next pass. Multi-pass video transcoding is an example of this, and which (depending on the codecs used and the hardware on which it runs) could certainly be I/O bound. I agree, but only if your tmpfs is big enough to hold the file. Ripping DVDs or BDs will exceed any tmpfs limit on most systems. The point is that neither you nor I can reasonably be expected to list all possible uses of /tmp; and that RAM is faster than disk, so that when you access a tmpfs you're going to be somewhat faster than when you access a disk-backed filesystem, at least until you start swapping (if not longer). Nobody disagrees that RAM is faster than disk, but I hope you don’t disagree as well that most people will have more disk space than RAM. Now whether that advantage outweighs the disadvantages you've outlined is something we can talk about. However, whether RAM is faster than disk Fine let’s talk. Why can’t we find a compromise? Additional to our disk /tmp we create a /ramtmp (so the name suggests that this tmp is a ramdisk) with tmpfs. This should be doable in time for Wheezy. The release notes should mention it. And those who wish can patch their programs to use the ramdisk if they think their program uses only small temporary files. In this way, we get some data and experience. And we have both worlds. /tmp on disk for even large temporary files and /ramtmp as fast ramdisk. No, that's not true. The real danger in filling up /tmp is not that other processes can't write temporary files anymore (causing a minority of processes to hang or die; those who just happen to need temporary storage at that point in time), but that no process can write any file anymore (causing a significant majority of processes to hang or die). But this will only happen if your /tmp is not a separate partition. And it can happen with /var as well. I’ve seen programs logging so fast that /var had no space left breaking the logging and the database. We can now start another discussion what should be the best partition layout for a default installation, but /tmp is not the only problem. And /var/tmp exists as well for everyone writeable. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Fri, Jun 15, 2012 at 06:37:18AM +0200, Jean-Christophe Dubacq wrote: Learning not to use /tmp to place large files. Setting TMPDIR=/home/tmp /tmp is for temporary files, and I expect to place files there as large as the partition is. I am not interested in analysing the files in what temporary directory they belong today. Besides if you set TMPDIR to /home/tmp, you don’t need /tmp at all, no matter if tmpfs or not. If you want a system tmp create one and set TMPDIR for these system services. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Tue, Jun 12, 2012 at 01:15:51PM +0200, Bjørn Mork wrote: Aneurin Price aneurin.pr...@gmail.com writes: In anything resembling a 'normal' system (ie. the kind where one might be using the defaults) I would say that the tmpfs correlation is so strong as to be very nearly 1:1, and this seems like the crux of the matter; that is after all the reason that these applications are failing when /tmp is switched to tmpfs. I agree that's likely for any system using a default disk layout, so my comment was irrelevant for this discussion. I agree as well. This is the main reason why I didn’t like tmpfs to be the default. In most desktop cases you won’t have disk space problems. Even with multiple partitions you can easily spare 20 - 30 GB for a separate tmp partition. I still think that the easy tmpfs resizing (no meta data update, no LVM requirements, can use available space on other file systems) makes it superior for /tmp. But most users won't know that they can do this, so we might need a daemon monitoring /tmp and doing ondemand resizing. While you can resize tmpfs easily, you will never get sizes you would get with disks. And you must backup tmpfs with RAM and swap, so you can’t simply say, I resize my tmpfs to 20 GB if you only have 4 GB RAM and 8 GB swap (but a 2 TB disk). Since you can’t change the partition layout on the fly to grow the swap partition, your daemon would have to create swap files and activate them according to the tmpfs needs. But there will you place these files? You must make sure that the daemon deletes them if they are not needed anymore. After a system crash they must be deleted, or your system will have less and less disk space because orphaned swap files are filling the disk. Will this be worth the trouble? I don’t think so. If you see an advantage having /tmp on tmpfs, you can manually do so. Then you know what you have done. I don’t care if we get a new /tmpfs together with /tmp, so the user has both choices to set TMDPIR according to his needs. We may even patch some applications creating small shortlived temporary files to use /tmpfs instead in Debian. But by default we should not give up disk based /tmp for a default installation. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Sun, Jun 10, 2012 at 12:20:32PM +0200, Wouter Verhelst wrote: When /tmp is in a tmpfs, it's easy to connect the dots if it's empty on the next boot, and even easy to understand that restoring there (and then rebooting) isn't going to be very helpful. I don’t think the standard user will realize the difference between disk /tmp cleaned at reboot and a RAM disk. Also, the symlink attack thing isn't just something I made up; tmpreaper's REAME.Debian actually warns about that. True, but tmpreaper is not needed for systems with frequent reboots. /tmp on disk is cleaned according to the setting of TMPTIME. You need tmpreaper to clean /tmp on systems which rarely reboot. And then you have the same problem with tmpfs. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 12:35:47PM +0200, Adam Borowski wrote: * Less wear of SSD drives. • Contrary to Serge's claims, SSDs are not an oddity, and it's not unlikely these will be a majority before wheezy becomes oldstable. He didn’t say they were oddities. He said you should more worry about firmware bugs than worry about write cycles. And I think he is quite right. Will Wheezy support SSDs out of the box with all trimming functions, even if your SSD partition is using LUKS and LVM? If not, you think that getting /tmp away from disk will help much? Even if you consider rsyslog and logfiles, browser caches and so on? You have some interesting ideas, but I think they are only valuable for the common case if we can buy computers with better RAM to disk ratio. I checked some offers for new PCs (here in Germany). If you don’t buy an expensive gaming PC (with 16 or 12 GB RAM), you will get 4 GB (sometimes 6 or 8 GB). It’s even worse with notebooks. And let me guess: if you ask people if they want to buy a PC with 4 GB RAM and 2 TB disk or a PC with 8 GB RAM and 1 TB disk, they will choose the first one, because they know more about disk space than RAM. This basically boils down to: efficiency vs failures for a newbie user. Replace newbie user with default installation. Even experienced users may wish to choose default installation for common desktop systems. We have popularity-contest to get statistics about packages. Can this script be extended to get hardware information (e.g. RAM, disk space and partition layout)? So we would see what computer are used by our users and how it is configured. If most people only have 4 GB RAM, it is quite useless to waste it with a RAM disk. If most people already have separate tmp partitions, we don’t need it either. Current size defaults for /tmp are naive to the point of brokenness: with modern systems not being expected to ever use swap, we'd want to Well, if I start Virtual Box on my notebook (4 GB RAM), the system uses the swap partition. So it is not modern enough? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote: ]] Stephan Seitz Will Wheezy support SSDs out of the box with all trimming functions, even if your SSD partition is using LUKS and LVM? Depends on what you mean by out of the box. I suspect you still need to turn on discard support (since it has security implications). It does not require extra packages or patches. Well, nice to hear, but I thought, discard was needed in all layers, so in my example in LUKS, then in LVM and then in the filesystem. Or is his only a function you activate via hdparm? Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Is it me or virtualbox memory management crap?
On Mon, Jun 11, 2012 at 02:28:59AM +0800, Thomas Goirand wrote: On 06/10/2012 11:55 PM, Stephan Seitz wrote: Well, if I start Virtual Box on my notebook (4 GB RAM), the system uses the swap partition. Frankly, I don't know what the fuck virtualbox is doing with its memory management, but I was tempted more than once to file a RC bug with a title like this one: Virtualbox fucks up Linux memory on nearly all cases I didn't do it, because I'm unsure if what I'm experiencing is to be considered normal or not, or if there are tricks to avoid that. I don’t know if this is normal. At least I can say, that I can use Virtual Box and Iceweasel together. The system gets slow, but it still is usable. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 10:31:21PM +0200, Tollef Fog Heen wrote: Well, nice to hear, but I thought, discard was needed in all layers, so in my example in LUKS, then in LVM and then in the filesystem. Or is his only a function you activate via hdparm? It's available in all layers, but as Tollef said it's manual. (In crypttab most likely, because that's commonly the lowest layer.) You need to enable it in all layers (fstab, crypttab, lvm.conf), yes. Ah, thank you for your explanations. But the documentation doesn’t sound encouraging. „man crypttab” gives a security warning and „man mount” says, this option is not sufficiently tested yet. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Fri, Jun 08, 2012 at 01:04:50PM +0200, Bjørn Mork wrote: - a tmpfs is always easy to grow without requiring any special preparations. Just add more swap. The swap could be on different disks, and could even be files hosted on other file systems. Yes, of course, now I’m not only wasting RAM for tmpfs but disk space for swap files? Any file system will run out of space given the broken applications mentioned in this thread. tmpfs is the only one which will allow all tmpfs will run out of space much ealier than your 2TB disk. systems to dynamically add more space, only limited by the available disks. That's why tmpfs should be the default for both new and old ROTFL, yes, of course. I can get my tmpfs bigger than my disk to back it up. Sorry, this is ridiculous. If I have enough disks available I can grow my tmp partition (or my root partition with tmp) with LVM without problems as well. Both things are nothing a standard desktop user can do by its own, but the standard desktop user will certainly have more disk space than RAM, so I’m glad this tmpfs for tmp crap is off by default. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Thu, Jun 07, 2012 at 03:24:08PM +0200, Wouter Verhelst wrote: On Fri, Jun 01, 2012 at 07:00:52PM +0300, Serge wrote: Well, nobody named the benefits yet. - You could mount your mail spool there, and make things go blazingly fast [1] If I remember Wietse’s opinion correctly he will jump on your throat if you put the postfix mail spool on tmpfs. Maybe it could be used for amavis tmp directory, if you have enough RAM or small enough mails. - It speeds things up, especially on systems with loads of RAM and no swapspace: whenever there's a possibility of disk access, no matter It may do so, but how many Debian user have so much RAM and/or so less disk space, that it can be used as default (yes, luckily it was changed)? - anything which reduces the number of possible disk accesses is good for people using SSDs (I have a laptop with SSD, and no swap, and love tmpfs for precisely that reason). So, you have /var/log on tmpfs as well (or a remote log server)? Don’t you think that you are doing more writes to /var or $HOME than to tmp? Besides SSDs aren’t so wide spread (and in my eyes too unsecure yet) that you should optimize for them as default. - In the (on laptops and desktops) fairly common one-partition-for-everything set-up, there's no risk of a runaway process eating up your diskspace with huge files in /tmp and therefore But runaway processes may fill your disk with log entries. I have seen a catalina.out with the size of several gigabytes. - It makes for an interesting I need to compile something quickly just to test something out area, where it doesn't matter if you forget to clean up after the fact (yes, this is a bit of an abuse of /tmp; never the less, I find myself doing such things in /tmp fairly often now that /tmp is a tmpfs) Probably true. The only thing I compile myself is the Linux kernel, and I want to keep it. But again, nothing that is worth as default installation. - There's no danger of a symlink attack or similar with things like tmpreaper -- or indeed any need for tmpreaper anymore. You reboot the system, and /tmp is clean again, no matter what was there before. This is more than just a convenience. The existance of TMPTIME shows that there are more than enough people who don’t want to loose the contents of their /tmp with every reboot. Besides tmpreaper exists so you clean your /tmp without the need to reboot. There are certainly advantages of tmpfs, but I don’t see it in /tmp for most systems. But the installer may give you the choise (or create as standard) to have a /tmpfs with tmpfs, so every user who wants to use it, can set their own TMPDIR. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Wed, Jun 06, 2012 at 11:09:31AM +0200, Goswin von Brederlow wrote: Stephan Seitz stse+deb...@fsing.rootsland.net writes: Don’t you think this is getting quite ridiculous? Big temporary files belong in your $HOME, but small temporary files in /tmp? Only to switch /tmp from disk to RAM? No, I just don't consider a 4.7GiB download a temporary thing. I still have the mindset that that should take time, cost money and therefore be precious and should not be lost on reboot. Well, everything you do with your computer will cost money. The download will take its time, yes, but you don’t have to wait for it to be finished. But for me your example still describes a temporary file *if* I want to delete the file after I burned the ISO. But does the default have to be maximised for the dumbest possible user? Or should the default rather be for the intelligent user doing the right things? But the intelligent user can change the default hisself, the dumbest can’t. And Debian does allow the inexperienced user to install his system. According to the discussion the installer will create one partition for swap and one for /. If this is true then the standard user has far more space on disk than he has RAM. Just wait one more release and it will only be one partition with swap files. And lets give that partition a drive letter like C:\. :) I realy don't like the direction DI is taking there. ROTFL, yes maybe. I agree that I don’t like one big partition as well, but how do you want to partition a disk by default? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Tue, Jun 05, 2012 at 10:33:13AM +0200, Goswin von Brederlow wrote: Personally I thing DVD ISO images (downloaded) belong in your $HOME Don’t you think this is getting quite ridiculous? Big temporary files belong in your $HOME, but small temporary files in /tmp? Only to switch /tmp from disk to RAM? somewhere. And locally generated should just pipe the image to the burner unless you want to upload the image somewhere, in which case Or you want to keep it safe, until you are sure the burned DVD is working. Of course, if I want to keep the ISO it will be stored in $HOME, but then it isn’t a *temporary* file anymore. And /tmp *is* for temporary files. $HOME again. Just imagine a power failure after you painstackingly uploaded 99.9% of the iso and then you have to start from scratch again because a reboot cleans /tmp. TMPTIME exists and can be set according to your needs and your safety concern. Just out of interest: Do you have /tmp on /? Because if you do already have a seperate /tmp partition then that obviously stays used. I always have separate partitions for /, /usr, /var, /tmp, /usr/local and /home (allright, with crappy software like udev and Co. which starts wanting files in /usr needlessy at the early boot stages, I will merge / and /usr in time). It isn’t a problem for me. But we are talking about defaults. You wish to tell new users that there two TB disk can’t really be used as they wish because Debian has a strange distinction between temporary files belonging in /tmp and temporary files don’t belonging in /tmp? According to the discussion the installer will create one partition for swap and one for /. If this is true then the standard user has far more space on disk than he has RAM. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Sat, Jun 02, 2012 at 12:48:03PM +0300, Serge wrote: Oh... I was not thinking about TMPTIME. Does it mean that there's no way we can mount /tmp to tmpfs because it breaks TMPTIME? Well, I think, as long as this setting exist, no. With „-1” you can even disable tmp cleaning. So if the admin wishes to change the setting to keep files in /tmp even after reboot, you can’t use tmpfs, even if you don’t have enough space left. You can only print a warning message but not ignore the local configuration. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Sat, Jun 02, 2012 at 02:56:03PM +0200, Philipp Kern wrote: If you assume an unexpected reboot, then all that data will be lost, Well, I can count my unexpected reboots in the last years with one hand, so this is not a problem. And as already mentioned, you can configure with TMPTIME in /etc/default/rcS, which files in /tmp will be deleted. you to redownload these images. Couldn't /var/tmp serve this purpose better, if it's not exactly ephemeral data? (Like a temporary ISO created from on-disk content.) Since I’m not interested in filling my /var partition with tmp files (and so getting problems with databases or logs), /var/tmp is always a link to /tmp. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Fri, Jun 01, 2012 at 02:19:53PM +0200, Goswin von Brederlow wrote: In general your option assumes that you need the maximum amount of free space in /tmp. That is simply not true. In most cases a small /tmp is just peachy. Because of this it is hard to set a minimum size where tmpfs would be too small to be usefull. For some user that would be 100MB, for others it is 100GB. /tmp is for temporary files, so I expect my /tmp to hold all these files, in my case DVD ISO images (downloaded or localy generated) that I will burn and then delete. So my /tmp is at least 20GB. BluRay users may need more. If this is not the meaning of /tmp, then rename it. Diskspace is cheap and easier to spare than my RAM. So, yes, if someone has one 3TB partition which is writeable, then /tmp belongs to disk not to RAM. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Moving /tmp to tmpfs makes it useful
On Thu, May 31, 2012 at 12:46:49AM +0300, Uoti Urpala wrote: Also, nowadays normal filesystems are journaled; using a journal for writes to /tmp damages the SSD for zero benefit. Writing to /tmp will damage a SSD? Are you serious? And writing to /var or /home will not? If SSDs are so easy damageable, that you should never use them for e.g. development because it creates to much write cycles, then they have a serious problem. (Thinking about the firmware bugs with data loss I will stay away from them anyway.) I think no one is saying that tmpfs is always bad and never should be used. But for a default installation /tmp belongs to a disk which will be far bigger than the memory. If a user thinks tmpfs will get him an advantage in his setup, then he can switch. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Moving /tmp to tmpfs makes it useless
On Mon, May 28, 2012 at 01:21:43PM +0800, Thomas Goirand wrote: As you wrote, nothing is infinite. I don't think that /tmp is worse than /home like other said. Your /home could become full as well. Your /home could be a network share like NFS and /tmp a local partition, so you don’t want to use /home for temporary downloads or caches. Besides that, on multi-user systems /tmp can be used to share files (I’ve downloaded the current ISO image to /tmp, so you can copy it from there). This is much better than to open access to your $HOME directory. And I think, it is clear as well that your disk space will always be much bigger than your RAM size. It seems very strange to waste RAM for a ramdisk to free disk space. I don’t think that there is a sane default as well. A desktop system which runs several VMs will probably not like to waste RAM for tmpfs. But since we are talking about defaults, how does d-i partition your hard disk in the following cases? a) Notebook 4 GB RAM 250GB disk b) PC 4 GB RAM 2TB disk If it creates 4 or 8 GB swap and a single partition for the remaining disk, tmpfs will never beat disk space. If the admin decides to partition manually he will know what he does (or he should ;-). My PC is normally used remote and acts more like a server. It uses tmpfs, but its size is only 635M, so I already have problems creating a CD ISO. Since the system has 2 TB disk space, my next repartitioning will create a separate /tmp with about 10 or 20 GB, much easier to spare than RAM. So I don’t see the advantage of using tmpfs as default, but d-i should offer the option to put /tmp on tmpfs if the admin wishes it. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Moving /tmp to tmpfs is fine
On Mon, May 28, 2012 at 01:59:24AM +0100, Ben Hutchings wrote: I don't recall that being common practice on any multi-user Unix-like system I've used. (It's also not something a Windows user would expect, Well, it was back in my university days, and it still is where I work. Maybe „multi-user” is wrong, but telling other user that the ISO lies on my system in /tmp is much easier than to tell them a location in my $HOME and to make sure they can access ist. as they already get per-user temporary directories.) One of the first things I do after a Windows installation is to create c:\temp. ;-) Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
On Tue, May 15, 2012 at 05:26:32PM +0200, Josselin Mouette wrote: Le dimanche 13 mai 2012 à 20:00 +0200, Gergely Nagy a écrit : Not entirely true. You can override parts of the file too, without copying: include the original. This doesn't let you override everything, but for a lot of things, is good enough. And then, when the original file changes, you lose the improvements and you might even end up with a broken system. For example if a systemd unit file is updated to match a change of behavior in a daemon. Say, from now it requires a pre-exec stanza to do stuff it used to do at startup. Your modified file in /etc will not include this new stanza and your daemon is broken. Now I am confused. I thought this was the advantage of the include function of systemd. So, your etc-configuration file has as first line „:include lib-configuration file” and then your modifications. If a unit file is updated in /lib, you have the new stanza thanks to your include function. Of course this can still break the daemon, because your own changes couldn’t be valid anymore. The problem is that we seem to have three cases: - default configuration file is in /lib; if the daemon detects a file in /etc, it will read the file in /lib and then in /etc and merge the files together (which application does this?) - default configuration file is in /lib; if the daemon detects a file in /etc, it will only read the etc-file; thanks to the include support you can include the lib-file in the etc-file and only add the stanza you need (e.g. systemd) - default configuration file is in /lib; if the daemon detects a file in /etc, it will only read the etc-file; without include function you have to copy the complete lib-file to etc and edit it (e.g. udev) I don’t think we can force one of the cases as rule via policy, so the etc-directory should contain a README (e.g. in /etc/udev/rules.d) explaining how to change the default configuration. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: RFC: OpenRC as Init System for Debian
On Fri, May 11, 2012 at 10:52:25AM +0200, Gergely Nagy wrote: Neither the FHS, nor the policy says anything about etc-overrides-lib as far as I can see. Neither pro or con. Do feel free to point me to the relevant section, would I be mistaken. To be honest, I still don’t really understand what the files in lib are: - Are they configuration examples with all possible settings and their default values and the application works fine without these files? Then they should be in /usr/share/doc/package. - Or doesn’t the application start without these files? Then they are undoubtedly configuration files and according to FHS and Debian policy configuration files belong in /etc The stuff in /lib are package defaults. Where the default is, in the program, embedded, or in some file, doesn't really matter, it's an implementation detail. It does matter. In the end it is the same situation as the firmware problem. For the hardware it doesn’t matter if the firmware is placed in an EEPROM on the hardware or loaded from the FS by the driver. But for Debian and its policy it is a difference. So if you don’t want a default configuration from a file, because you don’t want to put a file in /etc, then you must compile the program with your default settings. worse - in some ways, even better - than some other existing practice (the conf.d/ stuff I mentioned a few times elsewhere in this thread already). I like conf.d. It makes things easier for e.g. rsyslog or sysctl. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: RFC: OpenRC as Init System for Debian
On Fri, May 11, 2012 at 11:25:10AM +0200, Gergely Nagy wrote: Are you happy with dropping a snippet into a conf.d/ directory, and your software breaking on an upgrade without notice? Because that can happen even now, with software that uses only /etc, and /etc alone for their configuration, without any kind of default anywhere else. Yes, because I know that something is wrong when it breaks. This is better than the software is working but not anymore as you expect. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
