Puppy Linux Discussion Forum

I am going to go get new tires for the automobile, so I will add more later, but I've been working a lot with the www-data:root or spot:root model. This way I can have the many packages that will only run as non-root user yet still be able to access as the root user those files at the group level that belong to the user other than root.

Also to note, most of the Puppy Linux installations of Zoneminder do not use root but use the www-data:www-data and mysql:mysql users for the LAMP or LHMP. OR another combination that satisfies ZM preference to operate as any other user rather than root, is to use the built in webuser:webgroup for the web server plus ZM and mysql:mysql for the database server.

Zoneminder is not set up to run well as root since it is mainly controlled from a web console and is built to stream video and receive data from a network. With the APT plugin and the PAM it is even more in-line with ZM's prefrence of running as user www-data, webuser, weedog or daemon

Every Puppy Linux web server I set up does not use root as the primary user for web server connections. Apache and Hiawatha don't like it.

Threw together a quick WDL_Devuan64 (beowulf) using the dev version of build_firstrib_rootfs and build_weedog_initrd scripts and it connected fine via wiakwifi and posting from it now (using installed chromium). Currently also just has jwm, lxterminal, mtpaint, and scrot. Using WeeDog initrd with overlayfs frugal install functionality of course. Currently using uncompressed 01firstrib_rootfs since easy to hack during dev work.

I'm not really interested in WDL_Devuan64 itself (though works fine and also allows me to fix up build_firstrib_rootfs for Ubuntu and Debian future builds) but wanted it because its the host system I need for now producing a small WDLGO_Devuan64 system along with dpkg_apt_PAM addons as a side-production that can be used with Devuan beowulf Puppy productions.

wiak

@wiak
Nice!

Once I have the dev versions of all the build scripts finalised and checked out I'll upload them to git. Then, once I'm not playing with them myself, I'm thinking of writing a "Build WeeDogLinux Tutorial/Booklet" with examples for some of the various 'flavours'.

The fact is, that FirstRib WeeDog is really quite a simple toolkit for building frugal installable distros of now tons of different types with no limit to how big or small or what user wants to include. The point I'd like to get across, which being somewhat busy I've probably not managed to convince anyone about yet(!), is that it is really a simple process to build a WeeDogLinux distro and no-one should be afraid to try, whatever their experience with Linux more generally - you don't even need to really know how to write shell scripts, though that's useful of course. If a person ever uses the commandline, then basically, they should be able to build a WDL distro - just need an empty folder, download the build script or scripts, run that, wait for the build to complete, and adjust your grub3dos menu.lst or grub2 grub.conf configuration and all should work. Want to add to the build (prior to building) then simply add some extra entries to the build plugin (extra app installs, applications or desktop configurations, or whatever).

Of course, we all end up with some issue or another (missing firmware or grub syntax wrong, or ...) but help always available here. What's particularly useful about WeeDog (apart from its pretty flexible overlayfs-based initrd) is that a user can start with a very small limited build (just to see how it works) and then incrementally expand to a full desktop, piece by piece, and it's thus also a very educational experience (and that is the case for myself too - I learn a lot just by building systems using WeeDog build scripts and adding stuff via the build plugin). The end result is as good (or bad) as you make it... and you can always polish it up later (and expand it or slim it down). The critical core build scripts themselves are more slowly developed, and carefully tested by myself before their release, but I'm always open to ideas for new features though no guarantee about what I'd adopt - having said that, all the core build scripts contain quite flexible user-plugin expansion capability, which is the preferred method of build system expansion more generally. Outside of the core build script creation most of the hard work in practice (and for me too) is the main build recipe which is pretty much entirely a user-created plugin (f_whatever.plug) - that plugin provides the overall distro design and it is entirely created by users (which could include myself of course). I wrote the f_XXX.plug for WDL_Arch64 but the WDL_Void32 f_XXX.plug is written by rockedge.

Easier of course to concentrate on one WDL build system type (be it Void, Arch, Ubuntu, Debian, or Devuan) but because the basic build process is much the same for all of these it becomes pretty easy to build vastly different systems without feeling it is over-powering to master so many distro flavours. Good to have someone become the 'expert' on each build type/flavour though since all upstream repos have their own package management methodologies to master, though it is also important to have resident 'experts' on particular desktop managers - for example, I know a fair amount about setting up openbox (the Arch Linux way anyway) but next to nothing personally about setting up JWM...

In terms of developing WeeDogLinux systems, the more 'developers' the better of course ('developer' for WeeDogLinux meaning ANYONE willing to try/modify any build), since we all benefit from any and all new creations/systems/knowledge-sharing, though once again I stress that you don't need to be a guru to work on the build of your own WeeDogLinux creation - most anyone using the Puppy forum is perfectly able to develop a new WeeDog either by modifying or extending existing build plugins, which are often not much more than a list of package manager install app commands, plus any useful configurations you learn/duckduckgo about on the way (which is basically how I do it, and via Arch Linux wiki and similar, along with, as I've previously mentioned, cherrytree hierarchical notetaker as my brain/memory - notecase would similarly do for that really). I do use git, but usually only commit new stuff to that after a lot of hacking around - so knowledge of git is not at all required for WeeDog development, without denying I like git for final result updates, but my overall dev approach is much less formal so you don't need to know anything about git at all to develop WeeDogLinux distros. In fact I do not want git pushes/issues and so on (I simply wouldn't read these since I'm hardly ever 'there') - I prefer just discussing matters on this main forum since everyone can then be involved.

Anyway, back to my dev build script polishing alongside the WDLGO_Devuan64 current project...

wiak

I received a PM from Clarity asking if WDL systems could be provided in iso format. I explained that some already are (e.g. rockedge's WDL_Void32 and the expanding WDLGO series) but that WDL_Arch64 is not only rather large (around 1.5GB) but also a rolling distro (hence iso becomes stale almost as soon as it is produced resulting in pacman update redownloading all packages anyway). However I added the following note, which may end up being a way of conveniently providing a full desktop system, which is booted via the originally provided small iso:

@Clarity:

It is perfectly possible to build a distro even smaller than a traditional Pup or DebianDog by starting with a WDLGO (iso-provided) system, such as WDLGO_Focal64. Once I have all my latest build scripts in order and pushed up to WeeDogLinux gitlab, and finished a dpkg_apt_multiuserPAM addon for recent DevuanPup, I may therefore first concentrate on WDLGO_Focal64 (and Hirsute Hippo thereafter), building it up to a usable desktop in tutorial fashion. That way, the user can start with the extremely small WDLGO_Focal64 iso (which is bootable per the method you prefer) and then, following an instructional tutorial, easily build it up to full desktop status (allowing them to customise it on the way); furthermore, for those who don't want to bother entering lists of simple commands, or following a tutorial, I will be able to also provide small downloadable scripts (simpler even than a delta) to build the simple WDLGO_Focal64 automatically up to full desktop status - could even make that a one-quick operation (so rather like a QuickPet but for more than one app/configuration). People like rockedge would certainly be able to usefully help out with the details (e.g. JWM/Rox configurations - though alternatives such as Openbox/tint2/pcmanfm could also be discussed/provided). One again, iso contents soon become dated, but since only a small initial iso (which is easy to regularly update as a download anyway) the save folder update to that will be equally small and I really should also work on a similar WDLGO_Arch64, and so on.

Note that with such a small initial system, it would be relatively straightforward to also work on a modified initrd version that uses symlink sfs loading mechanisms (instead of overlayfs or in addition to it), such as the tinycorelinux mechanism preferred by wanderer, though looks like, for a while at least, I'd be too busy overall to dabble with that personally.

So after that WDL_DevuanBeowulf64 build I made, I've also made Ubuntu Focal and Debian Buster firstrib_rootfs builds - simply because I'm checking latest build_firstrib_rootfs script prior to uploading to gitlab. That's all going fine, but, I don't know if I'm misleading myself somehow because its so late at night here at the moment, and I'm tired, but the debootstrap-based Ubuntu Focal and Debian Buster both have an unexpected filesystem hierarchy compared to what I was expecting. Basically, both turned out a bit like Arch Linux with /bin now being a symlink to /usr/bin, and /lib a symlink to /usr/lib. That's great in many ways if it is true since makes PATH handling much simpler, but it is different to what I was expecting (different from the FossaPup and FossaDog distros that I have isos of, for example). I'll have to double-check and, if they have adopted that new filesystem hierarchy, I'll have to think what, if any changes, that makes concerning other matters handled by FirstRib WeeDog build scripts. I previously arranged WDLGO_Focal64 to use same FS hierarchy as the versions of FossaDog and FossaPup I have, assuming the former was same as upstream Ubuntu Focal since I think fredx181 uses debootstrap as a starting point too.

For making the dpkg_apt_PAM addon for FossaPup, it is important I use same FS hierarchy, but overall I want WDLGO_Focal64 to be same as upstream FS hierarchy, so I'll have to double check the situation overall.

I'm also planning to look into EFI boot capability for next WDLGO iso releases (I have access to a newer laptop so is a good time for me to do that).

A bit off topic, so I'll probably rename the topic later since I'm using it simply as a blog of updates I'm doing:

Currently, basically translating my f_00_Arch_amd64-openboxFull.plug to create almost identical version of same for Ubuntu, Debian, Devuan, and Void. I'm hoping the overall structural/configuration parts of that end up being basically identical since will make future development of these multiple distros much easier. Things going well so far. Have Ubuntu, Debian, and Devuan up to boot to commandline stage and beginning to merge in the f_00_Arch... extras, but first now checking Void flavour build up to same commandline stage and then try to build all of these up to the f_00_Arch_amd64-openboxFull.plug full desktop status.

Since the build for all of these uses the same build_firstrib_rootfs script, these ongoing build developments are also part of developing/testing that overall build script and then I run build_weedog_initrd on resulting firstrib_rootfs/ to produce the bootable systems for each of the above, which thus also allows me to tweak/develop/test that build_weedog_initrd script so that it works correctly with all above WDL distro variants.

Somewhat in parallel, I'm also further testing new build_firstrib_rootfs_lgo script, which is the WDLGO ultra slim distro builder script. It is a specially modified version of main build_firstrib_rootfs script, made for special WDLGO (lego-like) distro production. In practice I expect to be able to create f_ plugins for these simpler WDLGO systems that also allows them to be built up, in a finer grained manner, to full f_00_Arch_amd64-openboxFull.plug desktop status. Main difference overall being the ability to more easily produce cutdown versions of WeeDogLinux variants, an option that I feel is particularly useful for use in virtual machines and/or containers and similar. The WDLGO build is also what is used to produce, as an optional side-product, dpkg_apt_multiuserPAM sfs addons for some Puppy systems.

A lot of work going on in the background therefore, and it will be some time before next products are released, and probably not everything at once... First will come the latest build_firstrib_rootfs and build_weedog_initrd scripts probably, and possibly some of the WDLGO variants, such as a WDLGO_Devuan64 will follow thereafter (along perhaps with dpkg_apt sfs addon for DevuanPup. So when... I don't know yet since I prefer to do a lot of testing on my own prior to initial release.

wiak

@wiak excellent progress. Meanwhile I've been putting the Fossapup64 apt addon through as much stress as can think of. So far so good and the system still surprises me with it's resilience.
It is something else being able to install packages with 3 different package managers. Some stuff is just easier with the PPM some much better being installed with Pkg and then there is APT to make things simple when following recipes for Ubuntu or Debian.

I am in the process of renaming all of my WeeDog -Void plug files to the new naming format so they will work. The systems the plugs produce you have seen and are not that complex. The original idea was to make a couple of plug files that actually make a system that works, but also was an example of how it works. A template for some more serious creations. So I will name the existing plug files to make them usable by the Build scripts.

The potential of these OS's as virtual machines and chroot'ed or containerized is big.

All of my plug files will be available on github.

Looking forward to building a Void variant with your recent advances in technology.

In yesterday's tests, commandline builds for Ubuntu, Debian and Devuan worked fine using the new build_firstrib_rootfs and build_weedog_initrd scripts.

Have just completed an WDL_Arch64 build (and booted it) using the same new scripts, so all seems fine thus far.

Currently working on commandline WDL_Void64 build. Assuming that works with no issues I should be at the stage of uploading these new build scripts (version 3.0.0 -rc1) up to WeeDogLinux gitlab. Only truly major change is for build_weedog_initrd being that firmware/modules can be provided as separate 00fw_mods sfs file or as an uncompressed directory - previously that particular resource could only be in sfs format. Also fixed errors in previous build_firstrib_rootfs that prevented builds of Ubuntu, Debian, and Devuan working properly.

I've also fixed the f_build_plugins for Ubuntu, Debian, and Devuan such that no manual tweaks are required to login as root/root and use the bootable result (and connect via wiakwifi).

I'll try to make the Void f_plugin as similar in content and form to the Debian-based WDL distros as possible. Thereafter, as I said, I'll expand these all these variant plugins to try and clone the overall structure, content, and configuration as the existing full desktop WDL_Arch64 f_XXX.plug. I expect that last stage will take a while. Thereafter I'll get back to the separate build_firstrib_rootfs_lgo script, which is for the special WDLGO systems.

I have a feeling this could be a very productive year for WeeDogLinux. Once all the above are created I may well produce iso versions to help anyone interested try out WDL as a pre-configured system (I'll have to look into EFI boot capability as part of that). Finally, I'll look into producing some userland utilities that leverage the functionality available from WeeDogLinux initrd/init in terms of utilising upper_changes to best effect (e.g. for rollback or merging of a series of upper_changes sessions). And perhaps also some sfs-load on the fly facility via tinycorelinux-type symlink sfs loading mechanism.

Continuing to polish up latest build scripts for gitlab release.

Then will get back to considering EFI boot possibilities, and

planning to release WDL_Arch64 as an iso (and perhaps Ubuntu Focal version of much the same once ready), but will check first with rockedge for iso storage space since these are full desktop with latest full inkscape, gimp, libre-office+java, Chromium, and more 1.5GB distros. I 'could' remove some of these larger apps, but main reason the isos are bigger than typical cut-down distros is the fuller firmware provided. Cutting down no longer so worthwhile IMO (considering how big hard drives and usb sticks are nowadays) and in my experience WDL_Arch64 runs at least as fast (and at least as little RAM consumed) as all the rest aside from maybe WDL_Void creations. I like Arch base since well-tested rolling release provides nicely up-to-date apps, kernel, and libs, but that far works very efficiently on my old HP Elitebook 2530P core2duo machine of vintage circa 2008.

For those interested in very slimmed down (but full official package manager systems) then I'd recommend working on provided WDLGO systems (around 20MiB download). I will be providing alternative distro flavours/versions of these later later (currently UbuntuFocal64 only) and will keep them up-to-date. Later I'll think about user tools for creating even more flexibility in terms of merging upper_changes save folders/remastering/managing-rollback-saves etc - should also be able (or anyone so interested) to work on tools for creating slimmed down versions of the larger isos. Rather a lot to do though so contributors welcome as usual.

@wiak,
A quick report during an extended run of the WDLGO_UbuntuFocal64 mini-apt/dpkg experimental system built into a Fossapup64.

The add on SFS module and small modifications have been working solidly since first inception of blending a Fossapup64 to run a full version of the APT package manager. I just completed a complete system update/upgrade, including bringing the ZoneMinder installation to version 1.37.21 master and the process appears to have completed successfully.

Overall the experimental WDLGO_UbuntuFocal64 mini-apt/dpkg add-on has been a complete success

Good to hear that is still working okay - the supplied dpkg/apt related files within it are pretty old versions now of course, however, presumably able to upgrade themselves!

I had thought there would be a Phil version of JammyPup that I would end up providing an dpkg/apt addon for (as part of a very small WDL_Jammy release, however haven't seen that Pup appear. Neither has small WDL_Jammy release, the making of which automatically creates that dpkg/apt addon as a side-effect of the way I produce such, but there is a fair chance it will eventually (including the newest WDL initrd of course).

My opinion was, that it was appropriate Puppy design to leave it to contain its own cross-Puppy package manager (be that PPM, pkg, or whatever) and to only include the upstream repo official package managers via an optional addon. Having said that, I feel a bit differently about VoidPup since xbps as a package manager seems to fit in many ways into what was Puppy approach to packaging in smaller pieces (with Debian I think the dependencies tend to be larger - not so optional, but maybe I'm wrong about that). I also feel that VoidPup is a very different beast from say KLV-Airedale, so very useful in its own right.