Re: [DNG] no-usr-merged: let's get concrete
On 11/19/18 3:17 AM, KatolaZ wrote: Hi All, in the last few days we have seen many people going at lengths with the pros and cons of a non-merged usr. That has been a great discussion. We have put together a solution that consists into choosing if you want merged-usr at install time. It's available in the current unstable installer: https://pkgmaster.devuan.org/devuan/dists/unstable/main/installer-amd64/current/images/netboot/mini.iso It would be great for the vocal support against usr-merge to become a concrete piece of help to maintaining choice in Devuan. So if you care, please install beowulf/ceres using the mini.iso above and help testing all the possible scenarios of non-merged /usr, to discover any potential issue/breakage there. Note: the mini.iso is a barebone netinst, and tasksel does not currently work (I am on that). The "Package selection" step will fail. Just skip it, continue with the installation, and then install stuff with apt-get after reboot. Please report bugs on https://bugs.devuan.org. We are currently upgrading many packages in unstable, including reportbug, so either use the reportbug version from ascii or just use reportbug to prepare the report and then send the email it creates to submit[at]bugs.devuan.org Your help is very welcome. HND KatolaZ I'm just a user and not sure about the discussion. But if this has something to do with permissions, well I'm used to su to root and do what ever I want to do. Things have changed, now I need to sudo to run 'upgrade-system', it does a dist-upgrade and runs deborphan with the one command. But I can still su and run aptitude. On this system fully upgraded and cleaned today. -- Jimmy Johnson Devuan Ceres - Trinity R14.0.6 - Intel T5250 - GM965/GL960 - EXT4 at sda7 Registered Linux User #380263 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Rudeness can be productive. Re: /usr to merge or not to merge... that is the question
I have witnessed the same increase in productivity. It involves a lot of people adding a filter rule to their mail clients. Patrick ‐‐‐ Original Message ‐‐‐ On Thursday, November 22, 2018 7:10 PM, terryc wrote: > Good advice, but sometimes it can be counter productive. > > There are always "two" sides/views to any situation and I've always > found any out burst can be helpful, cathartic and generally lead to > increased production. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Rudeness can be productive. Re: /usr to merge or not to merge... that is the question
On Fri, Nov 23, 2018 at 12:10:11PM +1100, terryc wrote: [cut] > > Good advice, but sometimes it can be counter productive. > > There are always "two" sides/views to any situation and I've always > found any out burst can be helpful, cathartic and generally lead to > increased production. > Calling somebody an arsehole has never helped to progress a discussion by a single bit. This is the last warning: if you are not able to make your point clear without a "cathartic" insult to somebody, then your posts will be moderated. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Is Didier another troll? Re: /usr to merge or not to merge... that is the question
On Fri, Nov 23, 2018 at 11:44:04AM +1100, terryc wrote: [cut] > > Dear KatolaZ, My question wasn't intended to you, though I was > > pretty sure you would answer and I knew your answer :-) > > > > > I've observed people opposed to the merge feel very upset. > > At this point you lead me to believe that you are a duplicitous > arsehole. You made a statement and I replied to that. > > Now your post seek to do what you had previously claim other were > doing. Firstly you start off for some alleged motivation, > No Terryc, Didier is a long-term contribution to this ML, not a troll, and he has never called any other member a arsehole, while you have. Personal insults are not tolerated here. If you cannot make your point clear without insulting somebody, then your posts will be moderated. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On Thu, Nov 22, 2018 at 11:24:05PM +0100, Alessandro Selli wrote: > On 22/11/18 at 19:21, Roger Leigh wrote: > > On 21/11/2018 16:11, Alessandro Selli wrote: > >> On 21/11/18 at 13:17, Roger Leigh wrote: > >>> Hi folks, > >>> > >>> I've been following the discussion with interest. > >> > >> > >> No, you definitely have not followed it. In fact you are > >> disregarding > >> all the points that were expressed against the merge. > > > > Let me begin by stating that I found your reply (and others) to be > > rude, unnecessarily aggressive, and lacking in well-reasoned objective > > argument. > > > Oh poor show flake, did I hurt your tender feelings when I state facts? > > Alessandro, you are not funny at all. Roger is one of the DDs who stood the systemd avalanche in Debian, and the first one to publicly support Devuan (please read https://devuan.org/os/debian-fork/ to see what I mean). Roger took the time and effort to provide a first-hand explanation about the whats and whys behind early boot incantations. And his insight in this respect is precious and fundamental. I appreciate that not everybody might be interested in these details, but this thread is *exactly* about that, not about your own personal experience with this or that setup. On a related point: no, Alessandro, Devuan is not a Desktop-oriented distribution. Devuan strives to remain as a universal operating system as Debian claims to be. Devuan is currently used in a mutlitude of environments that include server farms, corporate and personal servers, embedded systems, personal devices, and desktops. So any choice Devuan will make has to take into account *all* the different uses of Devuan. We are going to provide the users with the choice of having or not having a merged-usr. This serves best the purpose of Devuan, and its commitment to guarantee as much freedom as possible to the people who decide to use Devuan. Those who think Devuan is not fit for their purpose have still the freedom to either contribute to Devuan and make it "better" (for whatever definition of "better") or to choose among a variety of other distributions. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Rudeness can be productive. Re: /usr to merge or not to merge... that is the question
On 2018-11-22 19:10, terryc wrote: On Thu, 22 Nov 2018 16:05:37 -0600 goli...@dyne.org wrote: It seems you missed this good advice from Roger Leigh: "Let me begin by stating that I found your reply (and others) to be rude, unnecessarily aggressive, and lacking in well-reasoned objective argument. It's poor communication like this which caused me to unsubscribe from the Debian lists, and also to this list a good while back (I only read the digest summary on occasion, and rarely participate). I find it fosters an unfriendly, unpleasant and unproductive environment which I don't enjoy working in. When you're doing this type of work as a part-time volunteer, it's extremely demotivating and disheartening to be treated this way. It would be unacceptable in a professional setting, and it's equally unacceptable here. Please do think about what you have written before sending it; it costs nothing to be nice, even when you are in disagreement with someone." Good advice, but sometimes it can be counter productive. There are always "two" sides/views to any situation and I've always found any out burst can be helpful, cathartic and generally lead to increased production. If someone is posting in a manner that causes offence to someone, it is better that it be drawn to the attention of the poster. They can then choose to modify their posting style or not. At least both sides know where they stand. I'd much rather have contributions(posts) than sulking. YMMV, but I dislike tofu, blancmange and similar. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Rudeness can be productive. Re: /usr to merge or not to merge... that is the question
On Thu, 22 Nov 2018 16:05:37 -0600 goli...@dyne.org wrote: > On 2018-11-22 14:55, Alessandro Selli wrote: > > On 22/11/18 at 16:25, Didier Kryn wrote: > >> Le 22/11/2018 à 13:25, Alessandro Selli a écrit : > >>> chown -R a-w /bin > >>> chown -R a-w /sbin > >>> chown -R a-w /lib > >> > >> Sorry, I meant chmod. > >> > >> Mounting read-only isn't more secure than marking a directory > >> read-only. root can change it anytime in a single command. > > > > > > Do you think root cannot change anytime file's permissions on the > > filesystem? > > > > Of course it adds security to the system, because if the > > filesystem was mounted ro root HAS to remount it rw in order to be > > able to do changes on the filesystem. Should you only change > > file's permissions you have NOT protected anything, because I > > inform you, on any Unix, since the dawn of Unix time, ROOT CAN DO > > WHAT IT WANTS REGARDLESS OF FILE PERMISSIONS! > > > > Didn't you know this? Whom am I debating with, a Windows > > sysadmin, a full time Valve gamer, a systemd developer? > > > > You are again blockheadedly ignoring the fact that read-only is > > *NOT* the only setting that make sense changing on the /usr > > filesystem! There > > are several, and I already *twice* listed a few of them: nobarrier, > > noatime, iversion, nodev, etc etc. > > > > > > Do you know so little of filesystem management or are you > > trolling? > > It seems you missed this good advice from Roger Leigh: > > "Let me begin by stating that I found your reply (and others) to be > rude, unnecessarily aggressive, and lacking in well-reasoned > objective argument. It's poor communication like this which caused > me to unsubscribe from the Debian lists, and also to this list a good > while back (I only read the digest summary on occasion, and rarely > participate). I find it fosters an unfriendly, unpleasant and > unproductive environment which I don't enjoy working in. When you're > doing this type of work as a part-time volunteer, it's extremely > demotivating and disheartening to be treated this way. It would be > unacceptable in a professional setting, and it's equally unacceptable > here. Please do think about what you have written before sending it; > it costs nothing to be nice, even when you are in disagreement with > someone." Good advice, but sometimes it can be counter productive. There are always "two" sides/views to any situation and I've always found any out burst can be helpful, cathartic and generally lead to increased production. If someone is posting in a manner that causes offence to someone, it is better that it be drawn to the attention of the poster. They can then choose to modify their posting style or not. At least both sides know where they stand. I'd much rather have contributions(posts) than sulking. YMMV, but I dislike tofu, blancmange and similar. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Is Didier another troll? Re: /usr to merge or not to merge... that is the question
On Thu, 22 Nov 2018 18:32:53 +0100 Didier Kryn wrote: > Le 22/11/2018 à 17:02, KatolaZ a écrit : > > On Thu, Nov 22, 2018 at 04:28:55PM +0100, Didier Kryn wrote: > >> Le 22/11/2018 à 13:42, terryc a écrit : > >>> IME, absolutely nothing in real life works that way. > >>> Do you dump all your clothes into one big bin or store them by say > >>> type? > >> Files are stored in different directories, that's it for clean > >> bookkeeping. Making these directories mountpoint does not add any > >> sort of ordering. Only the impression they are more secure. My > >> opinion is that impression is only an impression. Am I allowed to > >> express my opinion without causing flames? > >> > > Sure you are, Didier, as is anybody else, and we should all strive > > for this to remain the norm here :) > > > Dear KatolaZ, My question wasn't intended to you, though I was > pretty sure you would answer and I knew your answer :-) > > I've observed people opposed to the merge feel very upset. At this point you lead me to believe that you are a duplicitous arsehole. You made a statement and I replied to that. Now your post seek to do what you had previously claim other were doing. Firstly you start off for some alleged motivation, > I > understand one doesn't like, in general, reforms which don't make > things better and are forced on people, reforms the motivation of > which is weak or obscure. Then you invoke FUD/fear-fear-fear. > > Maybe there is a motivation from the darkside (Systemd), but > there is also a clear but weak motivation, for the sake of making the > filesystem hierarchy more sensible: and again go onto make statements that are not true; every decision has consequences and trade offs. > What I'm advocating is: this hasn't any > consequence for the safety of the OS and it hasn't anymore > consequences on the ability to boot; it's mostly a change in habits. and end by trivialising concerns and past experiences. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] packaging kubernetes
Hi Enrico, On 19/11/18 19:34, Enrico Weigelt, metux IT consult wrote: Maybe we should discuss how to bring extra packages (that aren't covered by Debian at all) into the distro. Any ideas ? --mtx This week i've been working on the live-sdk and amprolla (gnuinos jessie is comming soon). I removed all the stuff related with the linux kernel comming from debian, including the updates, the security-updates and the backports (i did some minor commits in amprolla for that). So, I might be able to build an extra repository no covered by debian if necessary. Cheers, Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On 22/11/18 at 22:31, Martin Steigerwald wrote: > barrier related mount options are deprecated, well even removed at least > for XFS, deprecated in 4.10 and and removed in 4.19¹. Write barriers > have been replaced by explicit cache flushes² (somewhere around 2.6.39… > I am too lazy to look it up in my Linux Performance tuning and analysis > training slides right now). To bad I can't take advantage of them because of this: [ 1.031094] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA > But with kernels still supporting the mount > option, nobarrier or barrier=0 would have been simply dangerous for data > integrity unless you have made sure that no sudden write interruption by > for example power loss can happen. I use them on battery-backed systems. Bye, -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On 22/11/18 at 19:21, Roger Leigh wrote: > On 21/11/2018 16:11, Alessandro Selli wrote: >> On 21/11/18 at 13:17, Roger Leigh wrote: >>> Hi folks, >>> >>> I've been following the discussion with interest. >> >> >> No, you definitely have not followed it. In fact you are >> disregarding >> all the points that were expressed against the merge. > > Let me begin by stating that I found your reply (and others) to be > rude, unnecessarily aggressive, and lacking in well-reasoned objective > argument. Oh poor show flake, did I hurt your tender feelings when I state facts? [...] Again I express something so simple I'm really beginning to lose my mind: I do not intend to deprive anyone with the freedom to merge /usr to /, damn it! I want to preserve *MY* freedom of choice, I want to be able to split from / anything that is not required on *MY* systems or that will never be required on any system (Java, Apache, Squid, Xorg, LibreOffice etc). I am not fighting against people who want to introduce different filesystem layouts because of their special needs, I WANT THEM TO STOP FORCING THEIR DESIGN CHANGES TO ME FOR NO OTHER REASON THAT TO THEIR SYSTEMS THEIR LAYOUT MAKES MORE SENSE! Is it clear enough now? I hope so. >> 1) mounting /usr with different mount options (like barrier, ro, >> nodev etc); > > Could you describe the specific goals of the separation? Damn it, again? Re-read the thread yourself, it's going to take you less time than it must have taken writing 58 lines, 1458 words and 8565 characters of text to justify the necessity of a / -> /usr merge. [...] > think about the specific problems which you are really trying to > solve, rather than tying the solution to this specific mountpoint. What? Did you read the Subject line at least? All this discussion is centered on "this specific mountpoint"! > Most of / should be ro+nodev just like for /usr. Yeah. Only, / can't be, but /usr can be. > So one deeper question is which bits of / shouldn't be ro/nodev? > /etc? /var? Everything except /dev, of course. > Maybe it should be between / and /etc and /var? Others? Are you kidding? How could you split /etc and /var from /? Are you really saying that keeping /usr split from / makes no sense because you can't split /var and /etc from /? > I should point out that I wrote a set of patches for mounting /etc in > the initramfs as well as /usr, specifically so that you could do this. First you stated that having a separate /usr is to be avoided because it's too troublesome and unmanageable, now you say you split even /etc from /? Great! I'm overjoyed! Since you could do something even more difficult, that no Unix system did before TIKO, could I ask you to please do me a favour? Will you keep /usr splittable from /, as it's been the case for decades even before Linux existed? >> 2) having /usr mounted over the network keeping / local; > While the initramfs does support both local / and remote /usr (by *my > own design and intent*), this is purely to avoid breakage on upgrades. > It's not a recommended setup. What does not "recommended" entail? Is moving /home to /var/Drake/shared recommended? I don't think so. Should this be made impossible then? And is so why? > All the cluster nodes Here we have it again: the changes that are being pushed have clusters as their reference system. But I mostly use GNU/Linux as a desktop system. If Debian is going to follow the Red Hat path, that is design their system tailored just for the Big Data Centers (BDC) needs precluding most desktop customizations, fine, it's their right. I will stay clear of it and will chose other distros that have commoners and their laptops as the typical target. > The content of that /usr filesystem is under the control of *one* dpkg > package database on a single system. If *any* of the other systems > install or remove any package touching /usr (which is all of them!), > they will be corrupting the installation. This only has sense for cluster installs, not desktop ones. If what you're writing means: "Debian from now on will only cater to the needs of BDCs, local desktop customizations will be ignored" well, I'm fine with it. I'll just not go back to Debian, as I do not run a BDC home or on my portable devices. Anyway, syncing updates of shared filesystems can be done with shared mounts. I thought to do some experiments with it some time ago, but then didn't. The relevant documentation is in Documentation/filesystems/sharedsubtree.txt . It should be enough to do this: # mount --make-shared / # mount nfs_server:/storage/shared_root /mnt/root # mount --bind / /mnt/root # mount /dev/sda5 /usr If I am correct, now both / and /usr should be visible under /mnt/root. This way a local update should be propagated to the NFS filesystem. > Even mounting it read-only is giving you an incomplete view of the > installed packages' contents. Why is that? Did I already
Re: [DNG] /usr to merge or not to merge... that is the question
On 2018-11-22 14:55, Alessandro Selli wrote: On 22/11/18 at 16:25, Didier Kryn wrote: Le 22/11/2018 à 13:25, Alessandro Selli a écrit : chown -R a-w /bin chown -R a-w /sbin chown -R a-w /lib Sorry, I meant chmod. Mounting read-only isn't more secure than marking a directory read-only. root can change it anytime in a single command. Do you think root cannot change anytime file's permissions on the filesystem? Of course it adds security to the system, because if the filesystem was mounted ro root HAS to remount it rw in order to be able to do changes on the filesystem. Should you only change file's permissions you have NOT protected anything, because I inform you, on any Unix, since the dawn of Unix time, ROOT CAN DO WHAT IT WANTS REGARDLESS OF FILE PERMISSIONS! Didn't you know this? Whom am I debating with, a Windows sysadmin, a full time Valve gamer, a systemd developer? You are again blockheadedly ignoring the fact that read-only is *NOT* the only setting that make sense changing on the /usr filesystem! There are several, and I already *twice* listed a few of them: nobarrier, noatime, iversion, nodev, etc etc. Do you know so little of filesystem management or are you trolling? It seems you missed this good advice from Roger Leigh: "Let me begin by stating that I found your reply (and others) to be rude, unnecessarily aggressive, and lacking in well-reasoned objective argument. It's poor communication like this which caused me to unsubscribe from the Debian lists, and also to this list a good while back (I only read the digest summary on occasion, and rarely participate). I find it fosters an unfriendly, unpleasant and unproductive environment which I don't enjoy working in. When you're doing this type of work as a part-time volunteer, it's extremely demotivating and disheartening to be treated this way. It would be unacceptable in a professional setting, and it's equally unacceptable here. Please do think about what you have written before sending it; it costs nothing to be nice, even when you are in disagreement with someone." PThere is no need to be rude and insulting (often repeatedly). That goes for everyone of us. golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
[… personal attacks against Didier omitted …] I recommend to go back to basic netiquette. Attacking others in person is not going to help anyone, nor does it add to a friendly community around Devuan. Alessandro Selli - 22.11.18, 21:55: > You are again blockheadedly ignoring the fact that read-only is > *NOT* the only setting that make sense changing on the /usr > filesystem! There are several, and I already *twice* listed a few of > them: nobarrier, noatime, iversion, nodev, etc etc. barrier related mount options are deprecated, well even removed at least for XFS, deprecated in 4.10 and and removed in 4.19¹. Write barriers have been replaced by explicit cache flushes² (somewhere around 2.6.39… I am too lazy to look it up in my Linux Performance tuning and analysis training slides right now). But with kernels still supporting the mount option, nobarrier or barrier=0 would have been simply dangerous for data integrity unless you have made sure that no sudden write interruption by for example power loss can happen. Cause it would cause journaling filesystems to be unable to met strict write ordering demands that are required for journaling to actually work reliably. By doing so, you could basically also run Ext4 without journal at all, in order to optimize performance. There are use cases for that, but if you appreciate your filesystem integrity even in a case of power loss… I'd recommend not doing so. [1] xfs: remove deprecated barrier/nobarrier mount options https://patchwork.kernel.org/patch/10487561/ [2] Jonathin Corbet,The end of block barriers: https://lwn.net/Articles/400541/ Ciao, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On 22/11/18 at 16:28, Didier Kryn wrote: > Le 22/11/2018 à 13:42, terryc a écrit : >> IME, absolutely nothing in real life works that way. >> Do you dump all your clothes into one big bin or store them by say >> type? > > Files are stored in different directories, that's it for clean > bookkeeping. So, you are in favour of retaining a slit / and /usr layout? Good. What does it change if some have /usr mounted on a different device compared to /? > Making these directories mountpoint does not add any sort of ordering. Merging /usr to / does indeed take away ordering. > Only the impression they are more secure. Different mount options do increase the system's overall security *and* they increase flexibility in other areas (like performance and resiliency). > My opinion is that impression is only an impression. Am I allowed to > express my opinion without causing flames? In principle you are, but I do flame when I have to repeat for the 2^64th time reasons to have / split from / while the person I speak to keep ignoring those points and repeating inconsequential matters that either do not apply or are plain wrong. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On 22/11/18 at 16:25, Didier Kryn wrote: > Le 22/11/2018 à 13:25, Alessandro Selli a écrit : >> chown -R a-w /bin >> chown -R a-w /sbin >> chown -R a-w /lib > > Sorry, I meant chmod. > > Mounting read-only isn't more secure than marking a directory > read-only. root can change it anytime in a single command. Do you think root cannot change anytime file's permissions on the filesystem? Of course it adds security to the system, because if the filesystem was mounted ro root HAS to remount it rw in order to be able to do changes on the filesystem. Should you only change file's permissions you have NOT protected anything, because I inform you, on any Unix, since the dawn of Unix time, ROOT CAN DO WHAT IT WANTS REGARDLESS OF FILE PERMISSIONS! Didn't you know this? Whom am I debating with, a Windows sysadmin, a full time Valve gamer, a systemd developer? You are again blockheadedly ignoring the fact that read-only is *NOT* the only setting that make sense changing on the /usr filesystem! There are several, and I already *twice* listed a few of them: nobarrier, noatime, iversion, nodev, etc etc. Do you know so little of filesystem management or are you trolling? -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] no-usr-merged: let's get concrete
On Thu, Nov 22, 2018 at 03:16:07PM -0500, Steve Litt wrote: [cut] > > But you wanted us to test the installer. The installer must have a > working tasksel to not bomb out on that one step, right? Steve, the mini.iso is a netinst. It downloads almost everything from the net, including tasksel, which is one of the components of debian-installer. I tried it yesterday, and it works perfectly. I am not asking you to try the installer: I would like as many people as possible to report problems with the choice of merged-usr/non-merged-usr in unstable/beowulf. > > As far as the other problems I reported, in the next few days I'll > apt-get upgrade my VM to see if I can run lxde, xfce, lxqt and friends. > Please consider that Beowulf is still under working, and most of the desktop stuff is still to be fixed (in terms of policykit and friends), so for instance you will not have any button to suspend/reboot/shutdown. Please just focus on issues related to the merged-usr/non-merged-usr setup at this point. Thanks KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] no-usr-merged: let's get concrete
On Thu, 22 Nov 2018 21:07:57 +0100 KatolaZ wrote: > On Thu, Nov 22, 2018 at 02:46:43PM -0500, Steve Litt wrote: > > On Thu, 22 Nov 2018 07:40:49 +0100 > > KatolaZ wrote: > > > > > On Mon, Nov 19, 2018 at 12:17:45PM +0100, KatolaZ wrote: > > > > > > [cut] > > > > > > > > > > > Note: the mini.iso is a barebone netinst, and tasksel does not > > > > currently work (I am on that). The "Package selection" step will > > > > fail. Just skip it, continue with the installation, and then > > > > install stuff with apt-get after reboot. > > > > > > > > > > Just to let you know that tasksel has now been fixed in unstable > > > and beowulf, so the "Package selection" step should run smoothly. > > > > > > My2Cents > > > > > > KatolaZ > > > > > > Is there an updated mini.iso to celbrate that fact? > > > > No need. You can use the same. Tasksel is downloaded after the bsae > system is installed. But you wanted us to test the installer. The installer must have a working tasksel to not bomb out on that one step, right? As far as the other problems I reported, in the next few days I'll apt-get upgrade my VM to see if I can run lxde, xfce, lxqt and friends. Thanks, SteveT Steve Litt November 2018 featured book: Manager's Guide to Technical Troubleshooting Brand new, second edition http://www.troubleshooters.com/mgr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] My setup, and why I like it
Hi all, There are a million different ways to set up your computer. Preserving those choices is why we use Linux instead of windoz and mac. In a recent thread people have expressed love or disdain for various setups. Let me brag about my setup, which is probably wrong for most of you, but it sure works well for me... My root drive is a little SSD that hosts the /usr and /etc trees. So when I run gnumeric, it pops up quickly because it comes off the SSD. Most other stuff is mountpoints. Of course /home is a mountpoint. But because I don't like mixing valuable data with config info and cache and who knows what else, I have two more important data trees: /d and /s. The distinction is that the stuff on /d is stuff I woudn't worry too much if a badguy got it, whereas the stuff no /s would be a big problem if someone else got it. When I take a laptop to meetings, it usually has a copy of /d but not /s. The /home, /d and /s mountpoints are mounted to spinning rust, because they hold *a lot* of data. On $PATH I have a directory called /d/bats with all my homegrown shellscripts and executables. I think some of you might be catching on that this system is older than my Linux usage: This directory was once D:/bats, and held all the DOS batch files I'd made. My machine has 16 GB RAM, so I can run VMs and lots of Chromium pages without stopping the machine. And, as mentioned, the fact that / and therefore /usr are on SSD makes this machine quick. This machine is about 4 years old. Every other machine I've ever had, by the time it reached 4 years old (usually 3), was so slow and pokey that it needed replacement. But this machine works fine for my needs in 90% of its tasks. I don't run LVM because I don't need yet one more level of abstraction. I don't yet run drive encryption, but may start. I won't be encrypting anything on the root drive, so I can boot up to a useable state and then unencrypt various partitions. It's not for everyone, but it's working well for me. SteveT Steve Litt November 2018 featured book: Manager's Guide to Technical Troubleshooting Brand new, second edition http://www.troubleshooters.com/mgr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] no-usr-merged: let's get concrete
On Thu, Nov 22, 2018 at 02:46:43PM -0500, Steve Litt wrote: > On Thu, 22 Nov 2018 07:40:49 +0100 > KatolaZ wrote: > > > On Mon, Nov 19, 2018 at 12:17:45PM +0100, KatolaZ wrote: > > > > [cut] > > > > > > > > Note: the mini.iso is a barebone netinst, and tasksel does not > > > currently work (I am on that). The "Package selection" step will > > > fail. Just skip it, continue with the installation, and then install > > > stuff with apt-get after reboot. > > > > > > > Just to let you know that tasksel has now been fixed in unstable and > > beowulf, so the "Package selection" step should run smoothly. > > > > My2Cents > > > > KatolaZ > > > Is there an updated mini.iso to celbrate that fact? > No need. You can use the same. Tasksel is downloaded after the bsae system is installed. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] no-usr-merged: let's get concrete
On Thu, 22 Nov 2018 07:40:49 +0100 KatolaZ wrote: > On Mon, Nov 19, 2018 at 12:17:45PM +0100, KatolaZ wrote: > > [cut] > > > > > Note: the mini.iso is a barebone netinst, and tasksel does not > > currently work (I am on that). The "Package selection" step will > > fail. Just skip it, continue with the installation, and then install > > stuff with apt-get after reboot. > > > > Just to let you know that tasksel has now been fixed in unstable and > beowulf, so the "Package selection" step should run smoothly. > > My2Cents > > KatolaZ Is there an updated mini.iso to celbrate that fact? SteveT Steve Litt November 2018 featured book: Manager's Guide to Technical Troubleshooting Brand new, second edition http://www.troubleshooters.com/mgr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On Thu, Nov 22, 2018 at 06:21:01PM +, Roger Leigh wrote: > On 21/11/2018 16:11, Alessandro Selli wrote: > > On 21/11/18 at 13:17, Roger Leigh wrote: > > > Hi folks, > > > > > > I've been following the discussion with interest. > > > > > > No, you definitely have not followed it. In fact you are disregarding > > all the points that were expressed against the merge. > > Let me begin by stating that I found your reply (and others) to be rude, > unnecessarily aggressive, and lacking in well-reasoned objective argument. > It's poor communication like this which caused me to unsubscribe from the > Debian lists, and also to this list a good while back (I only read the > digest summary on occasion, and rarely participate). I find it fosters an > unfriendly, unpleasant and unproductive environment which I don't enjoy > working in. When you're doing this type of work as a part-time volunteer, > it's extremely demotivating and disheartening to be treated this way. It > would be unacceptable in a professional setting, and it's equally > unacceptable here. Please do think about what you have written before > sending it; it costs nothing to be nice, even when you are in disagreement > with someone. > > > Before I follow up on any of the points you (and others) made in response, > let me begin with some history you may be unaware of. It actually predates > systemd, and is largely unrelated to systemd. > Dear Roger, I wholehartedly thank you for your post. It has shown clearly how little most of us (and I put myself in the lot) know about the whole history and functioning of the stuff we use everyday. This is exactly the kind of technical depth I was asking for in this list a couple of days ago, and I am happy it eventually came from you. My "research" in this direction (reviewing early-boot code and changelogs and delving through several mailing lists) had not gotten any close to the amount of information, context, knowledge and motivations you provided in a single email. I guess anybody willing to add even a comment to this thread must be sure to have read, digested, understood, and internalised all the content in Roger's email first. And please do not forget his gentle but strong nudge regarding being nice to other people, also and especially when you disagree with them. ThankYou KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On 21/11/2018 16:11, Alessandro Selli wrote: On 21/11/18 at 13:17, Roger Leigh wrote: Hi folks, I've been following the discussion with interest. No, you definitely have not followed it. In fact you are disregarding all the points that were expressed against the merge. Let me begin by stating that I found your reply (and others) to be rude, unnecessarily aggressive, and lacking in well-reasoned objective argument. It's poor communication like this which caused me to unsubscribe from the Debian lists, and also to this list a good while back (I only read the digest summary on occasion, and rarely participate). I find it fosters an unfriendly, unpleasant and unproductive environment which I don't enjoy working in. When you're doing this type of work as a part-time volunteer, it's extremely demotivating and disheartening to be treated this way. It would be unacceptable in a professional setting, and it's equally unacceptable here. Please do think about what you have written before sending it; it costs nothing to be nice, even when you are in disagreement with someone. Before I follow up on any of the points you (and others) made in response, let me begin with some history you may be unaware of. It actually predates systemd, and is largely unrelated to systemd. 6-7 years ago, back when I was one of the Debian sysvinit maintainers, we had a problem. The problem was that an increasing number of systems could no longer be booted up successfully. The reason for this was that the boot process was becoming increasingly complex. The process could be summarised like this with an initramfs: - mount / in initramfs - [early boot] - mount /usr and other filesystems - [late boot] or directly, without an initramfs - mount / - [early boot] - mount /usr and other filesystems - [late boot] The problems arose from the mounting of /usr part way through the boot process. An increasing number of system configurations required tools and libraries from /usr, before it was mounted. These could be NSS modules, LDAP stuff, dependencies of network filesystem tools, or others. In some cases, this was solved by moving individual tools and libraries from /usr to /[s]bin and /lib. But this became increasingly untenable as the requirements became more and more complex. Not only did we have to move individual tools and libraries and datafiles from /usr to the root filesystem, we also had to move every dependency as well for them to be functional. Also, service dependencies wanted services starting before /usr was mounted, moving chunks of the dependency graph into the early boot stage. This was a losing battle, since we couldn't move /everything/ to the root filesystem. Or could we? It was due to logistical challenges like this that we first considered the merge of / and /usr. Once low-level tools start requiring interpreters like Perl or Python, or libraries like libstdc++, or datafiles like timezone data, it was clear we needed a more general solution which would solve the problems for the long term. The question arose of how we might handle the migration, or avoid the need for a migration entirely. As the sysvinit maintainer, I did most of the investigation and implementation of this work, and you're likely using that solution right now yourself. The solution I chose was one which would allow for making /usr available in early boot without the need for physically merging the filesystems, so that it wouldn't break any of the installed systems on upgrade. We would add to the initramfs the ability to mount additional filesystems other than the rootfs, directly from the rootfs fstab. And we would cater for local and NFS filesystems just as we do for the rootfs. This was one of the more costly solutions (in terms of implementation complexity and testing needed), but it retained the flexibility some people required. This was implemented 5 years back, and the result is this with an initramfs: - mount / and /usr in initramfs - [early boot] - mount other filesystems - [late boot] or directly, without an initramfs: - mount / - [early boot] - mount other filesystems - [late boot] Thus we could guarantee the availability of files in /usr from the moment the system starts, and is independent of all init systems. The tradeoff is that we no longer supported direct booting of a system with a separate /usr; you had to use an initramfs. You could still boot directly, but / and /usr had to be on the same filesystem to guarantee the availability of /usr. But with this solution in place, all stages of the boot could rely on tools, libraries and datafiles present in /usr. This has been in production use since wheezy, and because it was so transparent, very few people would even realise that the filesystems had been (effectively) unified since then, because I took great care to support (and test) every possible
Re: [DNG] /usr to merge or not to merge... that is the question
On Thu, Nov 22, 2018 at 04:28:55PM +0100, Didier Kryn wrote: > Le 22/11/2018 à 13:42, terryc a écrit : > > IME, absolutely nothing in real life works that way. > > Do you dump all your clothes into one big bin or store them by say > > type? > > Files are stored in different directories, that's it for clean > bookkeeping. Making these directories mountpoint does not add any sort of > ordering. Only the impression they are more secure. My opinion is that > impression is only an impression. Am I allowed to express my opinion without > causing flames? > Sure you are, Didier, as is anybody else, and we should all strive for this to remain the norm here :) HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan Jessie + Huawei USB modems
On Thu, Nov 22, 2018 at 03:10:15PM +0100, Miroslav Skoric wrote: > > What is needed to install so that Devuan Jessie recognizes Huawei modems: > > - Huawei Mobile Connect - 3G modem (Wintendo sees it as such) > - Huawei USB modem E3372 4G > - Huawei Mobile Wifi router E5573C 4G I used to use a couple of dongle/modems. I used "raw" chat scripts. As I recall, the dongles were recognised and connected by the kernal via /dev/ttyUSBn, with n = 0,1,2,3,... Or maybe the other /dev/??? name for a serial usb device: I forget for the moment. Perhaps I had to load a module explicity, but I don't think so. The horrible Modem Manager sometimes worked and sometimes didn't. I hated it because it was a complex black box that I couldn't easily debug when it failed. It did (does?) have an associated database of network operators and their various connection protocols/passwords. Checking that database might be useful for information in writing chat scripts. Above was on Debian. I imagine that your dongles are more recent: maybe quite different. I wrote some notes on getting a huwai dongle going, but I don't have them to hand just now. I think that most of the information was on line. ael ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
Le 22/11/2018 à 13:42, terryc a écrit : IME, absolutely nothing in real life works that way. Do you dump all your clothes into one big bin or store them by say type? Files are stored in different directories, that's it for clean bookkeeping. Making these directories mountpoint does not add any sort of ordering. Only the impression they are more secure. My opinion is that impression is only an impression. Am I allowed to express my opinion without causing flames? Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
Le 22/11/2018 à 13:25, Alessandro Selli a écrit : chown -R a-w /bin chown -R a-w /sbin chown -R a-w /lib Sorry, I meant chmod. Mounting read-only isn't more secure than marking a directory read-only. root can change it anytime in a single command. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Devuan Jessie + Huawei USB modems
Hello all, What is needed to install so that Devuan Jessie recognizes Huawei modems: - Huawei Mobile Connect - 3G modem (Wintendo sees it as such) - Huawei USB modem E3372 4G - Huawei Mobile Wifi router E5573C 4G Any good experience with those? Seems that those only support Wintendo and Mac. Misko ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On 22/11/18 at 13:25, Alessandro Selli wrote: > Wrong. Split / and /usr Unix systems have been around for decades and > they have been upgradable. Your "solution" instead: > > chown -R a-w /bin > chown -R a-w /sbin > chown -R a-w /lib > > > would make them not. I am wrong here, as upgrades are performed as root to whom regular read/write file permissions do not apply. What I had in my mind was what I actually use to protect public files in front-line servers, i.e. running chattr +i on them. Still everything else does apply, mount options do much more than preventing file modification, and I urge you to get a grasp of that before you continue this debate. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On 22/11/18 at 13:42, terryc wrote: > On Thu, 22 Nov 2018 10:10:20 +0100 > Didier Kryn wrote: > But >> the part of the OS (which is managed by dpkg) better stays on one >> single partition. > IME, absolutely nothing in real life works that way. > Do you dump all your clothes into one big bin or store them by say > type? > Do you store all your house fitments in one big bin, or store in many > "partitions". I find it so annoying having to retrieve clean cups from > under a pile of screws, bolts, light globes, etc. > > Sub-division of stuff is logical and leads to efficency and the same > applies to computer OSs. +1 -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On Thu, 22 Nov 2018 10:10:20 +0100 Didier Kryn wrote: But > the part of the OS (which is managed by dpkg) better stays on one > single partition. IME, absolutely nothing in real life works that way. Do you dump all your clothes into one big bin or store them by say type? Do you store all your house fitments in one big bin, or store in many "partitions". I find it so annoying having to retrieve clean cups from under a pile of screws, bolts, light globes, etc. Sub-division of stuff is logical and leads to efficency and the same applies to computer OSs. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On 22/11/18 at 10:10, Didier Kryn wrote: > Le 21/11/2018 à 17:11, Alessandro Selli a écrit : >>> 1) A separate /usr serves no practical purpose on a Debian/Devuan >>> system >> Yes it does, and they were already listed: >> >> >> 1) mounting /usr with different mount options (like barrier, ro, >> nodev etc); > > > chown -R a-w /bin > chown -R a-w /sbin > chown -R a-w /lib Please read up man mount(8) and get yourself an idea of what mount options are and do, as you evidently don't have a clue. >> >> 2) having /usr mounted over the network keeping / local; >> >> 3) having a /usr partition shared by several local installs that are >> booted on different / filesystems; >> >> 4) having the smallest possible / filesystem to ease recovery of a >> botched system. >> >> > This is all fine with a custom OS, not when it is maintained by a > package manager. Yes, of course. And guess what? My systems are *all* customized, because no group of package managers gets my needs and desires perfect, and this is one of the reasons I run GNU/Linux on my PCs and laptops instead of Windows or MacOSX. Which is natural, as package managers have to setup a distribution that must satisfy a large number of use cases, some of which are in constrast to each other (such as power-compilation server vs. workstation for network security scanning and assessment). > Inconsistencies between the different filesystems on which the package > manager operates will just make it mad. Kernel maintainers have a much tougher life than just having to decide where their binaries are going to sit. Yet they manage. > Your OS may still be usable but not updatable. Wrong. Split / and /usr Unix systems have been around for decades and they have been upgradable. Your "solution" instead: chown -R a-w /bin chown -R a-w /sbin chown -R a-w /lib would make them not. > I have realized this after two decades of crazy partitionning. Your sysadmin failures prove nothing concerning good, longstanding filesystem layout practices, their reasons to exist and the possibility of sysadmins to be able to customize their GNU/Linux installation the way they choose. > /home should definitely be separated and well protected (RAID where > possible, backups), /usr/local (or /local) may as well, /opt > also,since Debian does not use it. But the part of the OS (which is > managed by dpkg) better stays on one single partition. There's no reason to do so other than a few corner cases (like clusters). Again, contrary to the Free(lol!)desktop people I am not keen at imposing my views and choices onto others, those who refere a merged / -> /usr filesystem should be able to do so. But they definitely keep their hands off *my* systems and stop trying to funnel *their* preferences down my throat against my will. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
Quoting Didier Kryn (k...@in2p3.fr): > /home should > definitely be separated and well protected (RAID where possible, > backups), /usr/local (or /local) may as well, /opt also,since Debian > does not use it. Here's my idea for how best to deal with the problem of /opt: :r! ls -l /opt lrwxrwxrwx 1 root root 14 Mar 4 2008 /opt -> /usr/local/opt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Quoting Didier Kryn (k...@in2p3.fr): > Rick, I'm very impressed by the level of responsibility which > has been given to you. We certainly don't have the same mileage. You > are a professional while I am just a somehow educated amateur. Well, when I _started_ doing that, I was a staff accountant and tax preparer with no IT experience whatsoever. I'm really not a lot smarter or better informed (but OTOH still annoyingly well-preserved). And, frankly, I don't do anything with kernels that I didn't do in the 1990s when I was just a staff accountant and tax preparer with zero IT experience -- just the obvious. The tools are just a bit better, and I'm faster at skim-reading the CVEs. (LASIK helps for us annoyingly youthful-looking old people.) And, of course, what was _really_ helpful in learning how to build and run systems is having nobody tell me it was an unreasonable thing to expect to run and administer my own servers, so I did so. Funny how that works. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Le 22/11/2018 à 10:27, Rick Moen a écrit : Quoting Didier Kryn (k...@in2p3.fr): Just out of curiosity: Debian kernels are patched by Debian's kernel team, in particular for security fixes. Therefore I see 4 options (at least) 1) compile from kernel.org source with your own config 2) compile from kernel.org source with Debian's config, customized by you 3) compile from Debian patched kernel source with your own config 4) compile from Debian patched kernel source with Debians config, customized by you A few years ago, I was the senior Operations guy (can't remeber the exact title) for a 'merchant bank', which is a rather odd term in e-commerce for a company or business unit whose business is handling online credit card data, accepting transactions from Web sites (either the company's own, or that of client firms, or both) and passing that on to the credit card clearinghouses. One part of that job was, every three months, proving to an auditing firm that the merchant bank's computing infrastructure still passed PCI DSS, the Payment Card Industry Data Security Standard. Much of this was tedious work proving that publicly relevant software was immune to known vulnerabilities as recorded in significant-grade CVEs. So, in turn, this meant that I got really good at showing that particular CVEs did not apply to our particular software and configuration because [reason X]. When the auditors deemed my analysis compelling, my merchant bank passed that component of PCI DSS. (There's a lot more to PCI DSS, which you can look up if curious, but I'm citing the portion that I feel casts some light on present discussion.) My point relates to the frequent 'doesn't apply to our particular software and configuration' outcome, whose frequency surprised me a bit -- even though the scope of auditing was the entire software complement of a complete data farm, not just a single piece of software such as an OS kernel. In attending to my own software on my personal systems, after I've pared down the software included in my bespoke binary kernel and associated modules to _only_ the software I actually want and need, and then further lock down / trim functionality in related system configuration files, the percentage of new Linux kernel CVEs that upon examination turn out to be even theoretically relevant to my systems goes down to almost none. It remains a really good idea to follow CVE news, which is why I subscribe to debian-security and have a subcription to LWN.net. Just in case something really is on fire. In addition to fixing CVEs, kernel revisions in theory also fix general bugs, in theory not along the way introucing new bugs, and introduce new hardware support and general alleged improvements and general alleged improvements. At some point, one abandons that version 2.0.13 kernel one first built in 2001, even if there aren't any relevant CVEs against it. Speaking in general terms, the result is that you skim-read and mumble 'Next!' a lot, and upgrade rather little. Your Mileage May Differ.[tm] I do as mentioned use my own kernel .config file for such systems, because IMO the alternative would be absurd. (Why bother compiling that software without customising for one's local system?) I'm not intending to tell you what kernel source code I use, or exactly how often this is updated and why and how, or any other such answers that would equate to posting the most sensitive details of security-sensitive issues to a public mailing list. A sufficient reason should be very obvious, plus there really is no reason for you to have that information. OTOH, I applaud your thinking about and crafting your own locally appropriate security policy, which is a very good idea for all *ix admins. Rick, I'm very impressed by the level of responsibility which has been given to you. We certainly don't have the same mileage. You are a professional while I am just a somehow educated amateur. It is clear also that the systems we care of (have cared of) haven't the same requirements in matter of security. In this mailing list, you rather advocate for big server infrastructures open to the public, while I'm rather on the side of the DIY guy, and also, sometimes, the almost dummy. I think it is great that Devuan can match all these use cases and I hope the discussion is usefull to others. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Quoting Didier Kryn (k...@in2p3.fr): > Just out of curiosity: > > Debian kernels are patched by Debian's kernel team, in > particular for security fixes. Therefore I see 4 options (at least) > > 1) compile from kernel.org source with your own config > > 2) compile from kernel.org source with Debian's config, > customized by you > > 3) compile from Debian patched kernel source with your own config > > 4) compile from Debian patched kernel source with Debians > config, customized by you A few years ago, I was the senior Operations guy (can't remeber the exact title) for a 'merchant bank', which is a rather odd term in e-commerce for a company or business unit whose business is handling online credit card data, accepting transactions from Web sites (either the company's own, or that of client firms, or both) and passing that on to the credit card clearinghouses. One part of that job was, every three months, proving to an auditing firm that the merchant bank's computing infrastructure still passed PCI DSS, the Payment Card Industry Data Security Standard. Much of this was tedious work proving that publicly relevant software was immune to known vulnerabilities as recorded in significant-grade CVEs. So, in turn, this meant that I got really good at showing that particular CVEs did not apply to our particular software and configuration because [reason X]. When the auditors deemed my analysis compelling, my merchant bank passed that component of PCI DSS. (There's a lot more to PCI DSS, which you can look up if curious, but I'm citing the portion that I feel casts some light on present discussion.) My point relates to the frequent 'doesn't apply to our particular software and configuration' outcome, whose frequency surprised me a bit -- even though the scope of auditing was the entire software complement of a complete data farm, not just a single piece of software such as an OS kernel. In attending to my own software on my personal systems, after I've pared down the software included in my bespoke binary kernel and associated modules to _only_ the software I actually want and need, and then further lock down / trim functionality in related system configuration files, the percentage of new Linux kernel CVEs that upon examination turn out to be even theoretically relevant to my systems goes down to almost none. It remains a really good idea to follow CVE news, which is why I subscribe to debian-security and have a subcription to LWN.net. Just in case something really is on fire. In addition to fixing CVEs, kernel revisions in theory also fix general bugs, in theory not along the way introucing new bugs, and introduce new hardware support and general alleged improvements and general alleged improvements. At some point, one abandons that version 2.0.13 kernel one first built in 2001, even if there aren't any relevant CVEs against it. Speaking in general terms, the result is that you skim-read and mumble 'Next!' a lot, and upgrade rather little. Your Mileage May Differ.[tm] I do as mentioned use my own kernel .config file for such systems, because IMO the alternative would be absurd. (Why bother compiling that software without customising for one's local system?) I'm not intending to tell you what kernel source code I use, or exactly how often this is updated and why and how, or any other such answers that would equate to posting the most sensitive details of security-sensitive issues to a public mailing list. A sufficient reason should be very obvious, plus there really is no reason for you to have that information. OTOH, I applaud your thinking about and crafting your own locally appropriate security policy, which is a very good idea for all *ix admins. -- Cheers, "Overheard a hipster say 'Quinoa is kind of 2011', Rick Moenso I lit his beard on fire." -- @kellyoxford r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Le 21/11/2018 à 17:34, k...@aspodata.se a écrit : To boot with an uefi system you need a fat partition available before even the bootloader is loaded, so what is the reason that you cannot use that instead of an initrd ? I agree, anything done in an initrd or initramfs can be done in a disk partition. The advantage being that it is easier to modify a disk partition. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
Le 21/11/2018 à 17:11, Alessandro Selli a écrit : 1) A separate /usr serves no practical purpose on a Debian/Devuan system Yes it does, and they were already listed: 1) mounting /usr with different mount options (like barrier, ro, nodev etc); chown -R a-w /bin chown -R a-w /sbin chown -R a-w /lib 2) having /usr mounted over the network keeping / local; 3) having a /usr partition shared by several local installs that are booted on different / filesystems; 4) having the smallest possible / filesystem to ease recovery of a botched system. This is all fine with a custom OS, not when it is maintained by a package manager. Inconsistencies between the different filesystems on which the package manager operates will just make it mad. Your OS may still be usable but not updatable. I have realized this after two decades of crazy partitionning. /home should definitely be separated and well protected (RAID where possible, backups), /usr/local (or /local) may as well, /opt also,since Debian does not use it. But the part of the OS (which is managed by dpkg) better stays on one single partition. /run, /tmp are well on tmpfs. An efficient way to secure the OS is to clone it on another partition. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Le 20/11/2018 à 20:04, Rick Moen a écrit : Since the gentleman seemed not to be familiar with make-kpkg in package kernel-package, perhaps he should start there. (However, I believe it's now deprecated as of Debian stretch, and being replaced by newer automation tool deb-pkg, and coverage in The Debian Administrator's Handbook has now been updated to discuss that, instead.) Actually, I'm not familiar with that tool, nor with package management internals. I've only been a simple user of apt. Now that I'm retired and only use a laptop, I'm not sure I want to go into that. Maybe... :-) Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
