Re: [DNG] merging /tmp
Le 24/11/2018 à 22:41, Adam Borowski a écrit : On Sat, Nov 24, 2018 at 02:40:31PM -0500, Hendrik Boom wrote: On Sat, Nov 24, 2018 at 06:47:42PM +0100, Didier Kryn wrote: In my last install, I still had /tmp and /var on separate partitions, but I'm questionning the validity of such a setup. It's useful to have /tmp on a separate partition in case some process running amok fills it and ordinary shell commands that need temprary files stop working. And it's even better if that partition is formatted as swap. You then mount /tmp as tmpfs (hey, lookie at the name!), and files there won't even hit the disk unless there's some memory pressure. With default value of /proc/sys/vm/swappiness being 60, the system won't sacrifice caching just to keep old crap in /tmp in memory and will swap them out eventually. But, during any compilation, gcc's temp files won't need to be written out if gcc doesn't manage to delete them within that 5 seconds window... But there are other tmpfs filesystems, eg /run, whichcontain critical files and might be swapped out if /tmp overflows. Is there a means to dedicate a swap partition to a particular /tmpfs mount. Note it's also possible to put a size limit to every tmpfs mount. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My setup, and why I like it
On Sat, 24 Nov 2018 12:18:53 -0600 Dan Pridgeon wrote: > I look forward to your "detailed > instructions" around this issue. (Though retired out of the computer > test environment, I'm very much a newbie when it comes to the > collaborative development via the Internet environment.) I'm very > interested in the this/your topic as well as the boot process (in > atomic detail), and, the wireless access mechanism. Thanks. I posted the instructions here: https://blog.spiralofhope.com/?p=40064 Don't be put off or insulted by my extreme verbosity. I think all instructions should boil down to a list of checkboxes. :) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My setup, and why I like it
On Sat, 24 Nov 2018 22:47:51 +0100 Harald Arnesen wrote: > Could you have /boot on a USB stick that you carry with you when not > at the computer? Oh my, this is an elegant solution! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] merging /tmp
On 24.11.18 22:41, Adam Borowski wrote: > On Sat, Nov 24, 2018 at 02:40:31PM -0500, Hendrik Boom wrote: > > On Sat, Nov 24, 2018 at 06:47:42PM +0100, Didier Kryn wrote: > > > > > > In my last install, I still had /tmp and /var on separate partitions, > > > but I'm questionning the validity of such a setup. > > > > It's useful to have /tmp on a separate partition in case some process > > running amok fills it and ordinary shell commands that need temprary > > files stop working. > > And it's even better if that partition is formatted as swap. You then mount > /tmp as tmpfs (hey, lookie at the name!), and files there won't even hit the > disk unless there's some memory pressure. With default value of > /proc/sys/vm/swappiness being 60, the system won't sacrifice caching just to > keep old crap in /tmp in memory and will swap them out eventually. But, > during any compilation, gcc's temp files won't need to be written out if gcc > doesn't manage to delete them within that 5 seconds window... Hey, that could speed up big compiles. Sounds worth trying. That leaves /var, which I've kept separate for three decades, to obviate the risk of furious rates of logging fatally depleting /. OK, it takes longer now, but the principle remains. Growth of /tmp was never a problem, as removal of several day old tmp files was/is a standard cronjob, at least after you've been bitten once. Erik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My setup, and why I like it
spiralofhope [24.11.2018 22:17]: >> Drive encryption has advantages in terms of keeping secrets and >> foiling the evil-maid scenario. > I always thought an evil maid could fiddle with the bootloader/etc or > root to wholly compromise the system somewhat easily, and then it's > just a matter of waiting for the user to use a key or passphrase. It's > two-step, but still straightforward. > > Maybe there's another term for this variation? Could you have /boot on a USB stick that you carry with you when not at the computer? -- Hilsen Harald ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] merging /tmp
On Sat, Nov 24, 2018 at 02:40:31PM -0500, Hendrik Boom wrote: > On Sat, Nov 24, 2018 at 06:47:42PM +0100, Didier Kryn wrote: > > > > In my last install, I still had /tmp and /var on separate partitions, > > but I'm questionning the validity of such a setup. > > It's useful to have /tmp on a separate partition in case some process > running amok fills it and ordinary shell commands that need temprary > files stop working. And it's even better if that partition is formatted as swap. You then mount /tmp as tmpfs (hey, lookie at the name!), and files there won't even hit the disk unless there's some memory pressure. With default value of /proc/sys/vm/swappiness being 60, the system won't sacrifice caching just to keep old crap in /tmp in memory and will swap them out eventually. But, during any compilation, gcc's temp files won't need to be written out if gcc doesn't manage to delete them within that 5 seconds window... sysvinit has specific support for this: edit /etc/default/tmpfs (the file says: # NOTE: This file is ignored when systemd is used as init system # at the start -- but it's not like you expect systemd advice on _this_ list). Meow! -- ⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased ⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts. ⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got ⠈⠳⣄ agriculture, towns then cities. -- whitroth on /. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My setup, and why I like it
On Sat, 24 Nov 2018 14:45:56 -0500 Hendrik Boom wrote: > Drive encryption has advantages in terms of keeping secrets and > foiling the evil-maid scenario. I always thought an evil maid could fiddle with the bootloader/etc or root to wholly compromise the system somewhat easily, and then it's just a matter of waiting for the user to use a key or passphrase. It's two-step, but still straightforward. Maybe there's another term for this variation? ___ 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: > > It would be possible to share the ports tree on a FreeBSD system, since it's > mostly self-contained, so long as it's read-only (it has unshared data in > /var including the package database, so can't be read-write). But this is > not reasonable with dpkg, by design. The packages are putting data in / and > /usr, as well as /var. You cannot just export /usr without getting into an > inconsistent and incoherent mess. The only way I can see for BSD to have a package system with a separate and shared /usr is (1) to absolutely forbid any dependencies from anything on /usr from anything in the root file system, (2) No package to have files in both /usr and the root file system (3) Split the package data base so that packages in /usr are tracked in /usr and that packages in the root file system are tracked in the root file system. (4) Make sure that you don't need anything in /usr to to packaage maintenance on the root file system. Then upgrading the root file system can be done independently of upgrading /usr. I suspect that this may be too severe a set of restrictions for BSD to tolerate, and as you mention, for Debian that ship has sailed long ago. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My setup, and why I like it
On Thu, Nov 22, 2018 at 03:14:10PM -0500, Steve Litt wrote: > 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. > Drive encryption has advantages in terms of keeping secrets and foiling the evil-maid scenario. There is some cost in terms of slightly slower access time. But the real risk is that of forgetting the decryption key. For me this possibility is enough to prohibit encryption. -- hendrik > 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 mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] merging /tmp
On Sat, Nov 24, 2018 at 06:47:42PM +0100, Didier Kryn wrote: > > In my last install, I still had /tmp and /var on separate partitions, > but I'm questionning the validity of such a setup. It's useful to have /tmp on a separate partition in case some process running amok fills it and ordinary shell commands that need temprary files stop working. After a reboot it's clean again. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Request for comments - training room
I would appreciate advice on the following situation I have several hosts of differing architectures or peripherals in a training room (several training rooms actually but each are independent of each other) which are supported by a server running the standard *NIX network services DHCP, BIND etc. The server also has the training application (which is single install license but multi-user) installed on it . How should this training room be best implemented for reliability and ease of maintenance ? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My setup, and why I like it
On 11/24/18 11:36 AM, spiralofhope wrote: On Thu, 22 Nov 2018 15:14:10 -0500 Steve Litt wrote: I don't yet run drive encryption, but may start. I encourage it. It's straightforward, and was surprisingly good performance for me, even on rust. I did it from scratch, prepping a whole drive and then copying data from elsewhere, and holy hell did it take forever and cook that room. You don't need them, but I decided to make very detailed instructions meant for complete newbies on how to install and reinstall onto plain non-LVM encrypted root partitions without reformatting. I've been too lazy to publish it, but I'll get to that soonish. [snip] I have found this thread very educational (except for the times when someone disparages another). I look forward to your "detailed instructions" around this issue. (Though retired out of the computer test environment, I'm very much a newbie when it comes to the collaborative development via the Internet environment.) I'm very interested in the this/your topic as well as the boot process (in atomic detail), and, the wireless access mechanism. Thanks. ___ 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 24/11/2018 à 13:13, Roger Leigh a écrit : (Like many, I used to routinely use a separate /usr on a separate partition, then LVM LV, until I really looked at the practice and questioned the real underlying problems which it was solving. I've not needed one in over a decade at this point. I'm not particularly for or against having one. It's simply ceased to be a relevant concern for any of the diverse systems I've worked on, from desktops and workstations, to cluster nodes, VMs, servers and container images. None of them needed it.) Like you I did mount /usr separately for over a decade, with the idea that my OS would be recoverable if /usr was corrupted. Untill I realized it simply wouldn't. I tend to prefer, now to reserve a partition for another Linux OS. It could be a clone, of the main one, but I prefer experimenting with fancy things, even custom. Disks are so big nowadays that there is a lot of room for it. In my last install, I still had /tmp and /var on separate partitions, but I'm questionning the validity of such a setup. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My setup, and why I like it
On Thu, 22 Nov 2018 15:14:10 -0500 Steve Litt wrote: > I don't yet run drive encryption, but may start. I encourage it. It's straightforward, and was surprisingly good performance for me, even on rust. I did it from scratch, prepping a whole drive and then copying data from elsewhere, and holy hell did it take forever and cook that room. You don't need them, but I decided to make very detailed instructions meant for complete newbies on how to install and reinstall onto plain non-LVM encrypted root partitions without reformatting. I've been too lazy to publish it, but I'll get to that soonish. > I won't be encrypting > anything on the root drive, so I can boot up to a useable state and > then unencrypt various partitions. This is easy to do. I use hard drives like floppies in a tool-less dock in one case. It's useful if you carry drives off-site. -- I'm sure it's even possible to craft a sort of nuke-carrying submarine-style system where you insert a hard drive and then a specific usb stick, and then get prompted with a password. Too many moving parts for me to care about, but it's a cool idea. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mutuality and harmlessness
--- This is a bike shed topic for me. Incoming bullshittery. :) --- On Sat, 24 Nov 2018 12:15:39 +0100 Martin Steigerwald wrote: > Now > what happens if I let go any belief that some of them are true or > right, preferably my own, and some of them are false or wrong, > preferably those of apparent others? What is beyond true or false, > beyond right or wrong, beyond black or white, beyond left or right? > What if, just what if this world is not binary, like a computer? What > if, just what if this world has all the different colors and none of > them are right or wrong? The binary is real. Without it, you never know if you are wholly wrong. You pretend you cannot ever be wholly wrong, and demand that nobody tells you when you are. You never get help correcting, or can even think to self-correct. You never improve. You never examine ethics or philosophies and aspire to greatness. You close yourself off, becoming bigoted by demanding open acceptance to your unwillingness to pursuit it. Core philosophies absent of permanent-improvement are poison to the self, and when they are enforced for others, even and especially "to protect them", they are cancer to others. Being wrong is common, (even normal before becoming less-wrong). Being told one is wrong should be normalized. Accepting one is wrong should be desirable. Going from being told one is wrong to being helped to be right should is .. Good. There must be a wrong and a right. -- Nobody loves you who withholds their opinion to save your ego. The thing of it is that the more antagonistic someone is, without trolling (e.g. they have expertise you accept), the more terrifying their criticism becomes. "Oh shit, what if LVM+encryption+btrfs really _is_ a hot mess that solves problems I don't have and gives benefits I don't use by introducing risks I can't recover from?" Yes the problem is that they and their communication are not tailored to your tender needs, but also that one demands being treated tenderly in the first place by pretending that being wholly wrong isn't a thing. ___ 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
Roger, I appreciate you taking the time for the explanation of the flow of logic driving the developments. It adds some depth that the average user, like me is not normally exposed to. I remember doing installations with various partitions for directories, as much for coolness as anything, paper install manuals pointed the way. I don't know if I represent the average use case, but now days other than swap and UEFI stuff, I just keep /home in a separate partition, spinning on its own when I can. Thanks, Clarke ___ 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
Roger: ... > There's no clean separation between the "base" system and "everything else". ... I think my urge to have a separate /usr is that I want such a separation and there isn't a clear other place to have it. > The other part of the scenario you mentioned here is "doesn't want to > use an initramfs". Why? ... I skip initrd to keep the boot setup simple. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden ___ 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 24/11/2018 02:45, Steve Litt wrote: On Wed, 21 Nov 2018 12:17:21 + Roger Leigh wrote: Some general points to consider: 1) A separate /usr serves no practical purpose on a Debian/Devuan system Historically, /usr was separately mountable, shareable over NFS. With a package manager like dpkg, / and /usr are an integrated, managed whole. Sharing over NFS is not practical since the managed files span both parts, and you can't split the package database between separate systems. What I hear in the preceding paragraph is that dpkg considers / and /usr a package deal (no pun intended), and so can't abide an NFS mounted /usr. Telling people to merge / and /usr for this reason is fixing the symptom and letting the root cause remain. That's usually not a good idea, but perhaps in this case fixing dpkg would be too difficult... This part isn't a problem with the dpkg tool itself. It's down to the content of packages not having a clean separation between / and /usr. Programs, libraries and data on both sides of the split are mutually interdependent upon the other. KatolaZ illustrated this nicely in his last post with library dependencies across the divide. (This was forbidden before the MountUsrInInitramfs work.) There's no clean separation between the "base" system and "everything else". You can absolutely mount /usr over NFS. But it's not very practical to share that filesystem between multiple systems. And it isn't a very useful configuration choice compared with other possibilities. If you want to use NFS, you can mount the rootfs over NFS (including /usr). It's a simpler, more practical arrangement, and it's exactly what tools like debian-live do (for example). Contrast this with the BSDs where there's a defined "base system" and then a separate and largely independent collection of packages under /usr/local. But even on the BSDs, the primary split is between / and /usr/local, not / and /usr. /usr/local/etc and /usr/local/var exist, while /usr/etc and /usr/var do not exist on Debian (or FreeBSD); they go on the rootfs, which is one of the causes of the tight coupling. And it's not necessarily a bad thing. It's simply a part of the basic design of Debian that we've accepted for over two decades. Take a copy of e.g. http://mirrorservice.org/sites/ftp.freebsd.org/pub/FreeBSD/releases/amd64/12.0-RC1/base.txz The "base" is the content of / and /usr from a single build of the base source tree. While there's a separate static /rescue and it's technically possible to mount /usr separately (there's similar convoluted logic in the initscripts to what Debian used to have), the system as provided is a collection encompassing both. Because it's not (yet) managed by a true package manager, you could actually set this up in the traditional way if you wished, and share a static /usr between several systems. But it might still interact badly with freebsd-update (not tested it myself), and it's planned to come under the remit of the pkg package manager in time, so like Debian it may run into logistical problems due to the package management. Modern disk sizes make partitioning a separate /usr unnecessary and undesirable. (Both are of course /possible/, but there is precious little to gain by doing so.) Well, *you* might not want a mounted /usr, and *I* certainly don't want a mounted /usr, but we don't speak for every user in every context, and we can't anticipate every context. So "serves no purpose" as a blanket statement is false if we find one person using or wanting to use a separate /usr on a De??an system. Absolutely. However, "wanting" to use a separate /usr doesn't imply that the reasons for that desire are sound or reasonable. This is why I very much would like to know the underlying rationale for each use. Some may be genuinely valid. Others may not be. But we need to be able to objectively evaluate each one to determine this. If you look back in the debian-devel and other list archives 5-7 years back or more, this was discussed on several occasions, and it was increasingly a struggle to identify genuinely valid use cases. Some were bad. Others were valid, but... pointless. Over the years, the need for a separate /usr has weakened. Most of the time, a single root partition is just fine, and this is the default for the installer, and the way the vast majority of people run their systems. For these people, a separate /usr doesn't solve any of their problems. Several of the uses are borne out of habit rather than necessity. The sharing of /usr over NFS is an instructive one. In discussions a few years back, this was brought up as a valid use case. One or two users and developers brought this possibility up. Some people claimed to be working with this setup. But when questioned about how they actually made it work, it came down to doing rather custom and fragile stuff outside the package manager. It turned
[DNG] Mutuality and harmlessness
Dear readers, After all what I let go and what I learned in the process of doing so, I totally agree with had I heard during some recordings I used. There are two essential aspects for any relationship: Mutuality and harmlessness. In the current discussions on this list I have seen a great lack in harmlessness. I feel uneasy about posting to this list, cause I absolutely do not enjoy receiving a mail with a personal attack. I still dare to write this mail as I know I can let go of any hurt. Also I am free to tell my mail server to block mails from persons attacking me or unsubscribe at any time. However I certainly prefer dng-ml being a supportive and safe space for discussing all things Devuan. I commit to contribute to that by letting go, by carefully writing mails and by speaking my own truth. I commit to let go wanting to control any other's experience, opinion, belief or preference – especially as there are no other. It is not upon me to tell someone else what to think, what to believe, what to propose or what to agree with. So I commit to agree to disagree wherever there is disagreement or different opinions. That appears to happen a lot in this human condition. Ask ten people about anything and you are very likely to get different answers. Now what happens if I let go any belief that some of them are true or right, preferably my own, and some of them are false or wrong, preferably those of apparent others? What is beyond true or false, beyond right or wrong, beyond black or white, beyond left or right? What if, just what if this world is not binary, like a computer? What if, just what if this world has all the different colors and none of them are right or wrong? Thank you. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
