Gentoo Forums :: View topic - The Politics of systemd Part 2

The Politics of systemd Part 2

View unanswered posts
View posts from last 24 hours

Goto page Previous 1, 2, 3 ... 24, 25, 26, 27, 28, 29 Next

This topic is locked: you cannot edit posts or make replies.

Gentoo Forums Forum Index

Gentoo Chat

View previous topic :: View next topic

Author

Message

khayyam
Watchman

Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

Posted: Tue Mar 07, 2017 8:47 am Post subject:

Hu ...

The 1.4 series is still in tree, it doesn't use pinentry (and so break the tty), and can be used without an agent starting. It also gets updated (the last being sept 2016).

/etc/portage/package.mask:

>=app-crypt/gnupg-2.0.22

best ... khay

CasperVector
Apprentice

Joined: 03 Apr 2012
Posts: 156

Posted: Tue Mar 07, 2017 12:00 pm Post subject:

mv wrote:

What is simpler:

/etc/local.d/my-gpg:

#!/bin/sh
install -d -o me -g mygroup -m 0700 /run/user/me

/etc/tmpfiles.d/my-gpg.conf:

d /run/user/me 0700 me mygroup - -

mv wrote:

And what is wrong with /etc/tmpfiles.d? Does it cause heavy dependencies and give possible security problems? Are there any reasons to reject it? There is only one reason to reject it: NIH

williamh does not really give me enough confidence in the security of opentmpfiles. From the viewpoint of code generation, the functionalities of opentmpfiles is equivalent to that of running (at a suitable location in the booting dependency graph)

Code:

#!/bin/sh
install -d -o me -g mygroup -m 0700 /run/user/me
install ... # with arguments transformed from another tmpfiles.d entry
...

Code generation is worthwhile when the output would be so much longer or more complex than the input that the difference in maintenance cost compensates the cost of a code generator. Considering the size of opentmpfiles codebase, you would need hundreds of /etc/tmpfiles.d entries to compensate for the growth in the total amount of code, so I do consider the former to be simpler for most users.

mv wrote:

What have you gained if you do the former instead of the latter?

With each init script creating the directories it needs, directories for disabled services would be naturally skipped during booting. And you can write shell "templates" that create directories according to the service name, like in the following script for a machine running s6

/etc/s6-rc/base/someservice.log/run:

#!/bin/rc -e
exec >[2=1] # equivalent to `exec 2>&1' in Bourne shell
. /etc/s6-rc/bin/fn.rc # where `$logd' is automatically generated from the service name (eg. `someservice.log' -> `/var/log/someservice')
. ./data/env.rc # where you set `logu=someuser'
logd_mk $logd $logu # small wrapper around install(1), defined in above-mentioned fn.rc
exec \
s6-setuidgid $logu \ # sets uid and gid to those of $logu
emptyenv -p \ # empties the environment, only keeping $PATH
s6-log n6 s5000000 !gzip t T $logd

Neither above can be easily done with a centralised directory maker like opentmpfiles.

mv wrote:

If you also start gpg earlier, the former might give you also dependency issues, because local.d is usually started last. If you are a package author you must make sure to have no order issues. So here the alternatives are: Provide init files for all init-systems (no matter whether the stuff is actually started) or rely that the distribution packager or local system admin really carefully reads the documentation and does it, or provide the one single file? Which increases the chance that the user will have a good experience with your package?

I mentioned /etc/local.d because I thought gpg would be started late for the original use case. If gpg needs to be started earlier, it would definitely be the result of an unusual init script, and the author of that init script (probably the sysadmin himself) would naturally be responsible to ensure the dependence. And the dependence is easily ensured by putting the install(1) invocation into the same init script as gpg; iow, enforcement of dependence is not necessarily correlated to using opentmpfiles or not.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Last edited by CasperVector on Tue Mar 07, 2017 5:40 pm; edited 3 times in total

khayyam
Watchman

Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

Posted: Tue Mar 07, 2017 1:43 pm Post subject:

mv wrote:

What is simpler:

/etc/local.d/my-gpg:

#!/bin/sh
install -d -o me -g mygroup -m 0700 /run/user/me

/etc/tmpfiles.d/my-gpg.conf:

d /run/user/me 0700 me mygroup - -

mv ... neither ... if you also need a 'which-users-should-be-provided-gpg' service to generate each my-gpg{,.conf} (and other such configuration) for all existing users (nah, that's a job for logind obviously). That's not complicated at all, but at least we're FHS compliant, and early boot (udev, systemd, mdadm, mount) has someplace on the filesystem to write. In short, simplicity was thrown out the window once /run came into being (and /var/run became tmpfs), and regardless of the additional complexity people are still going to argue that this is an improvement over /tmp or /var/run and start thinking of what else (ie, /var/cache) should be brought under this new 'standard', how about eix, because creating /var/cache/eix at install time is too complex and/or unreliable (it may just go missing, or not be backed up). So, "what is simpler", a tmpfs filesystem called /run used for early boot (and perhaps even system services if suitable), or requiring everything migrate to a tmpfs {/var,}/run (and additionally declare other parts of the filesystem 'volatile') and so require tempfiles.d (because they expect a directory structure in place)?

mv wrote:

And what is wrong with /etc/tmpfiles.d? Does it cause heavy dependencies and give possible security problems? Are there any reasons to reject it? There is only one reason to reject it: NIH

Nonsense ... the objection, or at least some attempt at getting at the reasons we came to have tempfiles.d at all, was laid out in my first post on the subject.

best ... don Quixote the windmill tilter

mv
Watchman

Joined: 20 Apr 2005
Posts: 6747

Posted: Tue Mar 07, 2017 6:38 pm Post subject:

khayyam wrote:

for all existing users

The grandmaster of goal shifting has spoken.
Congratulatins: It is possible to formulate problems which are not solved by tmpfiles.d

I have to go now, a strong wind is coming up again :wink:

khayyam
Watchman

Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

Posted: Tue Mar 07, 2017 9:53 pm Post subject:

mv wrote:

khayyam wrote:

for all existing users

The grandmaster of goal shifting has spoken. Congratulatins: It is possible to formulate problems which are not solved by tmpfiles.d

mv ... something which I can take with a grain of salt given your selective attention (ie, the goal shifting I'd pointed out above), selective quotation (replete throughout this discussion, and others), failure to deal with the substance of the argument, ad hominem, etc, etc. The point in the above (which you selectively quoted) is not to "formulate problems which are not solved by tmpfiles.d" but to show that the solution is worse than the problem it claims to address ... something which you've completely avoided discussing, because having lost the "[...] clumsy code to create directories [...] a permanent security risk" argument you've little to fall back on, other than the to narrow the subject down to suit your ad hominem.

mv wrote:

I have to go now, a strong wind is coming up again :wink:

Oh, how droll ... did you have a brain fart?

donQ

mv
Watchman

Joined: 20 Apr 2005
Posts: 6747

Posted: Wed Mar 08, 2017 9:02 am Post subject:

Now I am fed up with your permanent ad hominem attacks.

Quote:

goal shifting [...] selective quotation [...] failure to deal with the substance of the argument

Let me recall what we are discussing about:
A relatively new standard way providing that a package author or a distribution or a sysadmin can rely at the start of any tool on the existence of certain dirs/files/devices with certain permissions... making possibly sure that directories are empty, have correct quotas etc. on all distributions adopting that standard.

What I did, was pointing out the advantages:

Simpler upstream packaging.
No caring is required of whether these lie on a persistent medium or not.
Increased security by relying only on one tool doing this job instead of dozens doing the same job, partially with increased complexity
(This was not discussed yet): As a bonus, people with long-running system can also use this standard in a cron-job to clen up ancient files in e.g. /tmp, possibly making previous such scripts superfluous

What happened here: In some posting you had diminished the advantages to one single.
Your reaction is a sequence of ad hominem attacks:

You claim that it is goal-shifting (selective quotation, failure to deal with the substance) to not restrict myself to your selected diminished advantage.
You claim that I artificially try to make the standard appear better than it is.
You accuse me for being ad hominem

Of course, this is all a dirty rhethorical trick: To accuse me of the things which actually you are doing.

Quote:

show that the solution is worse than the problem

And so far you completely failed to do so:

What actually are the disadvantages of having/using this standard?

It is the second time that I explcitily raise this question, and still so far nobody mentioned any disadvantages.
There was one ad-hominem argument (not by you) which essentially comes down to "I do not trust the one who implemented it" (I will not discuss this questionable argument in an open-source world now).

All technical arguments mentioned so far come down to various attempts to make the advantages appear less advantegous:

For certain applications it is not much harder to artificially avoid using the standard.
The standard is not a one-size-fits-all for all problems related with file creation

Both are attacking strawmen which nobody had claimed.
Of course you use my ignoring of these strawmen for further ad hominem attacks:

Quote:

goal shifting [...] selective quotation [...] failure to deal with the substance of the argument

As mentioned several times, I am not interested in your personal war against this or that developer.
If there is really a technical issue with the standard, then mention it!
Otherwise, for me the discussion is over here.

CasperVector
Apprentice

Joined: 03 Apr 2012
Posts: 156

Posted: Wed Mar 08, 2017 11:08 am Post subject:

mv wrote:

What I did, was pointing out the advantages:

Simpler upstream packaging.
No caring is required of whether these lie on a persistent medium or not.
Increased security by relying only on one tool doing this job instead of dozens doing the same job, partially with increased complexity
(This was not discussed yet): As a bonus, people with long-running system can also use this standard in a cron-job to clean up ancient files in e.g. /tmp, possibly making previous such scripts superfluous

Upstream simply needed to either (1) add file-creation 2-liners into the init scripts he maintains, or (2) specify (eg. in the README) what files are needed if he does not maintain the init scripts himself.
2-liners using `install', `mkdir -p' etc. do not care, either.
Increased complexity and reduced security by violating the Unix philosophy.
Unimplemented in opentmpfiles, and can be implemented better as an independent script (probably less than 50 lines) constructing and executing `find ... -delete ...' command lines from a config file.

mv wrote:

What actually are the disadvantages of having/using this standard? It is the second time that I explcitily raise this question, and still so far nobody mentioned any disadvantages. All technical arguments mentioned so far come down to various attempts to make the advantages appear less advantegous:

For certain applications it is not much harder to artificially avoid using the standard.
The standard is not a one-size-fits-all for all problems related with file creation

For the first point, adding nearly 500 lines of shell script to replace several file-creation 2-liners with `tmpfiles.d' 1-liners is an obvious disadvantage; for the second point, since you asked

mv wrote:

What have you gained if you do the former instead of the latter?

I should of course answer what `tmpfiles.d' cannot do, and you are now

mv wrote:

attacking strawmen which nobody had claimed.

mv wrote:

To accuse me of the things which actually you are doing.

mv wrote:

There was one ad-hominem argument (not by you) which essentially comes down to "I do not trust the one who implemented it" (I will not discuss this questionable argument in an open-source world now).

I do not disagree if you would like to label it as ad hominem, because I believe that particular argument to be non-fallacious anyway :wink:

https://en.wikipedia.org/wiki/Ad_hominem wrote:

However, in some cases, ad hominem attacks can be non-fallacious; i.e., if the attack on the character of the person is directly tackling the argument itself. For example, if the truth of the argument relies on the truthfulness of the person making the argument—rather than known facts—then pointing out that the person has previously lied is not a fallacious argument.

Therefore, questioning the security of `tmpfiles.d' implementations by questioning the professional track record of their authors is, even if considered ad hominem, non-fallacious.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Last edited by CasperVector on Wed Mar 08, 2017 12:00 pm; edited 9 times in total

khayyam
Watchman

Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

Posted: Wed Mar 08, 2017 11:14 am Post subject:

mv wrote:

Now I am fed up with your permanent ad hominem attacks.

mv ... no, an ad hominem is a "logical fallacy in which an argument is rebutted by attacking the character, motive, or other attribute of the person making the argument", ie, "the grandmaster of goal shifting has spoken". Stating, or arguing, that someone is "goal shifting", "quoting selectively", or "failing to deal with the substance of the argument" do not qualify, as these are addressing the argument not the person, character, or motive (more on the later point bellow).

mv wrote:

khayyam wrote:

goal shifting [...] selective quotation [...] failure to deal with the substance of the argument

The fact that you choose to ignore that tempfiles.d is the result of /var/run becoming tmpfs, and that this came about as the result of 'early boot' needing someplace (other than /dev) to wtite, does not mean you get to define the subject, and scope, of the discussion. As for narrowing the subject down to your "recall[ection]", certain claimed benefits (ie, avoiding "[...] clumsy code to create directories [...] a permanent security risk") have been shown to be trivial, if not easily dealt with by pre-existing methods (ie, the creation a directory at install time), so when I see you recapitulating the discussion, keeping it within the above bounds, and throwing in distractions in the form of accusations of ad hominem, "holy war", etc, etc, I'm inclined to see this as a sign that you really don't care about the argument per se, you just want to come out seeming to have won.

Also, the "goal shifting" above came about as you accused me of doing this, so pointing to the irony of you having done it when you shifted from "a lot of these things was just done by writing more clumsy openrc scripts", to "classical init-files (not of openrc) contained bulks of identical code" is to point to a fact, rather than to insinuate that you had done so.

mv wrote:

What happened here: In some posting you had diminished the advantages to one single. Your reaction is a sequence of ad hominem attacks:

Nonsense ...

mv wrote:

You claim that it is goal-shifting (selective quotation, failure to deal with the substance) to not restrict myself to your selected diminished advantage.

No, firstly that wouldn't be an ad hominem, secondly the argument wasn't compounded in that form. You had shifted the goal posts (see above with regard to "clumsy openrc scripts") and I brought this up because you accused me of being a "grandmaster" (in an ad hominem), you had consistently engaged in selective quotation (examples abound, ie, your having now compounded the "goal shifting", "selective quotation" into one neat "claim", rather than the specificity of them in the form that they were stated). Such things were used as a means to avoid the substance of the argument (an example of which is your "recall[ing]" what the discussion is about rather than discuss why this came about, and so why they happen to be 'volatile').

mv wrote:

You claim that I artificially try to make the standard appear better than it is.

I'm not going to go back and re-read the entire discussion and try and figure out were you got this from but I don't think I did, please provide references otherwise that is unsubstantiated.

mv wrote:

You accuse me for being ad hominem

No, I accused you of using an ad hominem, which you did in the form of "the grandmaster of goal shifting has spoken", Similarly in accusing me of being on a "holy war", and by comparing me to don Quixote ("fight against windmills") something which is used to denote someone who is deluded.

mv wrote:

Of course, this is all a dirty rhethorical trick: To accuse me of the things which actually you are doing.

Oh, the sheer irony!!! How can I take you, or your arguments, seriously??? ... I'm completely wasting my time.

best ... khay

mv
Watchman

Joined: 20 Apr 2005
Posts: 6747

Posted: Wed Mar 08, 2017 6:41 pm Post subject:

OT:

khayyam wrote:

comparing me to don Quixote ("fight against windmills") something which is used to denote someone who is deluded.

This was not meant to be an attack, but a humorous parallel. Perhaps there is a cultural misunderstanding. I had meant it in the sense of the full novel which is well-known here (not only the windmill episode). In the novel, Don Quixote is a tragic figure: Despite some clear situation comedy, I think D.Q. is not meant to appear as deluded but instead as misguided by some questionable trends of his time which the novel intends to criticize.

khayyam
Watchman

Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

Posted: Wed Mar 08, 2017 7:50 pm Post subject:

mv wrote:

khayyam wrote:

comparing me to don Quixote ("fight against windmills") something which is used to denote someone who is deluded.

mv ... there is no cultural misunderstanding, I too know the book well. When the idiom is used it denotes a certain form of delusion, in that for Don Quixote these windmills are giants, and so the person said to be "tilting at windmills" can't deferenciate between one thing and another, and so is suffering under a delusion (often for vain, romantic, or idealistic, reasons). This statement operates as an ad hominum for obvious reasons.

That settled, please note you've only responded to one comment from the above ... and so are exhibiting selective quotation. The wider point about who is using ad hominum arguments against whom, still stands, unless you think that your "cultural misunderstanding" similarly covers "grandmasters of goal shifting", and "holy wars".

best ... khay

krinn
Watchman

Joined: 02 May 2003
Posts: 7470

Posted: Wed Mar 08, 2017 10:22 pm Post subject:

i'm still trying to figure out what is the value of that tmpfiles, except put lot of shit in anyone system. - if you use tmpfiles to handle something in /var/run, it's volatile, and get lost on reboot, and if you don't reboot, datas should be kept and never remove except by your program (that tmpfiles can remove them base on date or whatever) - if you use tmpfiles to handle something in /tmp, it's persistant, but on reboot it's upto the admin to decide if /tmp should be clear or not, not the decision taken by some software dev - if you use tmpfiles to handle something that is temp anywhere outside /tmp, you basically are putting temp files everywhere in the admin FS ; what i would call: shitting in anyone house, it's even worst, when your program start, you should take care if your temp files are used already by another instance of your program, or how your program handle starting without the tempfile but also with the tempfile already there... it's a design, that for sure endup with security issue or crash. And finally to handle that properly, you would endup getting help of mktemp (or reinvent the wheel) ; anyway if it's to endup using mktemp, just keep using mktemp but in /tmp and stop dropping useless files in a FS that is not yours. what is the advantage of tmpfiles so? as right now, i only see it as crap

AJM
Apprentice

Joined: 25 Sep 2002
Posts: 189
Location: Aberdeen, Scotland

Posted: Fri Mar 10, 2017 12:42 am Post subject:

miket wrote:

Lumina has some promise, I think. I'd like to find a nice display manager, though--one that plays nicely with X logins and does not deal in kits or seats.

Out of interest, what's wrong with XDM? I switched to it from GDM a few years ago (I used GDM for a long time even though I've never been able to tolerate any version of Gnome on my desktop) as it was getting even more bloated and/or broken with every new version in the inimitable Gnome style.

I know XDM is almost unbelievably ugly by default, but it's actually possible to make it look beautiful and also to provide buttons for shutting down etc which some people require. Best of all it's free from the tangled web of pointless *kits etc, consumes virtually nothing by way of resources and does all I ever required a display manager to do.

Tony0945
Watchman

Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

Posted: Fri Mar 10, 2017 1:58 am Post subject:

AJM wrote:

know XDM is almost unbelievably ugly by default, but it's actually possible to make it look beautiful and also to provide buttons for shutting down etc which some people require. Best of all it's free from the tangled web of pointless *kits etc, consumes virtually nothing by way of resources and does all I ever required a display manager to do.

Absolutely! I followed this 1999 guide which is still valid: http://www.linuxjournal.com/article/3325 I also added a "default desktop" that just presents a menu and lets you choose which real desktop to choose. I'll post the code if anyone is interested. It's only a few lines of shell script (cribbed from that button code you refer to), but that particular machine is shut down right now.

Zucca
Moderator

Joined: 14 Jun 2007
Posts: 3339
Location: Rasi, Finland

Posted: Fri Mar 10, 2017 12:55 pm Post subject:

krinn wrote:

i'm still trying to figure out what is the value of that tmpfiles

I use it as an easy way to delete old temporary files. For example I use it to delete old video files from my youtube-dl video directory. Yes, you can accoplish that same functionality by (for example) running "find /dir -type f -mtime +number -print0 | xargs -s -0 rm" as a cron job. But I think it's a little simplier way for me to add such rules.
I don't consider is as a bloat (especially the one that works with OpenRC), but upstream should not rely on it, instead distribution packagers should use it if available.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--

Quote:

I am NaN! I am a man!

Last edited by Zucca on Fri Mar 10, 2017 1:07 pm; edited 1 time in total

Goverp
Veteran
Veteran

Joined: 07 Mar 2007
Posts: 1995

Posted: Fri Mar 10, 2017 12:55 pm Post subject:

At risk of diverting the thread, a warning: I decided to create an encrypted system archive on a new 3TB external disk drive. The I/O to empty that much disk was going to take hours, partly 'cos my box is only USB2. So it got a cheap upgrade of a PCIe<->USB3 card. Now it only took 10 hours to fill the drive with noise. Whatever. Thanks to those helpful udev people, with Predictable Network Interface Names, adding that card caused my predictable name changed from net.enp2s0 to net.enp3s0. Hmm, I suppose that was predictable, but not helpful. I've reverted my system to net.eth0 with net.ifnames=0 on the kernel command line. So, warning: don't install new hardware, as the udev code to prevent new hardware changing device numbering changes device numbering. _________________ Greybeard

Zucca
Moderator

Joined: 14 Jun 2007
Posts: 3339
Location: Rasi, Finland

Posted: Fri Mar 10, 2017 1:11 pm Post subject:

Goverp wrote:

So, warning: don't install new hardware, as the udev code to prevent new hardware changing device numbering changes device numbering.

I've found myself doing udev rules many times for my NICs. I usually rename them (by HW or MAC address) to something I can remember easily like ethmb0 for the ethernet socket on the motherboard.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--

Quote:

I am NaN! I am a man!

Naib
Watchman

Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

Posted: Fri Mar 10, 2017 1:32 pm Post subject:

Zucca wrote:

krinn wrote:

i'm still trying to figure out what is the value of that tmpfiles

wtf... find can exec... -exec rm -rf {} \; and equally find has -delete

print0 & xargs are ... questionable
_________________

Quote:

Removed by Chiitoo

khayyam
Watchman

Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

Posted: Fri Mar 10, 2017 1:40 pm Post subject:

Goverp wrote:

I decided to create an encrypted system archive on a new 3TB external disk drive. The I/O to empty that much disk was going to take hours, partly 'cos my box is only USB2. So it got a cheap upgrade of a PCIe<->USB3 card. Now it only took 10 hours to fill the drive with noise. Whatever.

Goverp ... you're doing it wrong ;) ...

Code:

# cryptsetup luksOpen --type plain /dev/sdb1 crypt-device --key-file /dev/random
# dd if=/dev/zero of=/dev/mapper/crypt-device
# cryptsetup luksClose crypt-device
# cryptsetup -c aes-xts-plain64 -y -s 512 luksFormat /dev/sdb1
# cryptsetup luksOpen /dev/sdb1 crypt-device

... that should be quicker than using /dev/random to fill the disk with noise as cryptsetup will do the same with zeros (or any data) using the kernel AES.

HTH & best ... khay

Zucca
Moderator

Joined: 14 Jun 2007
Posts: 3339
Location: Rasi, Finland

Posted: Fri Mar 10, 2017 1:58 pm Post subject:

Naib wrote:

print0 & xargs are ... questionable

With -print0 and xargs -0 all the arguments are seperated by NULL character (as you may already know). I think it's more cleaner to pass the file list to xargs and then run as few as possible rm processes. With very large set of files it can take significantly longer to execute rm for each file. But you're right in a way in this case, since there propably isn't many files to delete since assuming the deletion of these files occur at least once a day or so.

khayyam wrote:

... that should be quicker than using /dev/random to fill the disk with noise as cryptsetup will do the same with zeros (or any data) using the kernel AES.

... then there's that shred -command. I don't know if it's any faster though... Just thought to mention it.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--

Quote:

I am NaN! I am a man!

khayyam
Watchman

Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

Posted: Fri Mar 10, 2017 2:38 pm Post subject:

Zucca wrote:

I use it as an easy way to delete old temporary files. For example I use it to delete old video files from my youtube-dl video directory. Yes, you can accoplish that same functionality by (for example) running "find /dir -type f -mtime +number -print0 | xargs -s -0 rm" as a cron job. But I think it's a little simplier way for me to add such rules. I don't consider is as a bloat (especially the one that works with OpenRC), but upstream should not rely on it, instead distribution packagers should use it if available.

Zucca ... there is absolutely no reason to use it in this case, the user has every means (including crontab, the shell, etc) to deal with such things.

~/.zlogin:

rm -f ~/path/**/*(^m0)

... and note zsh makes find unecessary, as it can qualify the glob (to match mtime).

If your argument is that its "easy/simpler" to have tempfiles.d do such cleanup, then it is only easier/simpler to the extent that "anything a user can do root can do better", and that is eating into the fundamental seperation we attempt to create between privilaged and non-privilaged tasks (hello Windows).

Zucca wrote:

khayyam wrote:

... that should be quicker than using /dev/random to fill the disk with noise as cryptsetup will do the same with zeros (or any data) using the kernel AES.

... then there's that shred -command. I don't know if it's any faster though... Just thought to mention it.

shred will require entropy from /dev/random, and so it's the same as dd, or other methods. With dmcrypt you can write /dev/zero and the kernel AES will make it random (and it should be faster because its done in kernel and not userland).

best ... khay

Naib
Watchman

Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

Posted: Fri Mar 10, 2017 2:50 pm Post subject:

Zucca wrote:

Naib wrote:

print0 & xargs are ... questionable

I am aware print0 and xargs -0 utilises NULL rather than line, it doesn't completely remove the issue. print0 equally isn't portable
-exec rm {} \; deletes the entire list and does not spawn a rm for every entry (-delete would and would slow down for a long list)
_________________

Quote:

Removed by Chiitoo

Zucca
Moderator

Joined: 14 Jun 2007
Posts: 3339
Location: Rasi, Finland

Posted: Fri Mar 10, 2017 2:58 pm Post subject:

khayyam wrote:

~/.zlogin:

rm -f ~/path/**/*(^m0)

... and note zsh makes find unecessary, as it can qualify the glob (to match mtime).

That's maybe the neatest way to do it. However, how does zsh handle if the shell expansion overflows the command line (max length)? I know it's a corner case...

khayyam wrote:

If your argument is that its "easy/simpler" to have tempfiles.d do such cleanup, then it is only easier/simpler to the extent that "anything a user can do root can do better", and that is eating into the fundamental seperation we attempt to create between privilaged and non-privilaged tasks (hello Windows).

True. tmpfiles does lack unpriviliged "mode". It's a major lack in features, indeed. I can only hope it gets fixed eventually. :\

Naib wrote:

-exec rm {} \; deletes the entire list and does not spawn a rm for every entry

Good point. I actually didn't thought that, although my example was limited to files only (-type f).
-exec rm -fr {} \; does work more realibly indeed.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--

Quote:

I am NaN! I am a man!

khayyam
Watchman

Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

Posted: Fri Mar 10, 2017 4:17 pm Post subject:

Zucca wrote:

khayyam wrote:

~/.zlogin:

rm -f ~/path/**/*(^m0)

... and note zsh makes find unecessary, as it can qualify the glob (to match mtime).

That's maybe the neatest way to do it. However, how does zsh handle if the shell expansion overflows the command line (max length)? I know it's a corner case...

Zucca ... good you asked, zsh has 'zargs', so:

~/.zshrc:

autoload -Uz zargs

~/.zlogin:

zargs ~/path/**/*(^m0) -- rm -f

Zucca wrote:

khayyam wrote:

True. tmpfiles does lack unpriviliged "mode". It's a major lack in features, indeed. I can only hope it gets fixed eventually. :\

Well, not only that but users can (in fact, we might say should) handle all such things within the existing framework (and there isn't some fundamental issue that prevents them doing so).

best ... khay

Goverp
Veteran
Veteran

Joined: 07 Mar 2007
Posts: 1995

Posted: Sat Mar 11, 2017 11:49 am Post subject:

khayyam wrote:

...
Goverp ... you're doing it wrong

...

Code:

# cryptsetup luksOpen --type plain /dev/sdb1 crypt-device --key-file /dev/random
# dd if=/dev/zero of=/dev/mapper/crypt-device
# cryptsetup luksClose crypt-device

...

Ta Khay, but that's exactly what I did, and it took 10 hours. I think the problem is the disk speed; dd started out at some insane I/O rate - until the drive cache filled. After that, it eventually settled down to 63.6 MB/sec (USB3), and I think about half that USB2.
_________________
Greybeard

khayyam
Watchman

Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

Posted: Sat Mar 11, 2017 12:33 pm Post subject:

Goverp wrote:

Goverp ... strange because I just did a 5200rpm 2.5" 80GB disk this way only the other day and my jaw droped when it took something in the region of 10-15 minutes. Previously (without something like sys-apps/haveged generaing entropy) this would have taken perhaps a few hours (if memory serves). Now I think about it, haveged was running, I wonder if this might have made the difference.

best ... khay

Display posts from previous:

	Gentoo Forums Forum Index Gentoo Chat	All times are GMT Goto page Previous 1, 2, 3 ... 24, 25, 26, 27, 28, 29 Next
Page 25 of 29

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Copyright 2001-2024 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy