Re: [DNG] etckeeper: was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
On 10/18/21 4:36 PM, Steve Litt wrote: Olaf Meeuwissen said on Mon, 18 Oct 2021 18:52:05 +0900 I keep track of /etc with etckeeper which puts that directory under git version control. That means I can always track back changes to package updates or me mucking around there and see exactly what changed. That can be very helpful if an `apt upgrade` broke stuff, more so because I track "testing" ;-) Nice!!! I run on a BTRFS file system and /etc is in it's on sub volume. I just take a snapshot of it. restoration is as easy as overwriting a file or folder from the snapshot. I store the snapshots both locally and externally. Works great. I handle /var/lib/mysql that way, too. Cheers, Curtis SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ 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] FHS deficiencies: Was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
Olaf Meeuwissen said on Mon, 18 Oct 2021 18:52:05 +0900 >Hi Steve, > >Steve Litt writes: >> On more thing. When *I* write a program, I never put it in /usr/bin >> or /usr/local/bin or /opt. I have my own directory, called /d/bats >> (last century it was called D:\BATS when I used Windows), to contain >> all executables [snip] >Might I suggest $HOME/bin :-) ~/bin isn't ideal for two reasons: 1) It's integrated with all sorts of config, cache, and who knows what, and can easily be lost or wiped out in a re-installation. 2) On a *personal* computer, a place to store all self developed data is needed. I have nothing against the standard File Hierarchy System (FHS) for servers. It works, it's stood the test of time for 40 years, and it's standard. How different things are on a *personal* computer. On a server, it's all about the computer (virtual or metal), and the user is incidental. On the personal computer, it's all about the user, and the computer is incidental. On a server, it's just fine (sort of) to store all locally developed and/or used data, config and executables under /usr/local. But on a personal computer I sure wouldn't want to store my stuff in a directory owned by root, or under a directory owned by root. I want it in a directory fully navagable by slitt all the way down. So isn't that what /home/slitt is for? Not really. /home/slitt is a huge, disorganized mess with data, config, cache, and all sorts of other stuff. /home/slitt gets destroyed in every clean install, so I have a choice: 1) Do a mass copy of the old /home/slitt tree to the new one, and probably mess up programs whose config system has changed. 2) One by one search the tree for non-config files that are made by Steve Litt. That this is time consuming is an annoyance. That it's error prone is very, very bad. There's also the matter of backup. Do I really want to back up 40,000 files worth of cache to back up my home grown data? Not this iteration of Steve Litt. About /home/slitt/bin: Wel, maybe, but if I need a place to put all homegrown anyway, why not put my executables there too, and just put it on my executable path? So I personally defy FHS by creating /d, owned by Steve Litt, to contain all my home grown data, programs, config for those programs, etc. It's really a minor violation of FHS, but it does me immense good. 90% of what I use a computer for is backed up from one tree and laid back down in that tree. My programs. My books. My copy of the Troubleshooters.Com website, and my various other websites. All in one tree, ready to back up or restore at a moment's notice, and small enough to put on some fairly small media, without cache files and downloaded files to bloat me up to Blu-Ray size. My stuff under /d is the important stuff, the stuff whose loss would put me out of business. Losing the other stuff would be in inconvenience. I actually violate FHS in a lot of other ways, which I won't elaborate, to granularize my backup and restore. This works because I'm the one and only user. Some Personal Computer owners shouldn't do this because they're not cognizant of different kinds of data. They should probably do it the FHS way and figure out some backup system, probably brute force back up all drives, to accommodate their backup needs. But for the "power user", FHS violations can be helpful and don't do any harm. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] etckeeper: was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
Olaf Meeuwissen said on Mon, 18 Oct 2021 18:52:05 +0900 >I keep track of /etc with etckeeper which puts that directory under git >version control. That means I can always track back changes to package >updates or me mucking around there and see exactly what changed. That >can be very helpful if an `apt upgrade` broke stuff, more so because I >track "testing" ;-) Nice!!! SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Er, Not that way ? (was: Announcing Devuan 4.0: Chimaera!)
On Mon, 18 Oct 2021 18:52:05 +0900 Olaf Meeuwissen via Dng wrote: > Might I suggest $HOME/bin :-) For me I've only had a few offline custom scripts in: $HOME/live/path If I thought about it further, I'd probably make it something more obvious, like: $HOME/live/scripts/sh/in-path Since I share (on GitHub), a crazy large number are in: /live/OS/shell-random/git/live/sh/scripts /live/OS/shell-random/git/live/zsh/scripts I use live/zombie/dead because I use terms from tabletop roleplaying necromancy to help visualize my data. > It's been 20+ years since "last century" ... I felt that. :( ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] snetaid debs...
On 2021-10-18 10:07, Edward Bartolo via Dng wrote: The name "snetaid" made me remember of my now defunct project. Searching on the project's git repository I found it has been removed, so, it is dead and forgotten. Edward Hi Edward, Nice to see that you are still hanging around Devuan. When we moved from gitlab to gitea, contributing developers were given multiple reminders and ample time to migrate their projects to the new format. Many projects fell by the wayside from lack of attention and action on the part of their creators. Isn't Aitor's project based on your work? If so, it is still alive and well! Take care, golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] snetaid debs...
Dear Devuan Developers and Users, First a well deserved thanks goes to all developers who dedicate their precious time to the development of Devuan. Second, my thanks goes to all users. The name "snetaid" made me remember of my now defunct project. Searching on the project's git repository I found it has been removed, so, it is dead and forgotten. I am still using my "broken" version of simple-netaid-backend. The GUI frontend required me to do some changes including giving file access to some protected directories. The use of a more stringent kernel based file security model, apparmor, broke both the backend and GUI frontend. I know I can disable apparmor, but that is not good security practice. So, I am using only the backend as root, and it works for me. The backend is something which I have written although it has flaws and was never truly completed. The main issue I see is, it assumes that to "automatically connect" means to connect with the most powerful wifi signal, which, honestly, is not always correct. Edward ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Warning about Wicd in Chimaera
On Thu, Oct 14, 2021 at 05:47:06PM -0400, Hendrik Boom wrote: > There's no wicd in Chimaera. > If you need it to access the internet, you must replace it with another > network manager *before* you upgrade to chimaera, otherwise you'll not be > able to access the internet to download the replacement network manager > after. I have added a transitional wicd package (1.7.4+tb2-6+devuan2) to chimaera-proposed-updates that, I hope, will help smooth this over. I would be grateful for confirmation that it works to ensure an alternative network manager is installed if you are upgrading from a beowulf system that has wicd installed. To test, before upgrading and when changing sources.list, also add deb http://deb.devuan.org/devuan chimaera-proposed-updates main Note that is is important to use http://deb.devuan.org/devuan rather than http://deb.devuan.org/merged. Thanks Mark ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
Hi Steve,
Steve Litt writes:
> Hendrik Boom said on Sun, 17 Oct 2021 11:55:56 -0400
>
>>On Sun, Oct 17, 2021 at 07:56:47AM -0400, . via Dng wrote:
>>> On 10/17/21 07:48, terryc wrote:
>
> [snip]
>
>>> Well, it can't hurt to try another update/upgrade cycle; I had a
>>> konsole open during the last reboot and it was restored, so I can do
>>> command-line things (and what else could I possibly need :-) If that
>>> doesn't fix things up then it's nuke-and-repave time.
>>
>>I've learned it's useful to repeat upgrades and dist-upgrandes and an
>>occasinoal aptitude until nothing happens AND there are no errors
>>reported.
>
> When dealing with non-rolling releases, and maybe even rolling releases
> in certain circumstances, I'm a fan of nuke-and-repave for major
> versions. This is because I'm an elder in the Church of the Known State,
> and a brand new install is an opportunity to achieve a known state. This
> tends to limit the ghosts of versions past.
Catharsis has its place ;-)
Major distro releases are a good time to consider them although I tend
to skip one (or two) because of the work involved starting from scratch
(even with backups to refer back to).
> Obviously, at least one complete, known good and known restorable
> backup must be taken before this. In addition, before this, the results
> of mount, lshw (as root), and whatever package management command gives
> you the packages installed manually, as opposed to those installed only
> as dependencies. If possible, also print the output of mount and lshw.
The stuff I typically back up is everything below /etc, /usr/local,
/home, /opt and /srv. I also check there's nothing left in
/var/spool/*, especially /var/spool/mail (symlinks to /var/mail, btw).
Then I collect the output of
apt-mark showmanual # for the stuff I explicitly installed
and one of
dpkg --get-selections # for what I intended to have installed
apt list --installed # for everything that's installed
As for capturing the output of mount, that should be covered by
/etc/fstab. If none of the hardware changes, then lshw might not
be needed and besides the installer will log a lot more below
/var/log/installer/.
> Then install the new major version, then install all your backed up
> *data*, as opposed to OS or package supplied *programs*, then install
> all the packages on the list of manually installed packages. What I
> generally do is copy the list of packages to a shellscript, convert it
> to package install commands, comment them all out, and then uncomment
> ten at a time to install them. Why ten at a time? So if something goes
> wrong you can find it, and so it doesn't take hours.
My list of manually installed packages is typically not all that long.
On my Xfce4 laptop (which pulls in Recommends:) there are only 120 and
quite a few of them are there to keep packages installed that were
installed by the installer already.
# BTW, I normally just install a console system with the installer and
# add the rest later on an as needed basis. That is, I don't select a
# desktop environment or any "standard" packages in the installer.
After installation, I typically run
apt-mark auto $(dpkg-query -W -f '${Package} ')
to mark *everything* automatically installed and then iterate over the
list of packages that
apt --auto-remove purge
would nuke to arrive at a list of packages I really need/want.
> After that, take a backup of the new system including /etc and
> $HOME, then restore *strategic* config files from /etc/ and ~ and
> ~/.config. By strategic, I mean configs that you hand-crafted.
> Sometimes it's better to copy your hand-crafting into current
> package-installed config files. I find this especially true of Dovecot.
I keep track of /etc with etckeeper which puts that directory under git
version control. That means I can always track back changes to package
updates or me mucking around there and see exactly what changed. That
can be very helpful if an `apt upgrade` broke stuff, more so because I
track "testing" ;-)
> On more thing. When *I* write a program, I never put it in /usr/bin or
> /usr/local/bin or /opt. I have my own directory, called /d/bats (last
> century it was called D:\BATS when I used Windows), to contain all
> executables (including shellscripts and perl/python/ruby/lua/ and the
> like) written by me. You can certainly name that directory differently,
> but it's a directory containing your executables and only your
> executables, so it restores with your personal data, and is not
> molested by anything in the upgrade. Obviously, this directory is on
> the system's executable path.In DOS, Windows, and Linux this segregation
> of executables written by me has served me extremely well. I'd suggest
> you do it too.
Might I suggest $HOME/bin :-)
It's been 20+ years since "last century" ...
If you need these scripts to be usable by other users on your system,
I'd go with /usr/local/bin (which I would backup).
Hope this helps,
--
Olaf
Re: [DNG] ultrabook boot issues - hybrid hard disk
Hi Riccardo, Riccardo Mottola via Dng writes: > I have installed Chimaera on my Ultrabook - first as beta, then > upgraded constantly. The system has a dual-disk setup under windows > called smart cache or fast cache. One spinning rust and one smaller > SSD. ON windows the two drives are one as one with a cache. That sounds a lot like my Dell Vostro 3360 at the office, apart from the fact that it doesn't have Windows (anymore, I zeroed both disks ;-). > Actually, when installing linux, they are seen as two drives, sda and > sdb. I thought, originally, to install on the SSD disk so to have a > fast boot system and the rest of apps and user directories on spinning > rust. However, I could not even partition the SSD, it always gave > errors. SO I installed everything on sda. I had delays at boot > however, later. I vaguely remember something about not being able to "use" my SSD but forgot the details. Whatever they were, letting dd if=/dev/zero of=/dev/sdb bs=4M run until it complained about no disk space left fixed it for me. Of course, if you want to keep that other OS around, that's not really an option but I thought I'd mention it anyway. Just a thought, I may also have fiddled with the BIOS to make it boot from the SSD before trying the HDD and made sure I installed GRUB in the MBR of the SSD. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
Le 17/10/2021 à 20:44, Steve Litt a écrit : > Hendrik Boom said on Sun, 17 Oct 2021 11:55:56 -0400 > >> On Sun, Oct 17, 2021 at 07:56:47AM -0400, . via Dng wrote: >>> On 10/17/21 07:48, terryc wrote: > [snip] > >>> Well, it can't hurt to try another update/upgrade cycle; I had a >>> konsole open during the last reboot and it was restored, so I can do >>> command-line things (and what else could I possibly need:-) If that >>> doesn't fix things up then it's nuke-and-repave time. >> I've learned it's useful to repeat upgrades and dist-upgrandes and an >> occasinoal aptitude until nothing happens AND there are no errors >> reported. Thanks. I discovered there remains a lot to upgrade/install after the reboot! I use to also insert 'apt-get autoremove --purge' in between. > When dealing with non-rolling releases, and maybe even rolling releases > in certain circumstances, I'm a fan of nuke-and-repave for major > versions. This is because I'm an elder in the Church of the Known State, > and a brand new install is an opportunity to achieve a known state. This > tends to limit the ghosts of versions past. I agree with you. Sometimes it's good to restart fromscratch. It's also an opportunity to make hardware changes. Two systems upgraded to Chimaera these days. All looks fine. Thanks to the great team. -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
