Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/25/19 6:10 PM, Björn Persson wrote: It's perfectly possible for a number to be unique without being random. As an example, you could hash the machine ID, which is supposedly unique in space, and the system clock, which is unique in time. That makes the hash unique in both space and time. Produce invocation IDs by counting up from that value, or by hashing repeatedly. That way you wouldn't need entropy for invocation IDs at every boot, only during installation. Such values would of course be somewhat predictable, but according to what you've said in this thread, invocation IDs don't need to be unpredictable. You've only said that you want them unique. That is a good point---and by the way, you COULD make the same argument for hashing: one could create another installation-time seed value that will be guaranteed to not leak from the system, and mix it in the hash creation, making the hash unpredictable. Between those two workarounds, it looks to me like we don't need randomness in secular systemd startup at all? (Of course one needs to be aware that collisions are not impossible, only improbable. That's equally true for hashes and random numbers.) At the UUID-level bit lengths, the probability is vanishingly small---although one does have to realize that even very small probability events can be realized with enough statistics, like in this recent measurement of Xenon124 radioactive decay with time constant of over 10^22 years, trillion times longer than the life of the Universe: https://www.nature.com/articles/s41586-019-1124-4 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
Lennart Poettering wrote: >On Do, 25.04.19 13:14, Przemek Klosowski (przemek.klosow...@nist.gov) wrote: >> That leaves the invocation IDs---the UUIDs need to be random to be truly >> Universally Unique, but a limited entropy system is implicitly isolated, so >> maybe the limited UUIDs could be seen as Universal in its very small >> Universe. What is the time duration of the original invocation IDs? What are >> the negative implication of the initial UUIDs being less random than the >> subsequent ones? > >Invocation IDs are useful for globally pinpointing a specific service >invocation. If the UUIDs would stop to be truly random then they'd >stop being universally unique and thus stop being useful. It's perfectly possible for a number to be unique without being random. As an example, you could hash the machine ID, which is supposedly unique in space, and the system clock, which is unique in time. That makes the hash unique in both space and time. Produce invocation IDs by counting up from that value, or by hashing repeatedly. That way you wouldn't need entropy for invocation IDs at every boot, only during installation. Such values would of course be somewhat predictable, but according to what you've said in this thread, invocation IDs don't need to be unpredictable. You've only said that you want them unique. (Of course one needs to be aware that collisions are not impossible, only improbable. That's equally true for hashes and random numbers.) Björn Persson pgpgjRbFY3fy5.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Do, 25.04.19 13:14, Przemek Klosowski (przemek.klosow...@nist.gov) wrote: > On 4/25/19 5:14 AM, Lennart Poettering wrote: > > For the hashtable seeds we use classic /dev/urandom (i.e. entropy from > > a possibly non-initialized pool) since it's OK if those seeds are > > crappy initially, as long as they get better over time, since we > > reseed if we see too many hash collisions. > > I thought that hashing would be fine with a completely predictable > generator, as long as the sequence itself is not correlated, i.e. it would > be OK if the sequence used for hashing was the same on every system. No, because then I can calculate in advance which hashes the target system uses and this still trigger the collisions. The seed hence must be hard to guess from the outside, and thus cannot follow a predictable scheme. > My point here is that actual entropy of the seeding is irrelevant, at all > times---would you agree? No, I would not agree. > That leaves the invocation IDs---the UUIDs need to be random to be truly > Universally Unique, but a limited entropy system is implicitly isolated, so > maybe the limited UUIDs could be seen as Universal in its very small > Universe. What is the time duration of the original invocation IDs? What are > the negative implication of the initial UUIDs being less random than the > subsequent ones? Invocation IDs are useful for globally pinpointing a specific service invocation. If the UUIDs would stop to be truly random then they'd stop being universally unique and thus stop being useful. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/25/19 5:14 AM, Lennart Poettering wrote: For the hashtable seeds we use classic /dev/urandom (i.e. entropy from a possibly non-initialized pool) since it's OK if those seeds are crappy initially, as long as they get better over time, since we reseed if we see too many hash collisions. I thought that hashing would be fine with a completely predictable generator, as long as the sequence itself is not correlated, i.e. it would be OK if the sequence used for hashing was the same on every system. Of course that particular sequence might lead to collisions, but then another uncorrelated but completely predictable sequence should fix that. In other words, it could be seeded from a constant table like [1,2,3,4,.], just as well as from /dev/urandom regardless of its entropy. My point here is that actual entropy of the seeding is irrelevant, at all times---would you agree? That leaves the invocation IDs---the UUIDs need to be random to be truly Universally Unique, but a limited entropy system is implicitly isolated, so maybe the limited UUIDs could be seen as Universal in its very small Universe. What is the time duration of the original invocation IDs? What are the negative implication of the initial UUIDs being less random than the subsequent ones? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 24.04.19 17:28, Björn Persson (Bjorn@rombobjörn.se) wrote: > Lennart Poettering wrote: > >As mentioned before: systemd itself already needs entropy itself (it > >assigns a random 128bit id to each service invocation, dubbed the > >"invocation ID" of it, and it generates the machine ID and seeds its > >hash table hash functions) > > Given that access to entropy during early boot is so problematic, > hardware-dependent and full of catch-22s, it seems to me that an init > system should use the entropy pool only if it really must. > > With that in mind, could you explain why the invocation ID and the hash > tables need to be cryptographically secure? Why is rand or a simple > serial number not good enough? I never heard that lack of a > cryptographically secure invocation ID was a big security problem > before systemd. init systems before systemd had no notion of "sevice lifecycles", they just didn't care. systemd cares about lifecycles however, and assigns a random 128bit id (aka "uuid") to each service invocation cycle. This can be used to associate logs and resource data of a specific service invocation with each other. To be suitable for their purpose, of being *universally unique* you need a good random source for them. You cannot just use srand() and start from a fixed or time source, because then every system would always generate the same uuids... Naive hash tables are prone to collision attacks: if you know the hash function used by the hash tables you might be able to trigger a DoS by forcing collisions and thus degrading the assumed O(1) complexity of hash table operations to O(n). See bug report how this was exploitable in Perl hash tables for example: https://rt.perl.org/Public/Bug/Display.html?id=22371 Because of that modern hash table implementations (including those in systemd) will use a keyed hash function and pick a random value as seed every now and then, so that clients cannot easily trigger DoS like that. This random seed needs to be of relatively high quality, since if clients could guess the seed the excercise would be pointless. Hence no, srand() from timer or constant value wouldn't cut it. But do note that systemd doesn't use blocking getrandom() for seeding hash tables, but uses /dev/urandom instead (i.e. is happy with an uninitialized entropy pool), because for the hash table collisions it's fine if we initially don't have the best entropy as long as it gets better over time. That's because the hash tables in systemd will monitor the fill level and rehash with a fresh seed if we hit a threshold. Anyway, there are a number of other places systemd needs a bit of entropy, these are just two prominent cases. We also make use of /proc/sys/kernel/random/boot_id btw, which also needs some entropy. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 24.04.19 17:43, Tomas Mraz (tm...@redhat.com) wrote: > > But how can it be successful? If systemd already needs to wait until > > the pool is full to get the randomness it needs (and thus blocks > > system boot-up as a whole) then what's the point in running rngd > > afterwards? To reach the point where rngd can be run we already need > > the pool to be full, and hence rngd can't do any good at all anymore, > > whatsoever. > > What does systemd use to generate these random numbers? Does it > directly call getrandom() or does something else? Depends. For the invocation IDs we use getrandom() with default args (i.e. blocking behaviour). Similar for all other cases where we pick 128bit random identifiers (also known as uuids). For the hashtable seeds we use classic /dev/urandom (i.e. entropy from a possibly non-initialized pool) since it's OK if those seeds are crappy initially, as long as they get better over time, since we reseed if we see too many hash collisions. We never use /dev/random or GRND_RANDOM. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 24.04.19 08:27, Adam Williamson (adamw...@fedoraproject.org) wrote: > > a. systemd starts before rngd. > > b. rngd runs before the entropy pool is full. > > c. the entropy pool needs to be full for systemd to start > > > > a before b before c before a before b before c before a? How's that > > solvable? > > > > So if you want rngd to stay and do something useful, then it needs to > > be modified to start *before* systemd, in the initrd, before systemd > > is invoked. i.e. not as regular service, but as kind of an init before > > the real init. > > > > The current mode is just entirely bogus... > > This is all based, though, on your expectation that everything uses > non-blocking interfaces, right? For anything that *does* use > /dev/random or blocking getrandom() - which absolutely does happen, > even the docs say it's deprecated - rngd is still useful. Well, the fix for that is probably not to clutter the system with rngd though. Patching /dev/random out, and patching /dev/urandom into those packages shouldn't be that difficult. It's low-hanging fruit. Very low-hanging in fact, you don't get to fix bugs that often by inserting a single character in your sources... ;-) I mean, how is this ever going to be fixed if not by simply dropping rngd from the default install and then fixing everything popping up? You can't fix these things any other way, it doesn't work in real-life. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 24 Apr 2019 at 11:30, Björn Persson wrote: > Lennart Poettering wrote: > >As mentioned before: systemd itself already needs entropy itself (it > >assigns a random 128bit id to each service invocation, dubbed the > >"invocation ID" of it, and it generates the machine ID and seeds its > >hash table hash functions) > > Given that access to entropy during early boot is so problematic, > hardware-dependent and full of catch-22s, it seems to me that an init > system should use the entropy pool only if it really must. > > With that in mind, could you explain why the invocation ID and the hash > tables need to be cryptographically secure? Why is rand or a simple > serial number not good enough? I never heard that lack of a > cryptographically secure invocation ID was a big security problem > before SystemD. > > I expect they have to be because someone pointed out some security hack that can be done without it and no one ever noticed it before (or had a way to fix it before so we just knocked it as a 'well cant fix it so never mind'). Over the years in this business I have seen a lot of issues in the past with that mantra... they only usually get re-earthed when someone gets a nit because a new tool doesn't have it. > Björn Persson > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 2019-04-24 at 14:16 +0200, Lennart Poettering wrote: > On Mi, 24.04.19 12:37, Nikos Mavrogiannopoulos (n...@redhat.com) > wrote: > > > > As mentioned before: systemd itself already needs entropy itself > > > (it > > > assigns a random 128bit id to each service invocation, dubbed the > > > "invocation ID" of it, and it generates the machine ID and seeds > > > its > > > hash table hash functions), hence rngd doesn't cut it anyway, > > > since it > > > starts after systemd, being a service managed by systemd. If rngd > > > was > > > supposed to fill up the entropy pool at boot, it would have to > > > run as > > > initial PID 1 in the initrd, before systemd, and then hand over > > > to > > > systemd only after the pool is full. But it doesn't, hence rngd > > > is > > > pointless: it runs too late to be useful. > > > > The goal of running rngd early was to have the system boot, not > > necessarily to address systemd's need for random numbers. In that > > it > > is successful. I do not disagree that it is not a clean solution. > > But how can it be successful? If systemd already needs to wait until > the pool is full to get the randomness it needs (and thus blocks > system boot-up as a whole) then what's the point in running rngd > afterwards? To reach the point where rngd can be run we already need > the pool to be full, and hence rngd can't do any good at all anymore, > whatsoever. What does systemd use to generate these random numbers? Does it directly call getrandom() or does something else? -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
Lennart Poettering wrote: >As mentioned before: systemd itself already needs entropy itself (it >assigns a random 128bit id to each service invocation, dubbed the >"invocation ID" of it, and it generates the machine ID and seeds its >hash table hash functions) Given that access to entropy during early boot is so problematic, hardware-dependent and full of catch-22s, it seems to me that an init system should use the entropy pool only if it really must. With that in mind, could you explain why the invocation ID and the hash tables need to be cryptographically secure? Why is rand or a simple serial number not good enough? I never heard that lack of a cryptographically secure invocation ID was a big security problem before SystemD. Björn Persson pgpbHdZeSq8DS.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 2019-04-24 at 14:25 +0200, Lennart Poettering wrote: > On Mi, 24.04.19 06:40, Stephen John Smoogen (smo...@gmail.com) wrote: > > > > As mentioned before: systemd itself already needs entropy itself (it > > > assigns a random 128bit id to each service invocation, dubbed the > > > "invocation ID" of it, and it generates the machine ID and seeds its > > > hash table hash functions), hence rngd doesn't cut it anyway, since it > > > starts after systemd, being a service managed by systemd. If rngd was > > > supposed to fill up the entropy pool at boot, it would have to run as > > > initial PID 1 in the initrd, before systemd, and then hand over to > > > systemd only after the pool is full. But it doesn't, hence rngd is > > > pointless: it runs too late to be useful. > > > > useful to systemd and your problems. What people are trying to say is that > > it is useful to their problems. > > but it can't be. it's logically impossible. let me explain this again: > > 1. systemd needs entropy to start services and other purposes > 2. if the entropy pool is not filled up systemd thus might need to >wait for it to fill up, in a blocking fashion. When it blocks for >that it won't start any services until it unblocks again. > 3. rngd is supposed to fill up the entropy pool, thus allowing systemd >to unblock and start the first services > 4. rngd runs as regular service however, i.e. > > And ther you have your ordering cycle: > > a. systemd starts before rngd. > b. rngd runs before the entropy pool is full. > c. the entropy pool needs to be full for systemd to start > > a before b before c before a before b before c before a? How's that > solvable? > > So if you want rngd to stay and do something useful, then it needs to > be modified to start *before* systemd, in the initrd, before systemd > is invoked. i.e. not as regular service, but as kind of an init before > the real init. > > The current mode is just entirely bogus... This is all based, though, on your expectation that everything uses non-blocking interfaces, right? For anything that *does* use /dev/random or blocking getrandom() - which absolutely does happen, even the docs say it's deprecated - rngd is still useful. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 2019-04-24 at 12:02 +0200, Nikos Mavrogiannopoulos wrote: > Can the jitter entropy gather be done by the kernel? It seems yes via > the jitterentropy_rng module. So a combo of CONFIG_RANDOM_TRUST_CPU > and the jitterentropy_rng may help in simplifying fedora (if people > agree :). This sounds like a useful change, can we make Fedora load this module by default in initrd before systemd starts? Will it help? Or is this module not adding into the entropy estimate as well ? Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 24 Apr 2019 at 08:26, Lennart Poettering wrote: > On Mi, 24.04.19 06:40, Stephen John Smoogen (smo...@gmail.com) wrote: > > > > As mentioned before: systemd itself already needs entropy itself (it > > > assigns a random 128bit id to each service invocation, dubbed the > > > "invocation ID" of it, and it generates the machine ID and seeds its > > > hash table hash functions), hence rngd doesn't cut it anyway, since it > > > starts after systemd, being a service managed by systemd. If rngd was > > > supposed to fill up the entropy pool at boot, it would have to run as > > > initial PID 1 in the initrd, before systemd, and then hand over to > > > systemd only after the pool is full. But it doesn't, hence rngd is > > > pointless: it runs too late to be useful. > > > > useful to systemd and your problems. What people are trying to say is > that > > it is useful to their problems. > > but it can't be. it's logically impossible. let me explain this again: > > 1. systemd needs entropy to start services and other purposes > 2. if the entropy pool is not filled up systemd thus might need to >wait for it to fill up, in a blocking fashion. When it blocks for >that it won't start any services until it unblocks again. > 3. rngd is supposed to fill up the entropy pool, thus allowing systemd >to unblock and start the first services > 4. rngd runs as regular service however, i.e. > > And ther you have your ordering cycle: > > a. systemd starts before rngd. > b. rngd runs before the entropy pool is full. > c. the entropy pool needs to be full for systemd to start > > a before b before c before a before b before c before a? How's that > solvable? > > Again, I am not disagreeing that it isn't important.. I am just saying that the other people saying they need it later and you are coming across as saying get rid of it completely just because it doesn't meet your needs. Most of them are seeing the system way after your problem and needing it fixed then. Let us look at it as a plumbing issue. We currently have a building with a bunch of pipes with small feeds and you as the morning janitor come in first of the day to wash the floors and clean things so other people can get to work. To fill your buckets you need a big basin to start up and have to instead wait around as the pipes fill up your cleaning bucket. You look around and see that people installed various buckets and pots to act as basins in their rooms they use to wash their hands and fases with but you can't use them as they need to be cleaned first. No one sees your problem because by the time their day starts.. you have been in there for hours and got your drip drip going and done your work. The problem here is that how you have come across is "Well I need more water, so we should rip out all the basins until I get one too. Just use this mopbucket water like I do." I don't know if that is what you are meaning to say or not. If it isn't then I am just trying to explain why people are 'reacting' versus 'fixing'. Yes the problem needs to be solved sooner in the chain. You need a proper basin to fill up water in. In fact we all need proper plumbing which helps each service we are running. Working out how to get it is what we should be doing but instead we are arguing over who is going to go on strike first to get it. So if you want rngd to stay and do something useful, then it needs to > be modified to start *before* systemd, in the initrd, before systemd > is invoked. i.e. not as regular service, but as kind of an init before > the real init. > > Which is what I was trying to say but you cut out. > The current mode is just entirely bogus... > > Lennart > > -- > Lennart Poettering, Berlin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 24.04.19 06:40, Stephen John Smoogen (smo...@gmail.com) wrote: > > As mentioned before: systemd itself already needs entropy itself (it > > assigns a random 128bit id to each service invocation, dubbed the > > "invocation ID" of it, and it generates the machine ID and seeds its > > hash table hash functions), hence rngd doesn't cut it anyway, since it > > starts after systemd, being a service managed by systemd. If rngd was > > supposed to fill up the entropy pool at boot, it would have to run as > > initial PID 1 in the initrd, before systemd, and then hand over to > > systemd only after the pool is full. But it doesn't, hence rngd is > > pointless: it runs too late to be useful. > > useful to systemd and your problems. What people are trying to say is that > it is useful to their problems. but it can't be. it's logically impossible. let me explain this again: 1. systemd needs entropy to start services and other purposes 2. if the entropy pool is not filled up systemd thus might need to wait for it to fill up, in a blocking fashion. When it blocks for that it won't start any services until it unblocks again. 3. rngd is supposed to fill up the entropy pool, thus allowing systemd to unblock and start the first services 4. rngd runs as regular service however, i.e. And ther you have your ordering cycle: a. systemd starts before rngd. b. rngd runs before the entropy pool is full. c. the entropy pool needs to be full for systemd to start a before b before c before a before b before c before a? How's that solvable? So if you want rngd to stay and do something useful, then it needs to be modified to start *before* systemd, in the initrd, before systemd is invoked. i.e. not as regular service, but as kind of an init before the real init. The current mode is just entirely bogus... Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 24.04.19 12:37, Nikos Mavrogiannopoulos (n...@redhat.com) wrote: > > As mentioned before: systemd itself already needs entropy itself (it > > assigns a random 128bit id to each service invocation, dubbed the > > "invocation ID" of it, and it generates the machine ID and seeds its > > hash table hash functions), hence rngd doesn't cut it anyway, since it > > starts after systemd, being a service managed by systemd. If rngd was > > supposed to fill up the entropy pool at boot, it would have to run as > > initial PID 1 in the initrd, before systemd, and then hand over to > > systemd only after the pool is full. But it doesn't, hence rngd is > > pointless: it runs too late to be useful. > > The goal of running rngd early was to have the system boot, not > necessarily to address systemd's need for random numbers. In that it > is successful. I do not disagree that it is not a clean solution. But how can it be successful? If systemd already needs to wait until the pool is full to get the randomness it needs (and thus blocks system boot-up as a whole) then what's the point in running rngd afterwards? To reach the point where rngd can be run we already need the pool to be full, and hence rngd can't do any good at all anymore, whatsoever. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 24 Apr 2019 at 06:24, Lennart Poettering wrote: > On Mi, 24.04.19 12:02, Nikos Mavrogiannopoulos (n...@redhat.com) wrote: > > > On Thu, Apr 18, 2019 at 10:23 AM Lennart Poettering > > wrote: > > > Sure, you can invoke rngd before systemd, in which case it would have > > > to be able to run as PID 1 itself pretty much and then hand over > > > things. > > > > > > But why do that in userspace at all? the "Trust CPU RNG" kernel > > > compile time option shows that these things are trivial to solve if > > > people just want to. Instead of involving rngd at all, why not add a > > > similar option for the TPM RNG (or any other non-CPU hw rng) and then > > > rngd doesn't do anything useful anymore whatsoever? I mean, to my > > > knowledge all those other RNGs already feed into the pool anyway, they > > > just don't get trusted and thus don't add to the entropy > > > estimate. Fixing that should be quite doable and given that > > > CONFIG_RANDOM_TRUST_CPU exists now it shouldn't be politically too > > > hard to argue for a CONFIG_RANDOM_TRUST_TPM either... > > > > I like the part that this is trivial to solve if people want to. > > Making people agree is an order of magnitude harder than fixing any > > code. Nevertheless, without rngd, getrandom() would block in one of > > the first services started by systemd (if it doesn't block in systemd > > itself). > > As mentioned before: systemd itself already needs entropy itself (it > assigns a random 128bit id to each service invocation, dubbed the > "invocation ID" of it, and it generates the machine ID and seeds its > hash table hash functions), hence rngd doesn't cut it anyway, since it > starts after systemd, being a service managed by systemd. If rngd was > supposed to fill up the entropy pool at boot, it would have to run as > initial PID 1 in the initrd, before systemd, and then hand over to > systemd only after the pool is full. But it doesn't, hence rngd is > pointless: it runs too late to be useful. > > useful to systemd and your problems. What people are trying to say is that it is useful to their problems. There are several solutions to try here: 1. Make something like it run sooner so it helps your problems 2. Add something like it into the kernel (which has been a Sisyphus task from what i can tell) 3. Pull it into systemd so it helps your problems and others. 4. Keep this thread going with everyone talking past each other. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, Apr 24, 2019 at 12:24 PM Lennart Poettering wrote: > > > But why do that in userspace at all? the "Trust CPU RNG" kernel > > > compile time option shows that these things are trivial to solve if > > > people just want to. Instead of involving rngd at all, why not add a > > > similar option for the TPM RNG (or any other non-CPU hw rng) and then > > > rngd doesn't do anything useful anymore whatsoever? I mean, to my > > > knowledge all those other RNGs already feed into the pool anyway, they > > > just don't get trusted and thus don't add to the entropy > > > estimate. Fixing that should be quite doable and given that > > > CONFIG_RANDOM_TRUST_CPU exists now it shouldn't be politically too > > > hard to argue for a CONFIG_RANDOM_TRUST_TPM either... > > > > I like the part that this is trivial to solve if people want to. > > Making people agree is an order of magnitude harder than fixing any > > code. Nevertheless, without rngd, getrandom() would block in one of > > the first services started by systemd (if it doesn't block in systemd > > itself). > > As mentioned before: systemd itself already needs entropy itself (it > assigns a random 128bit id to each service invocation, dubbed the > "invocation ID" of it, and it generates the machine ID and seeds its > hash table hash functions), hence rngd doesn't cut it anyway, since it > starts after systemd, being a service managed by systemd. If rngd was > supposed to fill up the entropy pool at boot, it would have to run as > initial PID 1 in the initrd, before systemd, and then hand over to > systemd only after the pool is full. But it doesn't, hence rngd is > pointless: it runs too late to be useful. The goal of running rngd early was to have the system boot, not necessarily to address systemd's need for random numbers. In that it is successful. I do not disagree that it is not a clean solution. regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 24.04.19 12:02, Nikos Mavrogiannopoulos (n...@redhat.com) wrote: > On Thu, Apr 18, 2019 at 10:23 AM Lennart Poettering > wrote: > > Sure, you can invoke rngd before systemd, in which case it would have > > to be able to run as PID 1 itself pretty much and then hand over > > things. > > > > But why do that in userspace at all? the "Trust CPU RNG" kernel > > compile time option shows that these things are trivial to solve if > > people just want to. Instead of involving rngd at all, why not add a > > similar option for the TPM RNG (or any other non-CPU hw rng) and then > > rngd doesn't do anything useful anymore whatsoever? I mean, to my > > knowledge all those other RNGs already feed into the pool anyway, they > > just don't get trusted and thus don't add to the entropy > > estimate. Fixing that should be quite doable and given that > > CONFIG_RANDOM_TRUST_CPU exists now it shouldn't be politically too > > hard to argue for a CONFIG_RANDOM_TRUST_TPM either... > > I like the part that this is trivial to solve if people want to. > Making people agree is an order of magnitude harder than fixing any > code. Nevertheless, without rngd, getrandom() would block in one of > the first services started by systemd (if it doesn't block in systemd > itself). As mentioned before: systemd itself already needs entropy itself (it assigns a random 128bit id to each service invocation, dubbed the "invocation ID" of it, and it generates the machine ID and seeds its hash table hash functions), hence rngd doesn't cut it anyway, since it starts after systemd, being a service managed by systemd. If rngd was supposed to fill up the entropy pool at boot, it would have to run as initial PID 1 in the initrd, before systemd, and then hand over to systemd only after the pool is full. But it doesn't, hence rngd is pointless: it runs too late to be useful. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Thu, Apr 18, 2019 at 10:23 AM Lennart Poettering wrote: > Sure, you can invoke rngd before systemd, in which case it would have > to be able to run as PID 1 itself pretty much and then hand over > things. > > But why do that in userspace at all? the "Trust CPU RNG" kernel > compile time option shows that these things are trivial to solve if > people just want to. Instead of involving rngd at all, why not add a > similar option for the TPM RNG (or any other non-CPU hw rng) and then > rngd doesn't do anything useful anymore whatsoever? I mean, to my > knowledge all those other RNGs already feed into the pool anyway, they > just don't get trusted and thus don't add to the entropy > estimate. Fixing that should be quite doable and given that > CONFIG_RANDOM_TRUST_CPU exists now it shouldn't be politically too > hard to argue for a CONFIG_RANDOM_TRUST_TPM either... I like the part that this is trivial to solve if people want to. Making people agree is an order of magnitude harder than fixing any code. Nevertheless, without rngd, getrandom() would block in one of the first services started by systemd (if it doesn't block in systemd itself). The kernel option CONFIG_RANDOM_TRUST_CPU, is not portable so you'll need something more for non-x86. What rngd does that the kernel doesn't is a jitter entropy "subsystem" which will feed the kernel with random data, even when the hardware doesn't support something native. Can the jitter entropy gather be done by the kernel? It seems yes via the jitterentropy_rng module. So a combo of CONFIG_RANDOM_TRUST_CPU and the jitterentropy_rng may help in simplifying fedora (if people agree :). regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mo, 22.04.19 08:35, Robert Marcano (rob...@marcanoonline.com) wrote: > > What's the story anyway for rngd? Why would userspace be better at > > providing entropy to the kernel than the kernel itself? Why do we > > enable it on desktops at all, such systems should not be > > entropy-starved. > > Non developers, true. Developer's workstations, wrong. Just signing a few > packages (java's jarsigner) to test your code runs fine under those > conditions can drop to near zero the entropy, taking a lot of time to finish > the signing. Well, "jarsigner" is broken then. It appears to use /dev/random instead of /dev/urandom. if you use the latter, then you can pull out as much randomness as you want, it's not affected by "entropy depletion". See man page about that: http://man7.org/linux/man-pages/man4/urandom.4.html Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Do, 18.04.19 09:16, stan (upai...@zoho.com) wrote: > On Thu, 18 Apr 2019 10:22:27 +0200 > Lennart Poettering wrote: > > > On Mi, 17.04.19 11:29, Japheth Cleaver (clea...@terabithia.org) wrote: > > > > This seems like a false dichotomy, no? Surely, things like this are > > > a possibility: > > > https://lists.freedesktop.org/archives/systemd-devel/2010-September/000225.html > > > > That too means the service gets started after the init system is up, > > and the init system already requires entropy, so it's pointless. > > On shutdown the existing entropy is stored for use at startup (it is > still entropy on restart if an attacker hasn't seen it). So, if init > uses that entropy and depletes it, it would be a positive to restore it > as soon as possible. That is pretty late: it's systemd-random-seed.service that does that and it runs after /var is mounted writable, which is relatively late in the early-boot phase. Moreover we don't credit entropy when writing the seed back into the kernel, since it's not safe to do so in the general case, as people frequently deploy the same pre-built image on multiple systems and tend to forget to invalidate the saved seed then. And all images that come up with the same saved seed would have the same entropy pool initially hence the excercsie would be pointless. There has been work on making this opt-in (https://github.com/systemd/systemd/pull/10621) but this has stalled since. If anyone wants to resurrect that, please do. However, regardless whether s-r-s.s credits entropy or does not: it runs too late: there are plenty entropy users running before that that need to wait for the pool to be filled. And we can't really move s-r-s.s earlier. [And also: the concept of "depleting" the entropy pool is a misconception. This doesn't happen if people use the APIs correctly, i.e. /dev/urandom instead of /dev/random (or their getrandom() equivalents). The kernel documentation calls /dev/random a "legacy interface" for a reason (see http://man7.org/linux/man-pages/man4/urandom.4.html). Once the entropy pool is filled it is filled for good, if /dev/urandom is used.] (BTW: in case you wonder why we wait for /var being writable before s-r-s.s is run: that's because we need to invalidate the old stored seed when you use it, so that it is never reused again. This means we need to overwrite the seed file when we use it.) Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/17/19 4:38 AM, Lennart Poettering wrote: On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote: I think all of these are good ideas. "No udev-settle" seems like a nice highlevel goal to shoot for. Another one I might add: "No stuck stop jobs" - it annoys me every single time when I reboot and something like rngd or conmon holds up my reboot for several minutes for no reason at all. I've seen the rngd stop thing, hadn't had time to investigate it yet as more urgent fires keep showing up :/ What's the story anyway for rngd? Why would userspace be better at providing entropy to the kernel than the kernel itself? Why do we enable it on desktops at all, such systems should not be entropy-starved. Non developers, true. Developer's workstations, wrong. Just signing a few packages (java's jarsigner) to test your code runs fine under those conditions can drop to near zero the entropy, taking a lot of time to finish the signing. Do we need this at all now that the kernel can use RDRAND itself? rngd runs as regular system service, hence what's the point of that altogether? I mean, it runs so late during boot, at a point where the entropy pool is full anyway, and we need the kernel's RNG much much earlier already (already because systemd assigns a uuid to each service invocation that derives from kernel RNG, and it does that super early). So, why run a service that is supposed to fill up the entropy pool at a point where we don't need it anymore, and if the kernel can do what it does most likely already on its own? Isn't it time to kick rngd out of the default install, in particular on the workstation image? Isn't keeping it around just cargo culting? Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Thu, 18 Apr 2019 10:22:27 +0200 Lennart Poettering wrote: > On Mi, 17.04.19 11:29, Japheth Cleaver (clea...@terabithia.org) wrote: > > This seems like a false dichotomy, no? Surely, things like this are > > a possibility: > > https://lists.freedesktop.org/archives/systemd-devel/2010-September/000225.html > > > > That too means the service gets started after the init system is up, > and the init system already requires entropy, so it's pointless. On shutdown the existing entropy is stored for use at startup (it is still entropy on restart if an attacker hasn't seen it). So, if init uses that entropy and depletes it, it would be a positive to restore it as soon as possible. But that is the purpose of having the CPRNG be robust. The seeds from last run are used until there is enough new entropy to reseed, and in the meantime the CPRNG provides the 'random' numbers. For most purposes this is more than adequate. If the CPRNG can be cracked with the short stream fed from it to start up the system, it is not robust. And that assumes that an attacker has complete access to that stream. The main threat from random numbers is that 'password' is a perfectly legitimate random string, so even hardware random number generators can generate easy to crack strings of numbers. That is, random doesn't mean strong cryptographically. What we really want are unpredictable crpytographically strong numbers. And that is also why it is so hard to validate random number generators; if they aren't failing the tests occasionally, they aren't random. But if they are failing the tests occasionally, it might or might not indicate they are not random, and thus predictable. And we might not even be testing the right thing! In any case, a good reason to randomly change seeds to CPRNGs regularly, if possible. Even a vulnerable CPRNG with a long stream required to crack it is robust if reseeded constantly at short intervals with randomness (the strategy of the linux kernel). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
> "LP" == Lennart Poettering writes: LP> Yes it is. But so is rngd afaik? The software isn't exclusive to any particular architecture, though it may of course have different sources of entropy on different architectures. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 2019-04-17 at 10:55 -0400, Steve Grubb wrote: > On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote: > > On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote: > > > > > > > > I think all of these are good ideas. "No udev-settle" seems like a > > > > nice > > > > highlevel goal to shoot for. > > > > > > > > > > > > > > > > Another one I might add: "No stuck stop jobs" - it annoys me every > > > > single > > > > time when I reboot and something like rngd or conmon holds up my > > > > reboot > > > > for several minutes for no reason at all. > > > > > > > > > I've seen the rngd stop thing, hadn't had time to investigate it yet as > > > more urgent fires keep showing up :/ > > > > What's the story anyway for rngd? Why would userspace be better at > > providing entropy to the kernel than the kernel itself? Why do we > > enable it on desktops at all, such systems should not be > > entropy-starved. Do we need this at all now that the kernel can use > > RDRAND itself? > > The kernel uses RDRAND/SEED but it does not increment the entropy estimate > based on it. Another interesting thing is that TPM chips also have entropy > available, but the kernel does not use it. So, if you have a hardware based > entropy source such as TPM, you need rngd to move the entropy to the kernel. > And it also can mine CPU jitter to create some entropy on its own. And it > also supports the NIST beacon if you want that kind of entropy. Rngd greatly > helps system recover from low entropy situations. > > > > rngd runs as regular system service, hence what's the point of that > > altogether? I mean, it runs so late during boot, at a point where the > > entropy pool is full anyway, > > I'd really like to see it start much earlier. Any way to make that happen? > > > and we need the kernel's RNG much much earlier already (already because > > systemd assigns a uuid to each service invocation that derives from kernel > > RNG, and it does that super early). So, why run a service that is supposed > > to fill up the entropy pool at a point where we don't need it anymore, and > > if the kernel can do what it does most likely already on its own? > > The kernel cannot recover quickly when stressed for continued entropy > depletion. For example, we are required to be able to supply all guest VM's > with entropy from the host. They draw down the entropy pools which need > replenishment. The kernel is constantly starved for entropy. > > > Isn't it time to kick rngd out of the default install, in particular > > on the workstation image? Isn't keeping it around just cargo culting? > > I think you're being harsh without really looking deeply into the problem. If > we could set a sysctl to tell the kernel to use a TPM or increment entropy > estimate when RDSEED is used, I'd agree we should consider this. And to be > honest, it should be running during an anaconda or kickstart install in order > to safely setup an encrypted disk. AFAIK, we already home that in place - if there is not enough entropy when storage encryption is being setup, the installation will pause & notify the user to provide more entropy (generally by monkey-bashing keyboard keys). > Also, livecd uses are starved for entropy > and must use rngd to be responsive and safe. If you have a TPM, the best use > you'll get out of it is providing random numbers via rngd. :-) > > -Steve > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, Apr 17, 2019 at 10:55:58AM -0400, Steve Grubb wrote: > On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote: > > On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote: > > > > > > > > I think all of these are good ideas. "No udev-settle" seems like a > > > > nice > > > > highlevel goal to shoot for. > > > > > > > > > > > > > > > > Another one I might add: "No stuck stop jobs" - it annoys me every > > > > single > > > > time when I reboot and something like rngd or conmon holds up my > > > > reboot > > > > for several minutes for no reason at all. > > > > > > > > > > > > I've seen the rngd stop thing, hadn't had time to investigate it yet as > > > more urgent fires keep showing up :/ > > > > What's the story anyway for rngd? Why would userspace be better at > > providing entropy to the kernel than the kernel itself? Why do we > > enable it on desktops at all, such systems should not be > > entropy-starved. Do we need this at all now that the kernel can use > > RDRAND itself? > > The kernel uses RDRAND/SEED but it does not increment the entropy estimate > based on it. Another interesting thing is that TPM chips also have entropy > available, but the kernel does not use it. So, if you have a hardware based > entropy source such as TPM, you need rngd to move the entropy to the kernel. > And it also can mine CPU jitter to create some entropy on its own. And it > also supports the NIST beacon if you want that kind of entropy. Rngd greatly > helps system recover from low entropy situations. > > > > rngd runs as regular system service, hence what's the point of that > > altogether? I mean, it runs so late during boot, at a point where the > > entropy pool is full anyway, > > I'd really like to see it start much earlier. Any way to make that happen? > > > and we need the kernel's RNG much much earlier already (already because > > systemd assigns a uuid to each service invocation that derives from kernel > > RNG, and it does that super early). So, why run a service that is supposed > > to fill up the entropy pool at a point where we don't need it anymore, and > > if the kernel can do what it does most likely already on its own? > > The kernel cannot recover quickly when stressed for continued entropy > depletion. For example, we are required to be able to supply all guest VM's > with entropy from the host. They draw down the entropy pools which need > replenishment. The kernel is constantly starved for entropy. The recommendation is for virtio-rng to be backed by /dev/urandom these days, so you won't deplete the host /dev/random anymore. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 17.04.19 15:25, Simo Sorce (s...@redhat.com) wrote: > On Wed, 2019-04-17 at 15:14 -0400, Steve Grubb wrote: > > Many have tried to convince upstream about this. If anyone here has > > influence, > > please try. > > If upstream is currently resistant, what about turning rngd into a > loadable kernel module and then insure it is in the initramfs and > loaded at kernel boot time ? > > Would this be a way to show upstream that this works and perhaps allow > inclusion later on ? So apparently the kernel can do both the RDSEED/RDRAND stuff already on its own (and this is turned on in Fedora) and also can credit entropy based on other hwrngs too (see other mail). The latter is a bit awkward since it requires a kernel cmdline option currently to enable, and is global for all drivers though it would probably be wise to enable this individually for each driver judging by how much the device is trusted or not. (Also note that virtio-rng is something systemd automatically loads if it's not around but the environment would support it, and it appears to credit entropy too.) Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 17.04.19 16:05, Chris Murphy (li...@colorremedies.com) wrote: > On Wed, Apr 17, 2019 at 11:36 AM Lennart Poettering > wrote: > > > > Yeah, all that stuff is stuff the kernel could do better on its > > own. If the CPU jitter stuff or the TPM stuff is a good idea, then why > > not add that to the kernel natively, why involve userspace with that? > > i.e. if the TPM and the CPU jitter stuff can be trusted, then the same > > thing as for CONFIG_RANDOM_TRUST_CPU=y should be done: pass the random > > data into the pool directly inside in the kernel. > > $ grep CONFIG_HW_RANDOM_TPM /boot/config-5.0.6-300.fc30.x86_64 > CONFIG_HW_RANDOM_TPM=y So apparently, since a long time the kernel actually could push data from hwrngs into the kernel pool while crediting entropy: https://lkml.org/lkml/2018/11/2/193 i.e. it's the "rng_core.default_quality=700" switch on the kernel cmdline. It sounds like that option is just something that needs a compile time option that Fedora could just turn on. Quoting from that mail: "This is better than relying on rng-tools." > /usr/lib/systemd/system/rngd.service contains > > WantedBy=multi-user.target > > I'm gonna guess Steve Grubb is wondering whether it could be wanted by > an earlier target, possibly cryptsetup-pre.target? I don't see a > service file in the upstream project so this may have been selected by > the Fedora packager as a known to work option. WantedBy= doesn't really say much about when something is started, just about what wants it started. It's not about ordering, it's about requirement. If you want to order it early then set DefaultDependencies=no and use Before= some appropriate unit. But this is all pretty much pointless, since PID 1 (systemd) itself already needs entropy, and thus starting this after PID 1 is useless. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 17.04.19 15:14, Steve Grubb (sgr...@redhat.com) wrote: > #!/bin/sh > > while [ 1 ] > do > /bin/cat /proc/sys/kernel/random/entropy_avail > sleep 1 > done > > Then in another: > > cat /dev/random >/dev/null > > After a couple seconds, hit ctl-c to kill cat. Watch what happens to the > entropy. Well, don't use /dev/random. Use /dev/urandom. The official documentation declares /dev/random a "legacy interface". http://man7.org/linux/man-pages/man4/random.4.html Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 17.04.19 11:29, Japheth Cleaver (clea...@terabithia.org) wrote: > On 4/17/2019 10:36 AM, Lennart Poettering wrote: > > On Mi, 17.04.19 10:55, Steve Grubb (sgr...@redhat.com) wrote: > > > > > On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote: > > > > rngd runs as regular system service, hence what's the point of that > > > > altogether? I mean, it runs so late during boot, at a point where the > > > > entropy pool is full anyway, > > > I'd really like to see it start much earlier. Any way to make that > > > happen? > > Well, no. I mean, the only way you can do that is by turning rngd into > > its own init system, if you want it to run before the init > > system. > > This seems like a false dichotomy, no? Surely, things like this are a > possibility: > https://lists.freedesktop.org/archives/systemd-devel/2010-September/000225.html That too means the service gets started after the init system is up, and the init system already requires entropy, so it's pointless. > But beyond that, is there really no way to lift this earlier in the boot > logic? Sure, you can invoke rngd before systemd, in which case it would have to be able to run as PID 1 itself pretty much and then hand over things. But why do that in userspace at all? the "Trust CPU RNG" kernel compile time option shows that these things are trivial to solve if people just want to. Instead of involving rngd at all, why not add a similar option for the TPM RNG (or any other non-CPU hw rng) and then rngd doesn't do anything useful anymore whatsoever? I mean, to my knowledge all those other RNGs already feed into the pool anyway, they just don't get trusted and thus don't add to the entropy estimate. Fixing that should be quite doable and given that CONFIG_RANDOM_TRUST_CPU exists now it shouldn't be politically too hard to argue for a CONFIG_RANDOM_TRUST_TPM either... Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 17.04.19 13:01, Jason L Tibbitts III (ti...@math.uh.edu) wrote: > > "LP" == Lennart Poettering writes: > > LP> That's not true anymore. There's a kernel compile time option now > LP> for that in CONFIG_RANDOM_TRUST_CPU=y. And yes, the Fedora kernel > LP> sets that since a while. > > Isn't this arch-dependent? Yes it is. But so is rngd afaik? It uses the RDTSC, RDSEED and TPM RNG iiuc and those are either x86 specific (in case of RDTSC/RDSEED) or pretty much so (in case of the TPM RNG). Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, Apr 17, 2019 at 11:36 AM Lennart Poettering wrote: > > Yeah, all that stuff is stuff the kernel could do better on its > own. If the CPU jitter stuff or the TPM stuff is a good idea, then why > not add that to the kernel natively, why involve userspace with that? > i.e. if the TPM and the CPU jitter stuff can be trusted, then the same > thing as for CONFIG_RANDOM_TRUST_CPU=y should be done: pass the random > data into the pool directly inside in the kernel. $ grep CONFIG_HW_RANDOM_TPM /boot/config-5.0.6-300.fc30.x86_64 CONFIG_HW_RANDOM_TPM=y I've got no idea if this is for TPM 1.x or 2.x or both. > Well, no. I mean, the only way you can do that is by turning rngd into > its own init system, if you want it to run before the init > system. /usr/lib/systemd/system/rngd.service contains WantedBy=multi-user.target I'm gonna guess Steve Grubb is wondering whether it could be wanted by an earlier target, possibly cryptsetup-pre.target? I don't see a service file in the upstream project so this may have been selected by the Fedora packager as a known to work option. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, Apr 16, 2019 at 09:06:02AM -0700, Adam Williamson wrote: > On Tue, 2019-04-16 at 11:48 -0400, Matthias Clasen wrote: > > On Tue, Apr 9, 2019 at 12:08 PM Lennart Poettering > > wrote: > > > > > Heya, > > > > > > today I installed the current Fedora 30 Workstation beta on my new > > > laptop. It was a bumpy ride, I must say (the partitioner (blivet?) > > > crashed five times or so on me, always kicking me out of anaconda > > > again, just because I wanted to undo something). But I don't really > > > want to discuss that. What I do want to discuss is this: > > > > > > > > > > > > Ideally, the top 4 wouldn't be installed at all anymore (in case of > > > the first two at least on the systems which do not need them). But if > > > that's not in the cards, it would be great to at least not enable > > > these services anymore in the default boot so that they are only a > > > "systemctl enable" away for people who need them? > > > > > > > > I think all of these are good ideas. "No udev-settle" seems like a nice > > highlevel goal to shoot for. > > > > Another one I might add: "No stuck stop jobs" - it annoys me every single > > time when I reboot and something like rngd or conmon holds up my reboot > > for several minutes for no reason at all. > > I've seen the rngd stop thing, hadn't had time to investigate it yet as > more urgent fires keep showing up :/ I opened a bug a while back, but it hasn't cropped up since I enabled additional logging: https://bugzilla.redhat.com/show_bug.cgi?id=1690364 Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 17 Apr 2019 15:14:54 -0400 Steve Grubb wrote: > Ah...the devil is in the details. It does not credit entropy. This > can easily be tested. systemctl stop rngd. Then open 2 terminal > windows. In one terminal start this shell script: > > #!/bin/sh > > while [ 1 ] > do > /bin/cat /proc/sys/kernel/random/entropy_avail > sleep 1 > done > > Then in another: > > cat /dev/random >/dev/null > > After a couple seconds, hit ctl-c to kill cat. Watch what happens to > the entropy. > > I have a Kabylake system idling. It takes 3 minutes for entropy to > get back to 3k after stopping the consumer. At that point its losing > about as much as its gaining. If I start rngd and do the same test, > my entropy bounces back to over 3k in less than a second. As it > stands today, rngd has a dramatic effect on entropy. I run a daemon that harvests entropy from the atmosphere via an rtl2832 and feeds it into the kernel via /dev/random. And, yes it makes a big difference to feed the entropy pool. When random.c was rewritten to use chacha instead of the modified mersenne twister (4.xx?), the way entropy was used changed. It used to bleed constantly across from the pool that is /dev/random into /dev/urandom when it was above the threshold set in write_wakeup_threshold. Now, it only checks when the kernel routine for get_random is called and reseeds if enough entropy is present. It always has decremented and still decrements entropy available when it uses some. Under mersenne it used to be possible to set a timer as well, but that went away with chacha. I patch to enable that feature in the new random.c, so I can reseed the chacha on a periodic interval. The rationale for chacha was that server farms were starving for entropy, and it is considered more robust for low entropy conditions, at least that is what I understand from my reading. As far as the CPU hardware entropy generators, those are not open source, so it is not possible to determine if they have a backdoor. Research has shown, however, that if any true entropy is fed into a stream with compromised entropy, it results in a stream with better entropy. That is, a system using a compromised hardware generator will have more robust entropy when combined with other sources of entropy. The kernel does this via a hash to smear the mix. An attacker can no longer utilize an attack knowing the bits came from the compromised generator. Things like the bit bubbler are reasonably cheap (~100 dollars US) and provide enough entropy for a small server farm. Even the rtl2832 (~10 dollars US) provides about 90 Kbytes of entropy per second (the kernel entropy pool is 4kB). Not enough for monte carlo simulations, but plenty for a home system or a few servers. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 2019-04-17 at 15:14 -0400, Steve Grubb wrote: > Many have tried to convince upstream about this. If anyone here has > influence, > please try. If upstream is currently resistant, what about turning rngd into a loadable kernel module and then insure it is in the initramfs and loaded at kernel boot time ? Would this be a way to show upstream that this works and perhaps allow inclusion later on ? Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wednesday, April 17, 2019 1:36:08 PM EDT Lennart Poettering wrote: > On Mi, 17.04.19 10:55, Steve Grubb (sgr...@redhat.com) wrote: > > On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote: > > > What's the story anyway for rngd? Why would userspace be better at > > > providing entropy to the kernel than the kernel itself? Why do we > > > enable it on desktops at all, such systems should not be > > > entropy-starved. Do we need this at all now that the kernel can use > > > RDRAND itself? > > > > The kernel uses RDRAND/SEED but it does not increment the entropy > > estimate based on it. Another interesting thing is that TPM chips also > > have entropy > > That's not true anymore. There's a kernel compile time option now for > that in CONFIG_RANDOM_TRUST_CPU=y. And yes, the Fedora kernel sets > that since a while. Ah...the devil is in the details. It does not credit entropy. This can easily be tested. systemctl stop rngd. Then open 2 terminal windows. In one terminal start this shell script: #!/bin/sh while [ 1 ] do /bin/cat /proc/sys/kernel/random/entropy_avail sleep 1 done Then in another: cat /dev/random >/dev/null After a couple seconds, hit ctl-c to kill cat. Watch what happens to the entropy. I have a Kabylake system idling. It takes 3 minutes for entropy to get back to 3k after stopping the consumer. At that point its losing about as much as its gaining. If I start rngd and do the same test, my entropy bounces back to over 3k in less than a second. As it stands today, rngd has a dramatic effect on entropy. > > available, but the kernel does not use it. So, if you have a hardware > > based entropy source such as TPM, you need rngd to move the entropy to > > the kernel. And it also can mine CPU jitter to create some entropy on > > its own. And it also supports the NIST beacon if you want that kind of > > entropy. Rngd greatly helps system recover from low entropy situations. > > Yeah, all that stuff is stuff the kernel could do better on its > own. Many have tried to convince upstream about this. If anyone here has influence, please try. > If the CPU jitter stuff or the TPM stuff is a good idea, then why > not add that to the kernel natively, why involve userspace with that? I agree. :-) > i.e. if the TPM and the CPU jitter stuff can be trusted, then the same > thing as for CONFIG_RANDOM_TRUST_CPU=y should be done: pass the random > data into the pool directly inside in the kernel. And credit entropy! > > > rngd runs as regular system service, hence what's the point of that > > > altogether? I mean, it runs so late during boot, at a point where the > > > entropy pool is full anyway, > > > > I'd really like to see it start much earlier. Any way to make that > > happen? > > Well, no. I mean, the only way you can do that is by turning rngd into > its own init system, if you want it to run before the init > system. > > > > RNG, and it does that super early). So, why run a service that is > > > supposed to fill up the entropy pool at a point where we don't need it > > > anymore, and if the kernel can do what it does most likely already on > > > its own? > > > > The kernel cannot recover quickly when stressed for continued entropy > > depletion. For example, we are required to be able to supply all guest > > VM's with entropy from the host. They draw down the entropy pools which > > need replenishment. The kernel is constantly starved for entropy. > > That's not how the entropy pool works. Once it is full it's full, and > it doesn't run empty anymore. Empirical evidence suggests otherwise. See the test above. > > I think you're being harsh without really looking deeply into the > > problem. If we could set a sysctl to tell the kernel to use a TPM or > > increment entropy estimate when RDSEED is used, I'd agree we should > > consider this. And to be > > OK, so I guess that point in time is now. Though it's not a sysctl, > but a compile time option (see above). It looks as though it may be controlled as a boot commandline option, too. But that is likely intended to disable the effect it has. -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/17/2019 10:36 AM, Lennart Poettering wrote: On Mi, 17.04.19 10:55, Steve Grubb (sgr...@redhat.com) wrote: On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote: rngd runs as regular system service, hence what's the point of that altogether? I mean, it runs so late during boot, at a point where the entropy pool is full anyway, I'd really like to see it start much earlier. Any way to make that happen? Well, no. I mean, the only way you can do that is by turning rngd into its own init system, if you want it to run before the init system. This seems like a false dichotomy, no? Surely, things like this are a possibility: https://lists.freedesktop.org/archives/systemd-devel/2010-September/000225.html But beyond that, is there really no way to lift this earlier in the boot logic? -jc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
> "LP" == Lennart Poettering writes: LP> That's not true anymore. There's a kernel compile time option now LP> for that in CONFIG_RANDOM_TRUST_CPU=y. And yes, the Fedora kernel LP> sets that since a while. Isn't this arch-dependent? config RANDOM_TRUST_CPU bool "Trust the CPU manufacturer to initialize Linux's CRNG" depends on X86 || S390 || PPC default n Not sure what happens on ARM but I think it would need to be considered. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 2019-04-17 at 19:36 +0200, Lennart Poettering wrote: > On Mi, 17.04.19 10:55, Steve Grubb (sgr...@redhat.com) wrote: > > > On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote: > > > On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote: > > > > > > > > > > > I think all of these are good ideas. "No udev-settle" seems like a > > > > > nice > > > > > highlevel goal to shoot for. > > > > > > > > > > > > > > > > > > > > Another one I might add: "No stuck stop jobs" - it annoys me every > > > > > single > > > > > time when I reboot and something like rngd or conmon holds up my > > > > > reboot > > > > > for several minutes for no reason at all. > > > > > > > > > > > > > > > > I've seen the rngd stop thing, hadn't had time to investigate it yet as > > > > more urgent fires keep showing up :/ > > > > > > What's the story anyway for rngd? Why would userspace be better at > > > providing entropy to the kernel than the kernel itself? Why do we > > > enable it on desktops at all, such systems should not be > > > entropy-starved. Do we need this at all now that the kernel can use > > > RDRAND itself? > > > > The kernel uses RDRAND/SEED but it does not increment the entropy estimate > > based on it. Another interesting thing is that TPM chips also have > > entropy > > That's not true anymore. There's a kernel compile time option now for > that in CONFIG_RANDOM_TRUST_CPU=y. And yes, the Fedora kernel sets > that since a while. > > > available, but the kernel does not use it. So, if you have a hardware based > > entropy source such as TPM, you need rngd to move the entropy to the kernel. > > And it also can mine CPU jitter to create some entropy on its own. And it > > also supports the NIST beacon if you want that kind of entropy. Rngd greatly > > helps system recover from low entropy situations. > > Yeah, all that stuff is stuff the kernel could do better on its > own. If the CPU jitter stuff or the TPM stuff is a good idea, then why > not add that to the kernel natively, why involve userspace with that? > i.e. if the TPM and the CPU jitter stuff can be trusted, then the same > thing as for CONFIG_RANDOM_TRUST_CPU=y should be done: pass the random > data into the pool directly inside in the kernel. Big +1, I've been saying this for ages as well ... > > > rngd runs as regular system service, hence what's the point of that > > > altogether? I mean, it runs so late during boot, at a point where the > > > entropy pool is full anyway, > > > > I'd really like to see it start much earlier. Any way to make that > > happen? > > Well, no. I mean, the only way you can do that is by turning rngd into > its own init system, if you want it to run before the init > system. > > > > RNG, and it does that super early). So, why run a service that is supposed > > > to fill up the entropy pool at a point where we don't need it anymore, and > > > if the kernel can do what it does most likely already on its own? > > > > The kernel cannot recover quickly when stressed for continued entropy > > depletion. For example, we are required to be able to supply all guest VM's > > with entropy from the host. They draw down the entropy pools which need > > replenishment. The kernel is constantly starved for entropy. > > That's not how the entropy pool works. Once it is full it's full, and > it doesn't run empty anymore. > > > I think you're being harsh without really looking deeply into the problem. > > If > > we could set a sysctl to tell the kernel to use a TPM or increment entropy > > estimate when RDSEED is used, I'd agree we should consider this. And > > to be > > OK, so I guess that point in time is now. Though it's not a sysctl, > but a compile time option (see above). I concur, I would really like to see rngd become a thing of the past as well. The kernel has all the tools and access needed to reseed itself, *requiring* a racy userspace tool to do the kernel's job is a bit ridiculous. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 17.04.19 10:55, Steve Grubb (sgr...@redhat.com) wrote: > On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote: > > On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote: > > > > > > > > I think all of these are good ideas. "No udev-settle" seems like a > > > > nice > > > > highlevel goal to shoot for. > > > > > > > > > > > > > > > > Another one I might add: "No stuck stop jobs" - it annoys me every > > > > single > > > > time when I reboot and something like rngd or conmon holds up my > > > > reboot > > > > for several minutes for no reason at all. > > > > > > > > > > > > I've seen the rngd stop thing, hadn't had time to investigate it yet as > > > more urgent fires keep showing up :/ > > > > What's the story anyway for rngd? Why would userspace be better at > > providing entropy to the kernel than the kernel itself? Why do we > > enable it on desktops at all, such systems should not be > > entropy-starved. Do we need this at all now that the kernel can use > > RDRAND itself? > > The kernel uses RDRAND/SEED but it does not increment the entropy estimate > based on it. Another interesting thing is that TPM chips also have > entropy That's not true anymore. There's a kernel compile time option now for that in CONFIG_RANDOM_TRUST_CPU=y. And yes, the Fedora kernel sets that since a while. > available, but the kernel does not use it. So, if you have a hardware based > entropy source such as TPM, you need rngd to move the entropy to the kernel. > And it also can mine CPU jitter to create some entropy on its own. And it > also supports the NIST beacon if you want that kind of entropy. Rngd greatly > helps system recover from low entropy situations. Yeah, all that stuff is stuff the kernel could do better on its own. If the CPU jitter stuff or the TPM stuff is a good idea, then why not add that to the kernel natively, why involve userspace with that? i.e. if the TPM and the CPU jitter stuff can be trusted, then the same thing as for CONFIG_RANDOM_TRUST_CPU=y should be done: pass the random data into the pool directly inside in the kernel. > > rngd runs as regular system service, hence what's the point of that > > altogether? I mean, it runs so late during boot, at a point where the > > entropy pool is full anyway, > > I'd really like to see it start much earlier. Any way to make that > happen? Well, no. I mean, the only way you can do that is by turning rngd into its own init system, if you want it to run before the init system. > > RNG, and it does that super early). So, why run a service that is supposed > > to fill up the entropy pool at a point where we don't need it anymore, and > > if the kernel can do what it does most likely already on its own? > > The kernel cannot recover quickly when stressed for continued entropy > depletion. For example, we are required to be able to supply all guest VM's > with entropy from the host. They draw down the entropy pools which need > replenishment. The kernel is constantly starved for entropy. That's not how the entropy pool works. Once it is full it's full, and it doesn't run empty anymore. > I think you're being harsh without really looking deeply into the problem. If > we could set a sysctl to tell the kernel to use a TPM or increment entropy > estimate when RDSEED is used, I'd agree we should consider this. And > to be OK, so I guess that point in time is now. Though it's not a sysctl, but a compile time option (see above). Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote: > On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote: > > > > > I think all of these are good ideas. "No udev-settle" seems like a > > > nice > > > highlevel goal to shoot for. > > > > > > > > > > > > Another one I might add: "No stuck stop jobs" - it annoys me every > > > single > > > time when I reboot and something like rngd or conmon holds up my > > > reboot > > > for several minutes for no reason at all. > > > > > > > > I've seen the rngd stop thing, hadn't had time to investigate it yet as > > more urgent fires keep showing up :/ > > What's the story anyway for rngd? Why would userspace be better at > providing entropy to the kernel than the kernel itself? Why do we > enable it on desktops at all, such systems should not be > entropy-starved. Do we need this at all now that the kernel can use > RDRAND itself? The kernel uses RDRAND/SEED but it does not increment the entropy estimate based on it. Another interesting thing is that TPM chips also have entropy available, but the kernel does not use it. So, if you have a hardware based entropy source such as TPM, you need rngd to move the entropy to the kernel. And it also can mine CPU jitter to create some entropy on its own. And it also supports the NIST beacon if you want that kind of entropy. Rngd greatly helps system recover from low entropy situations. > rngd runs as regular system service, hence what's the point of that > altogether? I mean, it runs so late during boot, at a point where the > entropy pool is full anyway, I'd really like to see it start much earlier. Any way to make that happen? > and we need the kernel's RNG much much earlier already (already because > systemd assigns a uuid to each service invocation that derives from kernel > RNG, and it does that super early). So, why run a service that is supposed > to fill up the entropy pool at a point where we don't need it anymore, and > if the kernel can do what it does most likely already on its own? The kernel cannot recover quickly when stressed for continued entropy depletion. For example, we are required to be able to supply all guest VM's with entropy from the host. They draw down the entropy pools which need replenishment. The kernel is constantly starved for entropy. > Isn't it time to kick rngd out of the default install, in particular > on the workstation image? Isn't keeping it around just cargo culting? I think you're being harsh without really looking deeply into the problem. If we could set a sysctl to tell the kernel to use a TPM or increment entropy estimate when RDSEED is used, I'd agree we should consider this. And to be honest, it should be running during an anaconda or kickstart install in order to safely setup an encrypted disk. Also, livecd uses are starved for entropy and must use rngd to be responsive and safe. If you have a TPM, the best use you'll get out of it is providing random numbers via rngd. :-) -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, Apr 17, 2019 at 10:38:18AM +0200, Lennart Poettering wrote: > On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote: > > > > I think all of these are good ideas. "No udev-settle" seems like a nice > > > highlevel goal to shoot for. > > > > > > Another one I might add: "No stuck stop jobs" - it annoys me every single > > > time when I reboot and something like rngd or conmon holds up my reboot > > > for several minutes for no reason at all. > > > > I've seen the rngd stop thing, hadn't had time to investigate it yet as > > more urgent fires keep showing up :/ > > What's the story anyway for rngd? Why would userspace be better at > providing entropy to the kernel than the kernel itself? Why do we > enable it on desktops at all, such systems should not be > entropy-starved. Do we need this at all now that the kernel can use > RDRAND itself? IIUC, RDRAND exists from IvyBridge generation CPUs onwards for Intel or EPYC CPUs for AMD. I've no idea what the story is for non-x86 CPUs & RDRAND equivalent. Anyway, whether we can rely on RDRAND depends on what we consider the minimum targetted CPU models & architectures. I'm guessing that we do intend Fedora to work correctly in CPUs predating/lacking RDRAND. KVM guests can have a virtio-rng device provided on any architecture, which feeds from host's /dev/urandom, but it is unfortunately fairly rare for public cloud providers to enable it :-( rngd includes support for the "jitter entropy" source which uses CPU jitter to feed the RNG. At least in RHEL, this is the recommended option when the CPUs lack RDRAND or equivalent and is why rngd is enabled by default there. IIUC it is reading the jitter entropy from the kernel's crypto APIs, optionally applying AES to data, and then feeding it back into the kernel's rng pool. > rngd runs as regular system service, hence what's the point of that > altogether? I mean, it runs so late during boot, at a point where the > entropy pool is full anyway, and we need the kernel's RNG much much > earlier already (already because systemd assigns a uuid to each > service invocation that derives from kernel RNG, and it does that > super early). So, why run a service that is supposed to fill up the > entropy pool at a point where we don't need it anymore, and if the > kernel can do what it does most likely already on its own? /dev/random can get depleted after boot. Though modern recommendation is for apps to use /dev/urandom by default (or getrandom/getentropy syscalls), some probably still uses /dev/random for historical baggage reasons. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote: > > I think all of these are good ideas. "No udev-settle" seems like a nice > > highlevel goal to shoot for. > > > > Another one I might add: "No stuck stop jobs" - it annoys me every single > > time when I reboot and something like rngd or conmon holds up my reboot > > for several minutes for no reason at all. > > I've seen the rngd stop thing, hadn't had time to investigate it yet as > more urgent fires keep showing up :/ What's the story anyway for rngd? Why would userspace be better at providing entropy to the kernel than the kernel itself? Why do we enable it on desktops at all, such systems should not be entropy-starved. Do we need this at all now that the kernel can use RDRAND itself? rngd runs as regular system service, hence what's the point of that altogether? I mean, it runs so late during boot, at a point where the entropy pool is full anyway, and we need the kernel's RNG much much earlier already (already because systemd assigns a uuid to each service invocation that derives from kernel RNG, and it does that super early). So, why run a service that is supposed to fill up the entropy pool at a point where we don't need it anymore, and if the kernel can do what it does most likely already on its own? Isn't it time to kick rngd out of the default install, in particular on the workstation image? Isn't keeping it around just cargo culting? Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, 2019-04-16 at 11:48 -0400, Matthias Clasen wrote: > On Tue, Apr 9, 2019 at 12:08 PM Lennart Poettering > wrote: > > > Heya, > > > > today I installed the current Fedora 30 Workstation beta on my new > > laptop. It was a bumpy ride, I must say (the partitioner (blivet?) > > crashed five times or so on me, always kicking me out of anaconda > > again, just because I wanted to undo something). But I don't really > > want to discuss that. What I do want to discuss is this: > > > > > > > > Ideally, the top 4 wouldn't be installed at all anymore (in case of > > the first two at least on the systems which do not need them). But if > > that's not in the cards, it would be great to at least not enable > > these services anymore in the default boot so that they are only a > > "systemctl enable" away for people who need them? > > > > > I think all of these are good ideas. "No udev-settle" seems like a nice > highlevel goal to shoot for. > > Another one I might add: "No stuck stop jobs" - it annoys me every single > time when I reboot and something like rngd or conmon holds up my reboot > for several minutes for no reason at all. I've seen the rngd stop thing, hadn't had time to investigate it yet as more urgent fires keep showing up :/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, Apr 9, 2019 at 12:08 PM Lennart Poettering wrote: > Heya, > > today I installed the current Fedora 30 Workstation beta on my new > laptop. It was a bumpy ride, I must say (the partitioner (blivet?) > crashed five times or so on me, always kicking me out of anaconda > again, just because I wanted to undo something). But I don't really > want to discuss that. What I do want to discuss is this: > > > > Ideally, the top 4 wouldn't be installed at all anymore (in case of > the first two at least on the systems which do not need them). But if > that's not in the cards, it would be great to at least not enable > these services anymore in the default boot so that they are only a > "systemctl enable" away for people who need them? > > I think all of these are good ideas. "No udev-settle" seems like a nice highlevel goal to shoot for. Another one I might add: "No stuck stop jobs" - it annoys me every single time when I reboot and something like rngd or conmon holds up my reboot for several minutes for no reason at all. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Sa, 13.04.19 14:03, Steve Grubb (sgr...@redhat.com) wrote: > > If you enable lingering for a user, it's the "systemd --user" instance > > (i.e. the per-user service manager) that is started at boot and > > terminated at shutdown (instead of started at first login and > > terminated at last logout of the user), that's all. > > > > If you then run code as user service (i.e. as a service started and > > managed by the "systemd --user" instance instead of PID 1) then it is > > lifecycled (and its processes killed as needed) by the user service > > manager. And you can configure the way you want killing to behave like > > you would for any systemd service: with KillMode= in the unit file. > > This doesn't really fit with the security requirements we need. > Anything run outside of a user session needs to have an audit session id > and login uid assigned to anything run. It has. As mentioned, systemd --user runs as part of a PAM session, hence it acquire its own session ID and loginuid setting as part of that. > We also need to have the ability to know the name of the script that > is being run in an audit event. To my knowledge audit collects the comm name of any process already, no? Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Fri, 12 Apr 2019 11:21:13 +0200 Lennart Poettering wrote: > On Do, 11.04.19 17:08, Przemek Klosowski (przemek.klosow...@nist.gov) > wrote: > > > > The logic in systemd is more strict on putting boundaries on > > > resource usage, and thus will by default not allow you to consume > > > resources while you are not logged in. It's really how this > > > always should have been designed. However, we fully acknowledge > > > that there are many uses where the ability to run stuff > > > independently of any login as your own user is fine, but you need > > > to turn on lingering for that (which is privileged), so that this > > > is explicitly marked OK. > > > > It IS very useful for systemctl to prevent resource leaks by > > killing errant processes (hanging browser, etc)---however, as we > > discussed, some processes should not be killed; I know which > > processes I want to annoint this way, and I take responsibility for > > their possible misbehavior. > > > > I understand that set-linger disables process harvesting for all > > processes in the session, though, and I would like to just do it > > only for SOME processes. > > If you enable lingering for a user, it's the "systemd --user" instance > (i.e. the per-user service manager) that is started at boot and > terminated at shutdown (instead of started at first login and > terminated at last logout of the user), that's all. > > If you then run code as user service (i.e. as a service started and > managed by the "systemd --user" instance instead of PID 1) then it is > lifecycled (and its processes killed as needed) by the user service > manager. And you can configure the way you want killing to behave like > you would for any systemd service: with KillMode= in the unit file. This doesn't really fit with the security requirements we need. Anything run outside of a user session needs to have an audit session id and login uid assigned to anything run. We also need to have the ability to know the name of the script that is being run in an audit event. -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Fri, 12 Apr 2019 10:01:33 +0200 Dridi Boukelmoune wrote: > > Was this the privileged operation? What privilege does it require? I > > just run the command as a non-admin user and saw no errors or > > prompts for passwords or anything. > > Are you part of the wheel group No, this account does not have wheel. That's what I meant by non-sysadmin acct. > and is wheel configured to be password-less in sudo? Default F29 sudo config. -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Fri, 2019-04-12 at 16:29 +, Akarshan Biswas wrote: > Mlocate too. I am not sure why is this package required but It > tremendously slows down all of my PC(using magnetic disk hard drive). > The first thing I do after installing Fedora Worstation is to remove > it. It only does that *one time*, until it has built its initial database. After that the db is updated regularly when files appear or disappear, and much faster. The benefit is you can then run 'locate' at any time and get a fast response. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
Mlocate too. I am not sure why is this package required but It tremendously slows down all of my PC(using magnetic disk hard drive). The first thing I do after installing Fedora Worstation is to remove it. Regards, Akarshan Biswas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Fri, Apr 12, 2019, at 7:13 AM, Lennart Poettering wrote: > On Fr, 12.04.19 11:35, Dominik 'Rathann' Mierzejewski > (domi...@greysector.net) wrote: > > > > Interestingly I think Google Chrome needs this when it installs, > > > though it seems nonsensical to me. (Chrome is installed by about 50% > > > of our users given some informal stats, so writing it off would be > > > shooting ourselves in the foot.) That's something the Workstation > > > folks may want to work with them to fix in a more systemd-ish way. > > > > Chrome doesn't require atd explicitly (nor is it pulled in by any of its > > dependencies). > > > > It does use it in %post to sneak in a cron job to to add a repo config > > file and its GPG key trust behind your back: > > > > service atd start > > echo "sh /etc/cron.daily/google-chrome" | at now + 2 minute > /dev/null 2>&1 > > > > So, actually not having atd installed won't break Chrome as it will > > just ignore the 'at' command execution error due to 'exit 0' a few > > lines below it. > > Just out of curiosity, why does a web browser need a daily chrome job? Chrome needs a cron job kept in time with chrony of course! I am not 100% certain on this but I am pretty sure it's because of RPM and GPG. librpm stores the keys in the rpmdb, and it's not supported to import the keys during a "transaction". Whereas at least libdnf uses /etc/pki/rpm-gpg and imports the keys before doing anything else; see also https://github.com/rpm-software-management/libdnf/issues/43 But I think Chrome is trying to support multiple librpm-based tools with a single package. The model of "add a repository with GPG key" is not really standardized across rpm-based distributions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Friday, 12 April 2019 at 14:47, Chris Adams wrote: > Once upon a time, Dominik 'Rathann' Mierzejewski > said: > > Chrome doesn't require atd explicitly (nor is it pulled in by any of its > > dependencies). > > That's incorrect. The Google Chrome RPM requires /usr/bin/lsb_release, > which is from redhat-lsb-core, and that requires /usr/bin/at. Ah, you're right. I thought atd is in atd package but it's actually in at and I have that installed, so I didn't see it in the transaction when installing chrome. Sorry, my bad. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
Once upon a time, Dominik 'Rathann' Mierzejewski said: > Chrome doesn't require atd explicitly (nor is it pulled in by any of its > dependencies). That's incorrect. The Google Chrome RPM requires /usr/bin/lsb_release, which is from redhat-lsb-core, and that requires /usr/bin/at. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
Le vendredi 12 avril 2019 à 13:12 +0200, Lennart Poettering a écrit : > On Fr, 12.04.19 11:35, Dominik 'Rathann' Mierzejewski ( > domi...@greysector.net) wrote: > > > > Interestingly I think Google Chrome needs this when it installs, > > > though it seems nonsensical to me. (Chrome is installed by about > > > 50% > > > of our users given some informal stats, so writing it off would > > > be > > > shooting ourselves in the foot.) That's something the Workstation > > > folks may want to work with them to fix in a more systemd-ish > > > way. > > > > Chrome doesn't require atd explicitly (nor is it pulled in by any > > of its > > dependencies). > > > > It does use it in %post to sneak in a cron job to to add a repo > > config > > file and its GPG key trust behind your back: > > > > service atd start > > echo "sh /etc/cron.daily/google-chrome" | at now + 2 minute > > > /dev/null 2>&1 > > > > So, actually not having atd installed won't break Chrome as it will > > just ignore the 'at' command execution error due to 'exit 0' a few > > lines below it. > > Just out of curiosity, why does a web browser need a daily chrome > job? Probably a check-for-updates or download white/black lists thing. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Fri, Apr 12, 2019 at 01:12:51PM +0200, Lennart Poettering wrote: > Just out of curiosity, why does a web browser need a daily chrome job? From the script's comment: # It creates the repository configuration file for package updates, since # we cannot do this during the google-chrome installation since the repository # is locked. # # This functionality can be controlled by creating the $DEFAULTS_FILE and # setting "repo_add_once" to "true" or "false" as desired. An empty # $DEFAULTS_FILE is the same as setting the value to "false". Despite this, the complete script (500+ lines!) seems to be in-line copied to the rpm's post-install script (nearly 1200 lines!) too. I gave up trying to understand everything they do in there years ago. I used to repackage Chrome in earlier days (i.e. make an rpm that extracts the Google binary rpm and builds a new one with pre/post scripts I wrote myself), also because I refused to run Google scripts as root with (in those days, a.o.) lines like "rm -rf $SOMEVAR" in it. But I became lazy and you can use your time only once, so now I decided not to bother anymore. Cheers, -- --Jos Vos --X/OS Experts in Open Systems BV | Office: +31 20 6938364 --Amsterdam, The Netherlands| Mobile: +31 6 26216181 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
* Lennart Poettering: > Just out of curiosity, why does a web browser need a daily chrome job? It uses this to persist itself, so that it is more difficult to remove the Google repository. I guess we can be lucky that it doesn't does this via /etc/ld.so.preload or a kernel module. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Fr, 12.04.19 11:35, Dominik 'Rathann' Mierzejewski (domi...@greysector.net) wrote: > > Interestingly I think Google Chrome needs this when it installs, > > though it seems nonsensical to me. (Chrome is installed by about 50% > > of our users given some informal stats, so writing it off would be > > shooting ourselves in the foot.) That's something the Workstation > > folks may want to work with them to fix in a more systemd-ish way. > > Chrome doesn't require atd explicitly (nor is it pulled in by any of its > dependencies). > > It does use it in %post to sneak in a cron job to to add a repo config > file and its GPG key trust behind your back: > > service atd start > echo "sh /etc/cron.daily/google-chrome" | at now + 2 minute > /dev/null 2>&1 > > So, actually not having atd installed won't break Chrome as it will > just ignore the 'at' command execution error due to 'exit 0' a few > lines below it. Just out of curiosity, why does a web browser need a daily chrome job? Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Thursday, 11 April 2019 at 18:09, Paul Frields wrote: > On Tue, Apr 9, 2019 at 12:07 PM Lennart Poettering > wrote: [...] > [...] > > 3. atd? Do we still need that? Do we have postinst scripts that need > >this? If so, wouldn't systemd-run be a better approach for those? > >Isn't it time to make this an RPM people install if they want it? > > Interestingly I think Google Chrome needs this when it installs, > though it seems nonsensical to me. (Chrome is installed by about 50% > of our users given some informal stats, so writing it off would be > shooting ourselves in the foot.) That's something the Workstation > folks may want to work with them to fix in a more systemd-ish way. Chrome doesn't require atd explicitly (nor is it pulled in by any of its dependencies). It does use it in %post to sneak in a cron job to to add a repo config file and its GPG key trust behind your back: service atd start echo "sh /etc/cron.daily/google-chrome" | at now + 2 minute > /dev/null 2>&1 So, actually not having atd installed won't break Chrome as it will just ignore the 'at' command execution error due to 'exit 0' a few lines below it. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Do, 11.04.19 20:49, Steve Grubb (sgr...@redhat.com) wrote: > > > I run a bunch of background jobs like harvesting podcasts that are > > > released weekly, collecting weather stats for my garden watering > > > system, monitoring my power feed and UPS, collecting ADSB data, > > > etc. I don't think of those as 'system' services, so I run them in > > > my own cron jobs. The system works well because even if my system > > > reboots on a power glitch, or my session crashes, the jobs still > > > run--but in the systemd world it wouldn't work. > > > > Why would't they? If you want to to run your own stuff independent of > > you being logged in then do "loginctl set-linger" on your user and > > it's done. > > Was this the privileged operation? What privilege does it require? I > just run the command as a non-admin user and saw no errors or prompts > for passwords or anything. It uses PolicyKit, like most of the system level services that need to authenticate clients. Hence, not sure what your local configuration of PolicyKit is, but iirc it allows users in "wheel" to do a lot of stuff without password. We require "auth_admin_keep" from pk for the action of enabling lingering. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Do, 11.04.19 17:08, Przemek Klosowski (przemek.klosow...@nist.gov) wrote: > > The logic in systemd is more strict on putting boundaries on resource > > usage, and thus will by default not allow you to consume resources > > while you are not logged in. It's really how this always should have > > been designed. However, we fully acknowledge that there are many uses > > where the ability to run stuff independently of any login as your own > > user is fine, but you need to turn on lingering for that (which is > > privileged), so that this is explicitly marked OK. > > It IS very useful for systemctl to prevent resource leaks by killing errant > processes (hanging browser, etc)---however, as we discussed, some processes > should not be killed; I know which processes I want to annoint this way, and > I take responsibility for their possible misbehavior. > > I understand that set-linger disables process harvesting for all processes > in the session, though, and I would like to just do it only for SOME > processes. If you enable lingering for a user, it's the "systemd --user" instance (i.e. the per-user service manager) that is started at boot and terminated at shutdown (instead of started at first login and terminated at last logout of the user), that's all. If you then run code as user service (i.e. as a service started and managed by the "systemd --user" instance instead of PID 1) then it is lifecycled (and its processes killed as needed) by the user service manager. And you can configure the way you want killing to behave like you would for any systemd service: with KillMode= in the unit file. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
> Was this the privileged operation? What privilege does it require? I > just run the command as a non-admin user and saw no errors or prompts > for passwords or anything. Are you part of the wheel group and is wheel configured to be password-less in sudo? Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/11/2019 8:32 AM, Przemek Klosowski wrote: On 4/11/19 10:16 AM, Lennart Poettering wrote: However, that's intended for system services only (i.e. for services running as users UID < 1000). For regular users (i.e. human ones, those with UID >= 1000), the idea is to install timer units in the per-user instance of the systemd service manager instead. That service manager runs inside a PAM session of the user, and the lifetime is normally bound to the time the user is logged in, meaning that users who are not logged in cannot run stuff. (however, specific users can be marked as "lingering" though a privileged operation and if so their specific service manager is started at boot and stays around until shutdown, so that their timers can run outside of the immediate login time of the user). I think you're saying that systemd is designed on an assumption that such jobs are part of system operation, and will have to run as system/privileged jobs or at least be designated as 'lingering', which you say requires system privilege. I would argue that on my own system (which is a majority of systems now) it should be easy to designate low-privilege jobs as lingering: I should get to decide if it's useful for them to run even if I don't have a current login session. While we're discussing session-tying for cron-esque background automation, it would be nice to have a resolution for https://bugzilla.redhat.com/show_bug.cgi?id=911766 via https://bugzilla.redhat.com/show_bug.cgi?id=995792#c16 It's unfortunate that it still fills up basic syslog with it: https://access.redhat.com/solutions/1564823 -jc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/11/19 1:08 PM, Lennart Poettering wrote: I run a bunch of background jobs like harvesting podcasts that are released weekly, collecting weather stats for my garden watering system, monitoring my power feed and UPS, collecting ADSB data, etc. I don't think of those as 'system' services, so I run them in my own cron jobs. The system works well because even if my system reboots on a power glitch, or my session crashes, the jobs still run--but in the systemd world it wouldn't work. Why would't they? If you want to to run your own stuff independent of you being logged in then do "loginctl set-linger" on your user and it's done. The logic in systemd is more strict on putting boundaries on resource usage, and thus will by default not allow you to consume resources while you are not logged in. It's really how this always should have been designed. However, we fully acknowledge that there are many uses where the ability to run stuff independently of any login as your own user is fine, but you need to turn on lingering for that (which is privileged), so that this is explicitly marked OK. It IS very useful for systemctl to prevent resource leaks by killing errant processes (hanging browser, etc)---however, as we discussed, some processes should not be killed; I know which processes I want to annoint this way, and I take responsibility for their possible misbehavior. I understand that set-linger disables process harvesting for all processes in the session, though, and I would like to just do it only for SOME processes. I guess I could create another user for the persistent jobs and set-linger that session... but it gets complicated. I think it's a better design if I could designate individual processes using my UID as set-linger. I remember talking about remote sessions with long-running jobs, and how the connection timeouts caused by remote clients or network routing prevented their completion. The solution was IIRC running them in tmux/screen. Here also, it'd be nice if I could designate 'my-long-running-service-like-executable' as eligible for lingering. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Thu, 11 Apr 2019 19:08:38 +0200 Lennart Poettering wrote: > On Do, 11.04.19 11:32, Przemek Klosowski (przemek.klosow...@nist.gov) > wrote: > > > On 4/11/19 10:16 AM, Lennart Poettering wrote: > > > However, that's intended for system services only (i.e. for > > > services running as users UID < 1000). For regular users (i.e. > > > human ones, those with UID >= 1000), the idea is to install timer > > > units in the per-user instance of the systemd service manager > > > instead. That service manager runs inside a PAM session of the > > > user, and the lifetime is normally bound to the time the user is > > > logged in, meaning that users who are not logged in cannot run > > > stuff. (however, specific users can be marked as "lingering" > > > though a privileged operation and if so their specific service > > > manager is started at boot and stays around until shutdown, so > > > that their timers can run outside of the immediate login time of > > > the user). > > > > I run a bunch of background jobs like harvesting podcasts that are > > released weekly, collecting weather stats for my garden watering > > system, monitoring my power feed and UPS, collecting ADSB data, > > etc. I don't think of those as 'system' services, so I run them in > > my own cron jobs. The system works well because even if my system > > reboots on a power glitch, or my session crashes, the jobs still > > run--but in the systemd world it wouldn't work. > > Why would't they? If you want to to run your own stuff independent of > you being logged in then do "loginctl set-linger" on your user and > it's done. Was this the privileged operation? What privilege does it require? I just run the command as a non-admin user and saw no errors or prompts for passwords or anything. -Steve > The logic in systemd is more strict on putting boundaries on resource > usage, and thus will by default not allow you to consume resources > while you are not logged in. It's really how this always should have > been designed. However, we fully acknowledge that there are many uses > where the ability to run stuff independently of any login as your own > user is fine, but you need to turn on lingering for that (which is > privileged), so that this is explicitly marked OK. > > But anyway, it's totally fine if you use cron for what you are doing > too, if you are more comfortable with it. It's just a question if cron > needs to be around on the workstation default install. I mean, all the > stuff you list up there, it's not precisely part of the base install > either, you installed a number of packages to make that work, and it > should be fine if crond is one of them, no? > > > I think you're saying that systemd is designed on an assumption > > that such jobs are part of system operation, and will have to run > > as system/privileged jobs or at least be designated as 'lingering', > > which you say requires system privilege. I would argue that on my > > own system (which is a majority of systems now) it should be easy > > to designate low-privilege jobs as lingering: I should get to > > decide if it's useful for them to run even if I don't have a > > current login session. > > Privileges are required to turn on lingering for your user. After that > your user can consume resources on the system from power-on to > power-off without further privileges. > > i.e. it's the act of turning on lingering that requires privs. After > that's done once you don't have to think about that anymore. > > Lennart > > -- > Lennart Poettering, Berlin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Thu, Apr 11, 2019 at 12:48:13PM -0400, Colin Walters wrote: > > > On Tue, Apr 9, 2019, at 12:07 PM, Lennart Poettering wrote: > > Heya, > > > > today I installed the current Fedora 30 Workstation beta on my new > > laptop. It was a bumpy ride, I must say (the partitioner (blivet?) > > crashed five times or so on me, always kicking me out of anaconda > > again, just because I wanted to undo something). But I don't really > > want to discuss that. What I do want to discuss is this: > > > > Can we maybe reduce the default set of packages a bit? > > The dependency chain of libvirtd is just doomed from this perspective. This is a rather sweeping inaccurate statement IMHO. The scale of the dependancies you get from installing libvirt varies significantly depending on which libvirt RPMs you choose to install or depend on. There's quite alot of modularization there if you pick the right sub-RPMs to minimize install footprint. In addition some of the footprint you get when installing libvirt is actually coming from QEMU itself. eg starting from the fedora:30 docker image * "libvirt-daemon-driver-qemu" The bare minimum currently needed by the libvirt QEMU driver impl. 56 RPMs / 100 MB * "libvirt-daemon-kvm" All functionality usable in combination with libvirt and KVM. Also pulls in the qemu-system- to match your host arch. 300 RPMs / 430 MB Of this, 211 RPMs / 300 MB is due to qemu-system-x86 & qemu-img RPMs, rather than libvirt itself. So real libvirt overhead here is only 90 RPMs / 120 MB * "libvirt-daemon-qemu" All functionality usable in combination with libvirt and QEMU (any arch emulation). Pulls in every qemu-system-XXX RPM 350 RPMs / 1 GB (The extra delta here is really coming from QEMU not libvirt itself) The first libvirt-daemon-driver-qemu RPM should in fact be even smaller than it is, but we have an accidental dependancy between two parts of libvirt codebase. This will be addressed in F31. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Do, 11.04.19 11:32, Przemek Klosowski (przemek.klosow...@nist.gov) wrote: > On 4/11/19 10:16 AM, Lennart Poettering wrote: > > However, that's intended for system services only (i.e. for services > > running as users UID < 1000). For regular users (i.e. human ones, > > those with UID >= 1000), the idea is to install timer units in the > > per-user instance of the systemd service manager instead. That service > > manager runs inside a PAM session of the user, and the lifetime is > > normally bound to the time the user is logged in, meaning that users > > who are not logged in cannot run stuff. (however, specific users can > > be marked as "lingering" though a privileged operation and if so > > their specific service manager is started at boot and stays around > > until shutdown, so that their timers can run outside of the immediate > > login time of the user). > > I run a bunch of background jobs like harvesting podcasts that are released > weekly, collecting weather stats for my garden watering system, monitoring > my power feed and UPS, collecting ADSB data, etc. I don't think of those as > 'system' services, so I run them in my own cron jobs. The system works well > because even if my system reboots on a power glitch, or my session crashes, > the jobs still run--but in the systemd world it wouldn't work. Why would't they? If you want to to run your own stuff independent of you being logged in then do "loginctl set-linger" on your user and it's done. The logic in systemd is more strict on putting boundaries on resource usage, and thus will by default not allow you to consume resources while you are not logged in. It's really how this always should have been designed. However, we fully acknowledge that there are many uses where the ability to run stuff independently of any login as your own user is fine, but you need to turn on lingering for that (which is privileged), so that this is explicitly marked OK. But anyway, it's totally fine if you use cron for what you are doing too, if you are more comfortable with it. It's just a question if cron needs to be around on the workstation default install. I mean, all the stuff you list up there, it's not precisely part of the base install either, you installed a number of packages to make that work, and it should be fine if crond is one of them, no? > I think you're saying that systemd is designed on an assumption that such > jobs are part of system operation, and will have to run as > system/privileged jobs or at least be designated as 'lingering', which you > say requires system privilege. I would argue that on my own system (which is > a majority of systems now) it should be easy to designate low-privilege jobs > as lingering: I should get to decide if it's useful for them to run even if > I don't have a current login session. Privileges are required to turn on lingering for your user. After that your user can consume resources on the system from power-on to power-off without further privileges. i.e. it's the act of turning on lingering that requires privs. After that's done once you don't have to think about that anymore. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/11/19 2:12 AM, Vojtěch Trefný wrote: That's actually a bug in libblockdev, only multipath plugin should depend on device-mapper-multipath. Bug opened. https://bugzilla.redhat.com/show_bug.cgi?id=1699071 I can make the spec changes if you need help, but I wanted to document this action in case there is something we're missing. Thanks, michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, Apr 9, 2019, at 12:07 PM, Lennart Poettering wrote: > Heya, > > today I installed the current Fedora 30 Workstation beta on my new > laptop. It was a bumpy ride, I must say (the partitioner (blivet?) > crashed five times or so on me, always kicking me out of anaconda > again, just because I wanted to undo something). But I don't really > want to discuss that. What I do want to discuss is this: > > Can we maybe reduce the default set of packages a bit? The dependency chain of libvirtd is just doomed from this perspective. For Fedora Silverblue (and FCOS) we make the intention decision not to include it by default (though I personally have it package layered). (Using qemu inside a container without libvirt is also a nice pattern, we use this in https://github.com/coreos/coreos-assembler ) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, Apr 9, 2019 at 12:07 PM Lennart Poettering wrote: [...] > Can we maybe reduce the default set of packages a bit? In particular > the following ones I really don't think should be in our default > install: Although somewhat orthogonal to your notes below, overall there's a lot of package-entangling in the basic platform underlying the Workstation as well. This is something we should look at if we're to make progress in CI and Lifecycle objectives -- i.e. being able to produce basic platform for integration more quickly. I was talking to contyk about this the other day and we are starting to throw some ideas around about that. Again, doesn't solve all your individual concerns below but at least related. A good portion of the other subthread is really about choices made and how we enable bits properly for something like Workstation, which is also valid but a different effort I think. [...] > 3. atd? Do we still need that? Do we have postinst scripts that need >this? If so, wouldn't systemd-run be a better approach for those? >Isn't it time to make this an RPM people install if they want it? Interestingly I think Google Chrome needs this when it installs, though it seems nonsensical to me. (Chrome is installed by about 50% of our users given some informal stats, so writing it off would be shooting ourselves in the foot.) That's something the Workstation folks may want to work with them to fix in a more systemd-ish way. -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/11/19 5:32 PM, Przemek Klosowski wrote: I think the Android model is more relevant in this IoT age than the traditional timesharing, 'kick-me-off-when-I-log-out' mode. I would agree and observe that even the timesharing model was never really kick-me-off-when-I-log-out. Processes have an owner (username) and run by themselves. Some effects related to father-child lifecycle are almost accidental (broken pipe and so on) and easily avoided (nohup, screen). The concept of "login" was just associated to how you entered the system (authentication,...), and there was no real concept of "session". The "session" concept mostly came from the graphical interfaces, where many pieces have to collaborate to give the final experience, that started the "session daemons" fashion. Some not-Unix operating system that were almost useless without a login (and without a graphic card) reinforced this idea that "the machine does something only when somebody is logged in". Regards. -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 2019-04-10 at 12:49 +0200, Kamil Paral wrote: > On Tue, Apr 9, 2019 at 8:21 PM Lennart Poettering > wrote: > > > Hmm, but the installed OS is not 100% the same as the livesys, or is > > it? If not, it should be possible to add a "systemctl disable > > dmraid.service --root=/path/to/os" somewhere, no? > > > > AFAIK, they are 100% same. There's a hack, check your > /etc/rc.d/init.d/livesys > /etc/rc.d/init.d/livesys-late > They are executed every time during boot, but immediately quit if they > detect they're not running on a Live image (using kernel command line). You > can see them also here: > https://pagure.io/fedora-kickstarts/blob/f30/f/fedora-live-base.ks#_73 > https://pagure.io/fedora-kickstarts/blob/f30/f/fedora-live-base.ks#_232 That's only part of the story. All the other kickstarts can add bits to the scripts, too (by catting to them). The actual script on any given live image is a combination of the bits from live-base and whatever the other kickstarts involved in building that image do to it. A long time ago I rewrote these as systemd units; the change was rejected... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/11/19 10:16 AM, Lennart Poettering wrote: However, that's intended for system services only (i.e. for services running as users UID < 1000). For regular users (i.e. human ones, those with UID >= 1000), the idea is to install timer units in the per-user instance of the systemd service manager instead. That service manager runs inside a PAM session of the user, and the lifetime is normally bound to the time the user is logged in, meaning that users who are not logged in cannot run stuff. (however, specific users can be marked as "lingering" though a privileged operation and if so their specific service manager is started at boot and stays around until shutdown, so that their timers can run outside of the immediate login time of the user). I run a bunch of background jobs like harvesting podcasts that are released weekly, collecting weather stats for my garden watering system, monitoring my power feed and UPS, collecting ADSB data, etc. I don't think of those as 'system' services, so I run them in my own cron jobs. The system works well because even if my system reboots on a power glitch, or my session crashes, the jobs still run--but in the systemd world it wouldn't work. I'd like the system jobs to be strictly about the OS infrastructure---both for the 'ideological purity' and because it seems to me that it'd be easier to move them to some sort of cloud environment where I don't manage the underlying OS. I think you're saying that systemd is designed on an assumption that such jobs are part of system operation, and will have to run as system/privileged jobs or at least be designated as 'lingering', which you say requires system privilege. I would argue that on my own system (which is a majority of systems now) it should be easy to designate low-privilege jobs as lingering: I should get to decide if it's useful for them to run even if I don't have a current login session. Compare this with Android: the apps can run in background, and it's fine; I implicitly authorized them by owning the device, and installing the app after authenticating to the device and to the app store and maybe to cloud services they depend on. I think the Android model is more relevant in this IoT age than the traditional timesharing, 'kick-me-off-when-I-log-out' mode. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Do, 11.04.19 14:19, Steve Grubb (sgr...@redhat.com) wrote: > > > But what, exactly, has cron fallen short in? > > > > In this case, I was trying to communicate that if systemd, which seems > > to want to replace cron, can't meet all the use cases, we should be > > reporting those that we find in the distro. That lets the systemd > > upstream decide if it is in scope or not and make changes as needed. > > From a security point, we'd want the equivalent of cron.allow, > cron.deny. We'd need the pam stack to run just as it did for cron which > means it needs to be privileged and switch to the user account so that > it can correctly recreate the user environment, optionally do auditing > as needed (just like cronie), and it would need to be MLS (Multi-level > Security) capable. > > If it did all these things, I could see ditching cron. I also have not > looked into the systemd timers to see if or how much of this it > currently does. systemd follows a more restrictive approach there: system services and timers can only be installed by root. If the service uses User= it can run code as a non-root user that way. If the service uses PAMName= this can be done through a PAM session if needed. However, that's intended for system services only (i.e. for services running as users UID < 1000). For regular users (i.e. human ones, those with UID >= 1000), the idea is to install timer units in the per-user instance of the systemd service manager instead. That service manager runs inside a PAM session of the user, and the lifetime is normally bound to the time the user is logged in, meaning that users who are not logged in cannot run stuff. (however, specific users can be marked as "lingering" though a privileged operation and if so their specific service manager is started at boot and stays around until shutdown, so that their timers can run outside of the immediate login time of the user). This model is supposed to be a bit more restrictive security-wise than traditional cron: it's not privileged code that parses and schedules timer expression and then transitions on each dispatching, but it's always the user's own code that is responsible for that. systemd is not a 1:1 replacement for cron, not by a long shot, and it's not supposed to be. It's supposed to be more restrictive and run the scheduler itself with the same privileges of the user it shall run stuff as. There are difference besides lifecycle and security though. For example, it serializes execution of timer-triggered services, and merges trigger events. It never was the intention of to provide the exact same feature set as cron. And I wouldn't push users who want cron to use systemd timers instead. But I'd say the semantics and security model we expose in systemd timers is actually better fitting for the various housekeeping jobs we ship along with our various RPMs. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Thu, Apr 11, 2019 at 03:57:30PM +0200, Lennart Poettering wrote: > On Do, 11.04.19 11:18, Daniel P. Berrangé (berra...@redhat.com) wrote: > > > > I don't know off hand of anything that would prevent it. Libvirt does > > > process events from running qemu VMs, but if there's no API users > > > connected to the daemon then I don't think libvirtd needs to be running; > > > it can handle restart and reconnecting to running VMs. That's > > > essentially the same behavior the session libvirtd instance uses which > > > auto shuts down after 30 seconds if there's no clients IIRC. danpb would > > > know best though, CCd > > > > The reasons systemd libvirtd starts on boot is that it needs to perform > > auto-start of various resources its manages. These resources don't have > > any associated systemd unit so we can't use systemd for this purpose. > > Ideally we would enable libvirtd to create systemd units for the resources > > it manages that need autostart, but that's a significant bit of work. > > So today we can't use systemd activation. > > socket activation doesn't mean you need to start libvirt strictly on > socket traffic. A common pattern is to start both the socket and the > service at boot, but the service exits when idle and then gets > restarted when needed. And that's what I'd like to see here: make > libvirt socket-activatable, but also start it at boot. This would mean > libvirt could start any VMs it wants at boot if they are > configured. And if nothing is configured and nothing has an open IPC > connection it would just exit, knowing that the instance something > wants to talk to it it would be started again. Ok, I see what you mean, enabling both the service & socket by default will probably work. We already have support for systemd activation and auto-exiting, for our non-root instance, so in theory we can just change the unit file setup. Will have to think if there are any other edge cases with this in the root instance though as it has much broader functionality. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Do, 11.04.19 11:18, Daniel P. Berrangé (berra...@redhat.com) wrote: > > I don't know off hand of anything that would prevent it. Libvirt does > > process events from running qemu VMs, but if there's no API users > > connected to the daemon then I don't think libvirtd needs to be running; > > it can handle restart and reconnecting to running VMs. That's > > essentially the same behavior the session libvirtd instance uses which > > auto shuts down after 30 seconds if there's no clients IIRC. danpb would > > know best though, CCd > > The reasons systemd libvirtd starts on boot is that it needs to perform > auto-start of various resources its manages. These resources don't have > any associated systemd unit so we can't use systemd for this purpose. > Ideally we would enable libvirtd to create systemd units for the resources > it manages that need autostart, but that's a significant bit of work. > So today we can't use systemd activation. socket activation doesn't mean you need to start libvirt strictly on socket traffic. A common pattern is to start both the socket and the service at boot, but the service exits when idle and then gets restarted when needed. And that's what I'd like to see here: make libvirt socket-activatable, but also start it at boot. This would mean libvirt could start any VMs it wants at boot if they are configured. And if nothing is configured and nothing has an open IPC connection it would just exit, knowing that the instance something wants to talk to it it would be started again. Or to say this differently: you can combine activation methods nicely and it's common to do so: activation-on-boot + activation-on-timer + activation-on-socket + activation-on-hardware + activation-on-anything-else can be nicely done for the same service. Or to say this even differently: service activation in systemd is substantially more powerful than in inetd: it's not exclusively about *on-demand* socket activation, but socket activation is just one form that can neatly be composed with every other trigger you like. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
I'd say that backward compatibility is important and as a Fedora workstation and server user I expect crond to work OOTB. Yes, users can install and enable the service if needed but cron is such an essential part of every system that I see no reason to exclude it. On 4/11/19 6:30 AM, Brian (bex) Exelbierd wrote: > My interest, and the way I read the OP was not about minimal size, > directly. In this case, it sounds like we have adopted a tool, > systemd, that replaces another tool, cron. We can debate the > completeness of the replacement, etc, but it is also valid to question > why we ship both as default installed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Thu, 11 Apr 2019 12:30:11 +0200 "Brian (bex) Exelbierd" wrote: > To: Japheth Cleaver > CC: Development discussions related to Fedora > Subject: Re: Can we maybe reduce the > set of packages we install by default a bit? Date: Thu, 11 Apr 2019 > 12:30:11 +0200 Reply-To: Development discussions related to Fedora > > > On Wed, Apr 10, 2019 at 8:54 PM Japheth Cleaver > wrote: > > > > Reducing the Minimal size is, in general, good, but it's possible > > to go too far, and I think that's the case with low-level, *nix > > wide tools like this. I'm reminded of the time someone thought tar > > needed to go too: > > https://bugzilla.redhat.com/show_bug.cgi?id=1409920 > > My interest, and the way I read the OP was not about minimal size, > directly. In this case, it sounds like we have adopted a tool, > systemd, that replaces another tool, cron. We can debate the > completeness of the replacement, etc, but it is also valid to question > why we ship both as default installed. > > Extending this, tar is a reasonable thing to install on all systems > today. That might not be true tomorrow. I encourage Fedora to be > willing to explore these questions and make opinionated decisions. > > > > > > Lastly, taking a position on some of this, for example, removing > > > cron, is a form of opinionation that calls back to our roots of > > > innovating in the OS space. We would be saying, we recognize > > > this is the way we did things X years ago, but there are new ways > > > and processes and we see value in those. If we can't remove > > > these things, then we are being a good distribution by pointing > > > out where solutions that claim to fix something have fallen short > > > so that those upstreams can make decisions about what to do. > > > > But what, exactly, has cron fallen short in? > > In this case, I was trying to communicate that if systemd, which seems > to want to replace cron, can't meet all the use cases, we should be > reporting those that we find in the distro. That lets the systemd > upstream decide if it is in scope or not and make changes as needed. From a security point, we'd want the equivalent of cron.allow, cron.deny. We'd need the pam stack to run just as it did for cron which means it needs to be privileged and switch to the user account so that it can correctly recreate the user environment, optionally do auditing as needed (just like cronie), and it would need to be MLS (Multi-level Security) capable. If it did all these things, I could see ditching cron. I also have not looked into the systemd timers to see if or how much of this it currently does. -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, Apr 10, 2019 at 8:54 PM Japheth Cleaver wrote: > > Reducing the Minimal size is, in general, good, but it's possible to go > too far, and I think that's the case with low-level, *nix wide tools > like this. I'm reminded of the time someone thought tar needed to go > too: https://bugzilla.redhat.com/show_bug.cgi?id=1409920 My interest, and the way I read the OP was not about minimal size, directly. In this case, it sounds like we have adopted a tool, systemd, that replaces another tool, cron. We can debate the completeness of the replacement, etc, but it is also valid to question why we ship both as default installed. Extending this, tar is a reasonable thing to install on all systems today. That might not be true tomorrow. I encourage Fedora to be willing to explore these questions and make opinionated decisions. > > > Lastly, taking a position on some of this, for example, removing cron, > > is a form of opinionation that calls back to our roots of innovating > > in the OS space. We would be saying, we recognize this is the way we > > did things X years ago, but there are new ways and processes and we > > see value in those. If we can't remove these things, then we are > > being a good distribution by pointing out where solutions that claim > > to fix something have fallen short so that those upstreams can make > > decisions about what to do. > > But what, exactly, has cron fallen short in? In this case, I was trying to communicate that if systemd, which seems to want to replace cron, can't meet all the use cases, we should be reporting those that we find in the distro. That lets the systemd upstream decide if it is in scope or not and make changes as needed. I was not suggesting cron had a short fall. > >> The last thing I'd want to have to deal with is solving for a missing > >> /etc/cron.* because someone forgot to click a checkbox somewhere or > >> didn't call it out in kickstart. > > Yes, but I also don't want to deal with a security fix in cron when I > > didn't want it to begin with. Adding software the user doesn't want > > to have it as assumed for other users is always a trade-off. > > True, but - as written elsewhere - that can be taken to a logical > extreme, both via removal of simple, auditable utilities and shell > scripts, and eventual giant replacements. I don't consider the evolution of replacements to be inherently bad. They may not meet your use case, but they may meet the use case of the Fedora Workstation core target audience. If we build a workstation that tries to be all things for all people, it is often not great for everyone. I am advocating that we tighten our scope for our deliverables and allow for differentation in them instead of trying to be all things for all people. regards, bex -- Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, Apr 09, 2019 at 02:55:51PM -0400, Cole Robinson wrote: > On 4/9/19 2:24 PM, Lennart Poettering wrote: > > On Di, 09.04.19 14:16, Cole Robinson (crobi...@redhat.com) wrote: > > > >> On 4/9/19 1:09 PM, Zbigniew Jędrzejewski-Szmek wrote: > >>> On Tue, Apr 09, 2019 at 06:07:09PM +0200, Lennart Poettering wrote: > multipathd [...] And beyond that, this daemon is really ugly too: it logs > at high log levels during boot that it found no configuration and > hence nothing to do. Yes, obviously, but that's a reason to shut up > and proceed quickly, not to complain loudly about that so that it > even appears on the scren (I mean srsly, this is the first thing I > saw when i booted from the fedora live media: a log message printed > all over the screen that multipathd has no working > configuration...). > >>> > >>> This was supposed to be fixed > >>> https://bugzilla.redhat.com/show_bug.cgi?id=1631772. > >>> If not, please reopen that bug. > >>> > 5. libvirtd. Why is this running? Can't we make this socket > activatable + exit-on-idel? > >>> > >>> This was supposed to happen. See > >>> https://bugzilla.redhat.com/show_bug.cgi?id=1290357. > >>> > >> > >> This bug (briefly) describes why at present libvirt can't use socket > >> activation: https://bugzilla.redhat.com/show_bug.cgi?id=1326136 > > > > Hmm, so that is a valid request I guess. But why can't libvirt do > > exit-on-idle? i.e. after it started up, after it noticed that it has no VMs > > to > > run, checks that there are no IPC requests pending, can't it just exit > > then and then rely on socket activation to be started again when it is > > needed the next time? That way libvirt would start at boot, but not > > stick around during normal runtime. > > > > I don't know off hand of anything that would prevent it. Libvirt does > process events from running qemu VMs, but if there's no API users > connected to the daemon then I don't think libvirtd needs to be running; > it can handle restart and reconnecting to running VMs. That's > essentially the same behavior the session libvirtd instance uses which > auto shuts down after 30 seconds if there's no clients IIRC. danpb would > know best though, CCd The reasons systemd libvirtd starts on boot is that it needs to perform auto-start of various resources its manages. These resources don't have any associated systemd unit so we can't use systemd for this purpose. Ideally we would enable libvirtd to create systemd units for the resources it manages that need autostart, but that's a significant bit of work. So today we can't use systemd activation. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/10/19 11:57 AM, Kamil Paral wrote: > On Wed, Apr 10, 2019 at 2:35 AM Chris Murphy > wrote: > >>> 1. multipathd. >> >> I'm pretty sure it gets dragged in by the installer > > > Nope, multipath seems to be present because libblockdev and udisks (and > perhaps some more), which is in turn required by GNOME: > > $ rpm -q --whatrequires device-mapper-multipath > libblockdev-fs-2.21-2.fc30.x86_64 > libblockdev-part-2.21-2.fc30.x86_64 That's actually a bug in libblockdev, only multipath plugin should depend on device-mapper-multipath. > libblockdev-mpath-2.21-2.fc30.x86_64 > fcoe-utils-1.0.32-6.fc29.x86_64 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/10/2019 4:10 AM, Brian (bex) Exelbierd wrote: On Tue, Apr 9, 2019 at 8:40 PM Japheth Cleaver wrote: Is this really worth the effort? cronie in F30 is a 103K package, and a decent chunk of that might be the ChangeLog. crontabs is all of 18K, which is 95% the GPL and the RPM header. It seems like a very small price to pay for something everyone is going to assume will be on any *nix-compatible system of note. I read, possibly misread, the original comment as being about the number of "unneeded" things in the install, not necessarily the weight of the specific packages. What I think we are hearing from containers, OSTree, etc. is that there is a group of people that wants their systems more minimal with less unnecessary stuff. *snip* This seems to go back to who is the primary target audience for our Workstation edition and what do they want/expect. Then we can document the changes and socialize them over a few releases so that other users can get to where they want to be. Basically "extra" isn't what no one wants, its what our defined target doesn't want/expect. Although this was originally posted about Workstation, I can virtually guarantee that a solution accepted for implementation would not be "Remove cron in %post," thus this really comes about as removing it as a default install pretty much everywhere. Of course, things like OSTree/atomic, containers, and micro-environments where every byte counts are likely to be bypassing typical installation mechanisms regardless to fine-tune what's delivered -- eg, removing documentation, etc in docker kickstart %post, or re-implementing parts of RPM to begin with. Reducing the Minimal size is, in general, good, but it's possible to go too far, and I think that's the case with low-level, *nix wide tools like this. I'm reminded of the time someone thought tar needed to go too: https://bugzilla.redhat.com/show_bug.cgi?id=1409920 One might make the case for a removal from @core -- *maybe* -- but definitely not @base. Lastly, taking a position on some of this, for example, removing cron, is a form of opinionation that calls back to our roots of innovating in the OS space. We would be saying, we recognize this is the way we did things X years ago, but there are new ways and processes and we see value in those. If we can't remove these things, then we are being a good distribution by pointing out where solutions that claim to fix something have fallen short so that those upstreams can make decisions about what to do. But what, exactly, has cron fallen short in? I'm reminded of that old testimonial tag line for the similarly named, but unrelated, utility cronolog: "cronolog kicks ass in every conceivable way in which a utility like cronolog can kick ass." ( http://web.archive.org/web/20090627031834/http://cronolog.org/ ) There are other launching mechanisms, sure... I've worked on one of them, but that doesn't mean there's anything wrong with cron, or /etc/cron.*/ directories. More directly, I'm old enough to remember when we were assured that systemd's timers were not "to be in competition here" with cron, and and it was promised to "make sure that cron is advertised as a good solution for people who just want to queue a simple cronjob." With all the discussion of ease-of-use and discoverability, removing the "good solution" mechanism for users in favor of something requiring a package install doesn't seem to be a great example of that. https://lists.fedoraproject.org/pipermail/devel/2014-March/196293.html The last thing I'd want to have to deal with is solving for a missing /etc/cron.* because someone forgot to click a checkbox somewhere or didn't call it out in kickstart. Yes, but I also don't want to deal with a security fix in cron when I didn't want it to begin with. Adding software the user doesn't want to have it as assumed for other users is always a trade-off. True, but - as written elsewhere - that can be taken to a logical extreme, both via removal of simple, auditable utilities and shell scripts, and eventual giant replacements. -jc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, Apr 10, 2019 at 3:22 PM Michael Watters wrote: > > You mean like systemd? ;) Given the origin of this thread, I tried not to go there. However, now that you've broached it, yes. This :D. systemd is a lot of things, but it also is the way forward we think that our audience wants. It has the adoption that shows that leaving it out is bad, and in this specific cron example, not using its full feature set is probably bad for our users and is poor of us as a distro. The more interesting set of cases is what our users want/need to be successful. For example, if we are targetting developers, should we work on replacing some tools like `cat` with `bat` as it is code aware. This would be a HUGE undertaking, potentially, but could potentially create an ease of use and experience that shows we understand our market. regards, bex > > On 4/10/19 7:10 AM, Brian (bex) Exelbierd wrote: > > Adding software the user doesn't want > > to have it as assumed for other users is always a trade-off. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
You mean like systemd? ;) On 4/10/19 7:10 AM, Brian (bex) Exelbierd wrote: > Adding software the user doesn't want > to have it as assumed for other users is always a trade-off. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, 2019-04-09 at 14:20 -0400, Neal Gompa wrote: > On Tue, Apr 9, 2019 at 1:11 PM Adam Williamson > wrote: > > On Tue, 2019-04-09 at 12:54 -0400, Stephen John Smoogen wrote: > > > On Tue, 9 Apr 2019 at 12:07, Lennart Poettering > > > wrote: > > > > > > > Heya, > > > > > > > > today I installed the current Fedora 30 Workstation beta on my new > > > > laptop. It was a bumpy ride, I must say (the partitioner (blivet?) > > > > crashed five times or so on me, always kicking me out of anaconda > > > > again, just because I wanted to undo something). But I don't really > > > > want to discuss that. What I do want to discuss is this: > > > > > > > > Can we maybe reduce the default set of packages a bit? In particular > > > > the following ones I really don't think should be in our default > > > > install: > > > > > > > > > > > This is not the first time this has come up and I expect it won't be the > > > last time. > > > > > > I think the main reason they stick around is that the people who want them > > > gone just show up right after a release, drop a bunch of requests, and > > > then > > > go off to their own busy work. Then they come back a release later, don't > > > see any change and either drop another email detailing things to be > > > dropped > > > OR discouraged that no-one ever listens. The things that do get changed > > > and > > > pulled out (or kept in) do so because people come in and work on scrubbing > > > out the reasons and making sure the replacements are socialized in. > > > > > > One of the things is that I am not sure any of these items > > > > > > > > > 1. multipathd. On a workstation, uh?? I obviously have no multipath > > > > > > 2. dmraid. Not quite as bad as multipathd as it is more likely to > > > > > > I think these two are here because of the blivet you mentioned earlier. > > > Advanced partitioning requires them to be there... and there do seem to be > > > people who actually do expect both of those to work on their workstations > > > when it was looked at to be removed in the past. > > > > > > I do not know if the SIlverBlue does not have them on the other hand. > > > > Basically, anything that's part of the install environment is going to > > be present after a live install. That accounts for both of the above: > > the installer supports multipath and dmraid storage devices, so the > > relevant packages are part of the install environment, so they're part > > of the lives, so they're installed by a live install. > > > > This is kind of a limitation of the live deployment mechanism. In > > theory a post-install stage could be added to strip things that were > > only needed at install time, or that we can tell aren't actually needed > > by the installed system, but this has never been done, though I recall > > it being discussed at times. > > > > I'd personally like to see some kind of post-install mechanism that > could remove unneeded things This is on the technical level doable as long as: - RPM & DNF tooling on the image works - you are only removing stuff - the "recipe" what to remove needs to be maintained somewhere and kept current > or apply updates before rebooting into > the new environment. This on the other hand is a bit harder four a couple reasons: - the current live installation does not need networking and this network is (IIRC) generally not setup, so you would need to make sure network is available at the time you attempt to do this - unlike the live image that is always the same and passes quite some testing (both automated and manual) before it is declared fit for GA, update repos can change more or less at random, creating a miriad of combinations with the live image package set, some of them potentially wrong (file conflicts, broken deps, failing scriptlets) - any errors due to updates might be harder to debug in the live environment than on installed system - note that thisa is not the same as netins as you would be always taking a frozen package set and then aplying a bunch of ever changing updates on top of it VS installing a full system from latest packages on netinst - while making the system up to date (and potentially more secure) this could make the live installation run quite a bit longer & taking ever longer the older the live image is (current live image just rsyncs the base filesystem content to the target, no need to run all the scriptlets and rpm machinery) > That's something that Ubiquity, DrakX, Calamares, > and YaST all do, and it's quite nice to have... It's all possible in principle, but both remove & update is: - extra code not useed on netinst that needs to be written, maintained & QAed - will this be the same for all lives or different per spins vs workstation - do the SIGs taking care of the Workstation live and other live spins actually want this ? > > > > > 3. atd? Do we still need that? Do we have postinst scripts that need > > > > > > 4. Similar crond. On my fresh install
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 10.04.19 08:16, Julen Landa Alustiza (ju...@zokormazo.info) wrote: > I'm really interested on the livet crash, but I can't reproduce it with > latest branched compose. > Can you provide us with reproduction steps? Urks, I don't remember. I think created an ESP part, two ext4 partitions, one encrypted swap and one encrypted btrfs or so, and then changed my mind and flushed it all out with that button in the lower right, and then it died on me. And then I did the same twice again it it died again. But sorry, I didn't record the errors, it wasn't particularly special though... Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Di, 09.04.19 18:34, Chris Murphy (li...@colorremedies.com) wrote: > > Ideally, the top 4 wouldn't be installed at all anymore (in case of > > the first two at least on the systems which do not need them). But if > > that's not in the cards, it would be great to at least not enable > > these services anymore in the default boot so that they are only a > > "systemctl enable" away for people who need them? > > At the least it seems reasonable they can be disabled on the installed > system, and enabled for Live OS boot if the installer needs them. I mean, it could be as easy that these services remain off, but the installer does a "systemctl enable --now …" on them as soon as it notices it needs them. That way the livesys and the host installed version can be 100% identical, if that's what people want. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 10.04.19 12:49, Kamil Paral (kpa...@redhat.com) wrote: > > Hmm, but the installed OS is not 100% the same as the livesys, or is > > it? If not, it should be possible to add a "systemctl disable > > dmraid.service --root=/path/to/os" somewhere, no? > > AFAIK, they are 100% same. There's a hack, check your > /etc/rc.d/init.d/livesys > /etc/rc.d/init.d/livesys-late > They are executed every time during boot, but immediately quit if they > detect they're not running on a Live image (using kernel command line). You > can see them also here: > https://pagure.io/fedora-kickstarts/blob/f30/f/fedora-live-base.ks#_73 > https://pagure.io/fedora-kickstarts/blob/f30/f/fedora-live-base.ks#_232 > They are ugly, I think, and many improvements could be made there. But some > Live image adjustments are possible through them. But those are just > runtime changes for Live environment, they don't affect the installed > system. If anaconda had a post-install phase where it would make > appropriate changes to the installed system (and also ideally removed > itself and those livesys scripts), that would be great, yes. Those scripts, can't we make them part of some RPM btw? I filed a bug about that yesterday: https://bugzilla.redhat.com/show_bug.cgi?id=1698119 These scripts are a bit annoying since they are the only SysV scripts left really (not even LSB!), have no purposes on an installed system and live outside of any RPM ownership and validation. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, Apr 9, 2019 at 8:40 PM Japheth Cleaver wrote: > Is this really worth the effort? cronie in F30 is a 103K package, and a > decent chunk of that might be the ChangeLog. crontabs is all of 18K, > which is 95% the GPL and the RPM header. It seems like a very small > price to pay for something everyone is going to assume will be on any > *nix-compatible system of note. I read, possibly misread, the original comment as being about the number of "unneeded" things in the install, not necessarily the weight of the specific packages. What I think we are hearing from containers, OSTree, etc. is that there is a group of people that wants their systems more minimal with less unnecessary stuff. Some of this is about resource-sizing (RAM, Disk, etc.), some is about update and security footprints, and some of it is about "psychic weight." I realize that we have to make these tradeoffs in some cases, for example, aiui, gnome-keyring is not able to be removed and still have a functional Gnome environment. But this isn't universally the case. This seems to go back to who is the primary target audience for our Workstation edition and what do they want/expect. Then we can document the changes and socialize them over a few releases so that other users can get to where they want to be. Basically "extra" isn't what no one wants, its what our defined target doesn't want/expect. I don't expect the tools I use to always be installed by default and I don't think anyone else on the list does either. It also speaks to our spins/labs as ways to take our existing software and reformulate the install to meet different users' needs. Lastly, taking a position on some of this, for example, removing cron, is a form of opinionation that calls back to our roots of innovating in the OS space. We would be saying, we recognize this is the way we did things X years ago, but there are new ways and processes and we see value in those. If we can't remove these things, then we are being a good distribution by pointing out where solutions that claim to fix something have fallen short so that those upstreams can make decisions about what to do. > The last thing I'd want to have to deal with is solving for a missing > /etc/cron.* because someone forgot to click a checkbox somewhere or > didn't call it out in kickstart. Yes, but I also don't want to deal with a security fix in cron when I didn't want it to begin with. Adding software the user doesn't want to have it as assumed for other users is always a trade-off. regards, bex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, Apr 9, 2019 at 8:21 PM Lennart Poettering wrote: > Hmm, but the installed OS is not 100% the same as the livesys, or is > it? If not, it should be possible to add a "systemctl disable > dmraid.service --root=/path/to/os" somewhere, no? > AFAIK, they are 100% same. There's a hack, check your /etc/rc.d/init.d/livesys /etc/rc.d/init.d/livesys-late They are executed every time during boot, but immediately quit if they detect they're not running on a Live image (using kernel command line). You can see them also here: https://pagure.io/fedora-kickstarts/blob/f30/f/fedora-live-base.ks#_73 https://pagure.io/fedora-kickstarts/blob/f30/f/fedora-live-base.ks#_232 They are ugly, I think, and many improvements could be made there. But some Live image adjustments are possible through them. But those are just runtime changes for Live environment, they don't affect the installed system. If anaconda had a post-install phase where it would make appropriate changes to the installed system (and also ideally removed itself and those livesys scripts), that would be great, yes. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, Apr 10, 2019 at 2:35 AM Chris Murphy wrote: > > 1. multipathd. > > I'm pretty sure it gets dragged in by the installer Nope, multipath seems to be present because libblockdev and udisks (and perhaps some more), which is in turn required by GNOME: $ rpm -q --whatrequires device-mapper-multipath libblockdev-fs-2.21-2.fc30.x86_64 libblockdev-part-2.21-2.fc30.x86_64 libblockdev-mpath-2.21-2.fc30.x86_64 fcoe-utils-1.0.32-6.fc29.x86_64 $ rpm -q --whatrequires libblockdev-fs udisks2-2.8.2-1.fc30.x86_64 $ rpm -q --whatrequires udisks2 gvfs-1.40.0-1.fc30.x86_64 gnome-disk-utility-3.32.0-1.fc30.x86_64 That was latest F30 Workstation Live. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
Le mardi 09 avril 2019 à 10:11 -0700, Adam Williamson a écrit : > > To be specific here, 'at' is part of the @standard group. 'chrony' is > pulled in several ways. It's part of @standard *if gnome-control- > center > is being installed*, so effectively it'll be installed with > Workstation > but not other editions/spins. That sort of implies that there's some > functionality in GNOME that depends on chrony; chrony, mdadm and dmraid are all necessary parts of a workstation setup. The first one because some virtualisation systems (windows 10 Hyper-V for example) are braindamaged and will wake up VMs (including GNOME VMs) with a system clock stuck at the time the VM was frozen. So you better have a clock-skewing ntp client running in all your vms. chrony is the best existing one right now IIRC (kuddo to chrony devs, they passed their security audits with style) The others because raid does exist on workstations, and the dmraid guys never got around to finish replicating all the mdadm functionnalities (pretty much like networkd stopped at integrating bonding, and never bothered to do teaming, for example). chrond, at, udev settle… that's all lack or good proeminent systemd documentation, that causes third party projects to kludge, and gave up on things they do not understand. -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
I'm really interested on the livet crash, but I can't reproduce it with latest branched compose. Can you provide us with reproduction steps? Hau idatzi du Neal Gompa (ngomp...@gmail.com) erabiltzaileak (2019 api. 10, az. (02:59)): > On Tue, Apr 9, 2019 at 8:35 PM Chris Murphy > wrote: > > > > On Tue, Apr 9, 2019 at 10:07 AM Lennart Poettering > wrote: > > > > > > Heya, > > > > > > today I installed the current Fedora 30 Workstation beta on my new > > > laptop. It was a bumpy ride, I must say (the partitioner (blivet?) > > > crashed five times or so on me, always kicking me out of anaconda > > > again, just because I wanted to undo something). > > > > I haven't seen a single one come across in QA > > > > > 1. multipathd. > > > > I'm pretty sure it gets dragged in by the installer, i.e. the > > installation environment needs it because installing to multipath is > > supported. And since it's on the Workstation LiveOS, it just gets > > copied over along with the installer itself (LiveOS installs use > > rsync). I wonder if it's reasonable to apply more exclude filtering > > during rsync to avoid copying some things needed for Live OS > > environment, but not on the final installed system. But that's sorta > > up to Workstation WG I think. > > > > Not having the rpmdb in sync with what content is on the system is > probably not a good idea. I'd advocate for anaconda being able to run > dnf to clean up stuff instead. > > > > > > 2. dmraid. > > > > Same as above. I'm not sure whether, or when, dmraid stuff is going to > > be dropped by anaconda. For a long time now dmraid is deprecated. The > > two supported ways of doing software raid are managed by mdadm and > > lvm, both of which actually use the md driver in the kernel. > > > > So I think this is a question for the anaconda team. > > > > > > > 4. Similar crond. On my fresh install it's only used by "zfs-fuse", > > >which I really wonder why it even is in the default install? And > > >"mdadm" wants this too. (which would be great if it would just use > > >timer units) > > > > I think zfs-fuse and glusterfs are dragged in by libvirt, which is > > present because of GNOME Boxes. I don't know why any of those want > > crond. > > > > These could be converted to systemd units. There's no reason not to, > really... > > > mdadm scrub and monitoring depends on crond, and then email > > notifications if mismatch count != 0; it's archaic these days I guess, > > but that's how it works. > > > > > > > 5. libvirtd. Why is this running? Can't we make this socket > > >activatable + exit-on-idel? While I am sure it's useful on > > >workstations why run it all the time, given that only very few > > >users probably actually need that, and if they do starting it on > > >demand would be much more appropriate? On my freshly installed > > >system it is running all the time even though there are no VMs or > > >anything around. > > > > Agreed. > > > > > > > > > > Ideally, the top 4 wouldn't be installed at all anymore (in case of > > > the first two at least on the systems which do not need them). But if > > > that's not in the cards, it would be great to at least not enable > > > these services anymore in the default boot so that they are only a > > > "systemctl enable" away for people who need them? > > > > At the least it seems reasonable they can be disabled on the installed > > system, and enabled for Live OS boot if the installer needs them. > > > > -- > > Chris Murphy > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Julen Landa Alustiza ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, Apr 9, 2019 at 8:35 PM Chris Murphy wrote: > > On Tue, Apr 9, 2019 at 10:07 AM Lennart Poettering > wrote: > > > > Heya, > > > > today I installed the current Fedora 30 Workstation beta on my new > > laptop. It was a bumpy ride, I must say (the partitioner (blivet?) > > crashed five times or so on me, always kicking me out of anaconda > > again, just because I wanted to undo something). > > I haven't seen a single one come across in QA > > > 1. multipathd. > > I'm pretty sure it gets dragged in by the installer, i.e. the > installation environment needs it because installing to multipath is > supported. And since it's on the Workstation LiveOS, it just gets > copied over along with the installer itself (LiveOS installs use > rsync). I wonder if it's reasonable to apply more exclude filtering > during rsync to avoid copying some things needed for Live OS > environment, but not on the final installed system. But that's sorta > up to Workstation WG I think. > Not having the rpmdb in sync with what content is on the system is probably not a good idea. I'd advocate for anaconda being able to run dnf to clean up stuff instead. > > > 2. dmraid. > > Same as above. I'm not sure whether, or when, dmraid stuff is going to > be dropped by anaconda. For a long time now dmraid is deprecated. The > two supported ways of doing software raid are managed by mdadm and > lvm, both of which actually use the md driver in the kernel. > > So I think this is a question for the anaconda team. > > > > 4. Similar crond. On my fresh install it's only used by "zfs-fuse", > >which I really wonder why it even is in the default install? And > >"mdadm" wants this too. (which would be great if it would just use > >timer units) > > I think zfs-fuse and glusterfs are dragged in by libvirt, which is > present because of GNOME Boxes. I don't know why any of those want > crond. > These could be converted to systemd units. There's no reason not to, really... > mdadm scrub and monitoring depends on crond, and then email > notifications if mismatch count != 0; it's archaic these days I guess, > but that's how it works. > > > > 5. libvirtd. Why is this running? Can't we make this socket > >activatable + exit-on-idel? While I am sure it's useful on > >workstations why run it all the time, given that only very few > >users probably actually need that, and if they do starting it on > >demand would be much more appropriate? On my freshly installed > >system it is running all the time even though there are no VMs or > >anything around. > > Agreed. > > > > > > Ideally, the top 4 wouldn't be installed at all anymore (in case of > > the first two at least on the systems which do not need them). But if > > that's not in the cards, it would be great to at least not enable > > these services anymore in the default boot so that they are only a > > "systemctl enable" away for people who need them? > > At the least it seems reasonable they can be disabled on the installed > system, and enabled for Live OS boot if the installer needs them. > > -- > Chris Murphy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, Apr 9, 2019 at 10:07 AM Lennart Poettering wrote: > > Heya, > > today I installed the current Fedora 30 Workstation beta on my new > laptop. It was a bumpy ride, I must say (the partitioner (blivet?) > crashed five times or so on me, always kicking me out of anaconda > again, just because I wanted to undo something). I haven't seen a single one come across in QA > 1. multipathd. I'm pretty sure it gets dragged in by the installer, i.e. the installation environment needs it because installing to multipath is supported. And since it's on the Workstation LiveOS, it just gets copied over along with the installer itself (LiveOS installs use rsync). I wonder if it's reasonable to apply more exclude filtering during rsync to avoid copying some things needed for Live OS environment, but not on the final installed system. But that's sorta up to Workstation WG I think. > 2. dmraid. Same as above. I'm not sure whether, or when, dmraid stuff is going to be dropped by anaconda. For a long time now dmraid is deprecated. The two supported ways of doing software raid are managed by mdadm and lvm, both of which actually use the md driver in the kernel. So I think this is a question for the anaconda team. > 4. Similar crond. On my fresh install it's only used by "zfs-fuse", >which I really wonder why it even is in the default install? And >"mdadm" wants this too. (which would be great if it would just use >timer units) I think zfs-fuse and glusterfs are dragged in by libvirt, which is present because of GNOME Boxes. I don't know why any of those want crond. mdadm scrub and monitoring depends on crond, and then email notifications if mismatch count != 0; it's archaic these days I guess, but that's how it works. > 5. libvirtd. Why is this running? Can't we make this socket >activatable + exit-on-idel? While I am sure it's useful on >workstations why run it all the time, given that only very few >users probably actually need that, and if they do starting it on >demand would be much more appropriate? On my freshly installed >system it is running all the time even though there are no VMs or >anything around. Agreed. > > Ideally, the top 4 wouldn't be installed at all anymore (in case of > the first two at least on the systems which do not need them). But if > that's not in the cards, it would be great to at least not enable > these services anymore in the default boot so that they are only a > "systemctl enable" away for people who need them? At the least it seems reasonable they can be disabled on the installed system, and enabled for Live OS boot if the installer needs them. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, Apr 9, 2019 at 12:11 PM, Adam Williamson wrote: To be specific here, 'at' is part of the @standard group. 'chrony' is pulled in several ways. It's part of @standard *if gnome-control-center is being installed*, so effectively it'll be installed with Workstation but not other editions/spins. Note that Workstation doesn't include @standard at all. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/9/19 2:14 PM, Lennart Poettering wrote: > On Di, 09.04.19 12:54, Stephen John Smoogen (smo...@gmail.com) wrote: > >> I think these two are here because of the blivet you mentioned earlier. >> Advanced partitioning requires them to be there... and there do seem to be >> people who actually do expect both of those to work on their workstations >> when it was looked at to be removed in the past. > > Well, but anaconda makes some changes to the image after copying in > the OS, no? it could also do an "systemctl disable mdraid.service > --root=/installed/tree" or so if it knows that mdraid is not actually > needed... The general argument against doing things like that in anaconda is that it will change later and this email thread becomes "Why is anaconda running systemctl disable mdraid.service after installing the OS" >> This is more about socializing and teaching the systemd replacements... >> because most of the systemd advocates and heavy users I have asked aren't >> sure about how systemd replaces them and go back to cron/atd. I actually >> think that the replacements seem much better thought out than cruft-ware >> but.. but I also have little confidence I could get it to work consistently >> while I can find 10k tutorials on cron. > > Well, we addresses similar cases by placing README files or so in > those directories, so that people might notice if they are looking for > something there... i.e. /var/log/README is a similar case and > /etc/inittab too. I think we can do the same here too and make clear > that people need to install cronie first before these things work. > > Alternatively. just drop the cron dropin dirs from the base image: if > i want to drop in a script in the dirs I should notice if I can't > because the dir doesn't actually exist. > > Lennart > > -- > Lennart Poettering, Berlin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Di, 09.04.19 20:12, Richard Hughes (hughsi...@gmail.com) wrote: > On Tue, 9 Apr 2019 at 19:27, Lennart Poettering wrote: > > Hmm? Can you elaborate? Why does fwupd's runtime have something to do > > with display flickers? Not grokking the connection? > > More information in > https://github.com/hughsie/fwupd/commit/75b965d01d80d70ae51816acd4d4cafdaf792e99 > -- in the case of MST it's where a fake monitor gets created on the > hardware so the chip can wake up enough to tell us the current > firmware version, but the fake monitor causes a flicker for a couple > of reasons. I guess we could always just cache the last known version > in some database somewhere and just assume it's not changed, but if > we're not "alive" to see the device removal/insertion event we don't > know the true state of the hardware. If you're worried about the > startup speed or memory usage, we've been pretty keenly fixing both, > but if you have any specific concerns let me know. Hmm, but why would you scan for firmware versions during hotplug? why not just when the user triggers a query if there's something to update? I presume fwupd subscribes to udev events for this, what precisely is it susbcribing to? Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, 9 Apr 2019 at 19:27, Lennart Poettering wrote: > Hmm? Can you elaborate? Why does fwupd's runtime have something to do > with display flickers? Not grokking the connection? More information in https://github.com/hughsie/fwupd/commit/75b965d01d80d70ae51816acd4d4cafdaf792e99 -- in the case of MST it's where a fake monitor gets created on the hardware so the chip can wake up enough to tell us the current firmware version, but the fake monitor causes a flicker for a couple of reasons. I guess we could always just cache the last known version in some database somewhere and just assume it's not changed, but if we're not "alive" to see the device removal/insertion event we don't know the true state of the hardware. If you're worried about the startup speed or memory usage, we've been pretty keenly fixing both, but if you have any specific concerns let me know. Richard. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/9/19 2:20 PM, Lennart Poettering wrote: > On Di, 09.04.19 10:11, Adam Williamson (adamw...@fedoraproject.org) wrote: > >> Basically, anything that's part of the install environment is going to >> be present after a live install. That accounts for both of the above: >> the installer supports multipath and dmraid storage devices, so the >> relevant packages are part of the install environment, so they're part >> of the lives, so they're installed by a live install. > > Hmm, but the installed OS is not 100% the same as the livesys, or is > it? If not, it should be possible to add a "systemctl disable > dmraid.service --root=/path/to/os" somewhere, no? > >> To be specific here, 'at' is part of the @standard group. 'chrony' >> is > > Yupp, it's very confusing that we have chrony and cronie in our OS > and both are installed by default... ;-) > >>> I don't know on this. I remember something about containers and flatpaks >>> but .. I don't know. >> >> Boxes is a key component of Workstation, and it relies on libvirt. It's >> in the 'Core Applications' definition of the Workstation tech spec: > > Hmm, but boxes supposedly uses the user session version of libvirt, > no? it doesn't actually use the system service? > You're right it does not explicitly talk to the system libvirtd instance. But boxes implicitly depends on system libvirtd to autostart the 'default' virtual network, which is the preferred networking method. boxes VMs then essentially use a small setuid helper shipped with qemu to use the default virbr0 for unprivileged VMs. Thanks, Cole ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/9/19 2:24 PM, Lennart Poettering wrote: > On Di, 09.04.19 14:16, Cole Robinson (crobi...@redhat.com) wrote: > >> On 4/9/19 1:09 PM, Zbigniew Jędrzejewski-Szmek wrote: >>> On Tue, Apr 09, 2019 at 06:07:09PM +0200, Lennart Poettering wrote: multipathd [...] And beyond that, this daemon is really ugly too: it logs at high log levels during boot that it found no configuration and hence nothing to do. Yes, obviously, but that's a reason to shut up and proceed quickly, not to complain loudly about that so that it even appears on the scren (I mean srsly, this is the first thing I saw when i booted from the fedora live media: a log message printed all over the screen that multipathd has no working configuration...). >>> >>> This was supposed to be fixed >>> https://bugzilla.redhat.com/show_bug.cgi?id=1631772. >>> If not, please reopen that bug. >>> 5. libvirtd. Why is this running? Can't we make this socket activatable + exit-on-idel? >>> >>> This was supposed to happen. See >>> https://bugzilla.redhat.com/show_bug.cgi?id=1290357. >>> >> >> This bug (briefly) describes why at present libvirt can't use socket >> activation: https://bugzilla.redhat.com/show_bug.cgi?id=1326136 > > Hmm, so that is a valid request I guess. But why can't libvirt do > exit-on-idle? i.e. after it started up, after it noticed that it has no VMs to > run, checks that there are no IPC requests pending, can't it just exit > then and then rely on socket activation to be started again when it is > needed the next time? That way libvirt would start at boot, but not > stick around during normal runtime. > I don't know off hand of anything that would prevent it. Libvirt does process events from running qemu VMs, but if there's no API users connected to the daemon then I don't think libvirtd needs to be running; it can handle restart and reconnecting to running VMs. That's essentially the same behavior the session libvirtd instance uses which auto shuts down after 30 seconds if there's no clients IIRC. danpb would know best though, CCd Thanks, Cole ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
