From WeeDogLinux: dpkg_apt_multiuserPAM for Puppy (experimental)

[wiak]

Was previously provided in forum area now designated Puppy-only.
No longer available. But being further developed in WDL-only developers' area

Get download script and usage details for various (being added to) Pups as below.

For BionicPup32: https://weedoglinux.rockedge.org/viewto ... p=335#p335

For FossaPup64: http://weedoglinux.rockedge.org/viewtop ... p=336#p336

[rockedge]

I went ahead and set up Bionic32 and apt is working in the first version check.
My problem is Bionic32 is not finding eth0 or eth1. This machine has 2 separate network cards and so far every Puppy and every WeeDog has had no issues finding the devices.

I feel like a firmware problem is the cause, and something is not loading. But I have not yet looked into it much.
Been busy restoring the little modifications that customized and adjusted the forum software since this last update over wrote a significant number of the 10482 files that make up forum's code. Many of the changes are small and 1 or 2 values or 2-5 lines of added php code so remembering what I did last year is vague and am reduced to examining the backups when something pops up. I may have broken the fixes for the responsive CSS for mobile device page parsing. I have not even gone there yet.
So while I wanted to pass the time through this snow blizzard attempting to get the Bionic32 plugins working and install Zoneminder and the LAMP, instead I've worked through the day to track down those changes we've made and get them back into the new versions of code.

[wiak]

So while I wanted to pass the time through this snow blizzard attempting to get the Bionic32 plugins working and install Zoneminder and the LAMP, instead I've worked through the day to track down those changes we've made and get them back into the new versions of code.

That's fair enough, rockedge. In fact I noticed from other threads how busy you were with forum update matters which is why I just went ahead and published the BionicPup32 addon without testing results. Does sound like ethernet firmware issue on your machine with BionicPup32 - the dpkg/apt addon has no effect on that of course. My machine uses module e1000e for ethernet and all works fine. You'll need to track down what ethernet firmware your machine needs (maybe via some other OS that successfully connects using it.

[wiak]

download/main-description locations for both FossaPup64 and BionicPup32 dpkg_apt addons can now be found in first post of this thread:

viewtopic.php?p=16601#p16601

I'm assuming at the moment that FossaPup32 dpkg_apt addon would be less useful and similarly BionicPup64 dpkg_apt addon since supplied BionicPup32 addon likely to be more useful for older 32bit machines and newer machines unlikely to use FossaPup32 (actually I haven't even checked if there is a 32bit version of FossaPup, but I presume there might be). Please let me know, and depending on overall interest I'll consider making other builds in the near future.

[rockedge]

@wiak I need to run some tests after I dig out of the 16 inches or 40.64 cm of snow to get the wife to work. Kindergarten teacher. But the machine I'm working with runs 7 other frugal set ups of Bionic32 and none have eth0 connection problems. This is the first Puppy that is not even detecting the devices.

To check upupbb32+25 I'll set it up side by side it in it's pristine state and check the net connectivity

[rockedge]

I have a test system all set to go! There was some connectivity issues with the Bionic32 +25 that I am using, but after a kernel swap to 5.6.4-rt3 (i686) that I compiled for Puppy the OS connected automatically at during reboot.

Next step is to install Apache2 with APT and add my configurations for the Hiawatha web sever built into Puppy. Hiawatha is one of the best and most secure web servers made and available.
Next comes the PHP7 install with apt. MySQL server I'll do as the 3rd step. I'll install WordPress and see how it functions.
4th step is the Zoneminder installation with APT. I've had really good luck with the Beta firstrib_rootfs.sfs system in Fossapup64 and I've had great performance from Zoneminder in Bionic32 so this will be a good overall test of the apt_sfs_load_bionic_i386.sfs add on. The PAM capability is what many using ZM on other OS's will be interested in.

There will be a follow up report!

[rockedge]

@wiak
I've run into problems with adduser!

Code: Select all

# adduser _apt --force-badname
Allowing use of questionable username.
Adding user `_apt' ...
Adding new group `_apt' (1003) ...
Adding new user `_apt' (1004) with group `_apt' ...
Creating home directory `/home/_apt' ...
Copying files from `/etc/skel' ...
passwd: pam_start() failed, error 26
Try again? [y/N]
chfn: PAM: Critical error - immediate abort
adduser: `/usr/bin/chfn _apt' returned error code 1. Exiting.

Code: Select all

# adduser www-data
Adding user `www-data' ...
Adding new group `www-data' (1004) ...
Adding new user `www-data' (1005) with group `www-data' ...
Creating home directory `/home/www-data' ...
Copying files from `/etc/skel' ...
passwd: pam_start() failed, error 26
Try again? [y/N] 
chfn: PAM: Critical error - immediate abort
adduser: `/usr/bin/chfn www-data' returned error code 1. Exiting.

Code: Select all

# adduser www-data
adduser: The user `www-data' already exists.
# passwd www-data
passwd: pam_start() failed, error 26

going to try:

Code: Select all

apt --fix-broken install

[wiak]

Doubt it has anything to do with the issue you are experiencing (I didn't get such problems) but I am re-uploading the bionicpup32 addon because I noticed something else that puppy symlinks that pure ubuntu does not so I'm modifying the addon filesystem to match that of Puppy. Will post once new download is ready. Unfortunately Puppy makes things much more difficult by using upstream Ubuntu repos but not adopting upstream filesystem hierarchy, so I can't guarantee I'll get it Puppy-like right - not this time round anyway

[wiak]

Make sure when you install the addon you follow the instructions carefully rockedge. It is important that the apt_adrvXXX file ends up being a Puppy adrv... and only the apt_sfs_load...sfs should be loaded via sfs_load! Otherwise you will not correctly overwrite the puppyXXX.sfs adduser busybox version.

i.e. You must not use Puppy sfs_load to load both addon sfs files - that will not work! The adrv one must replace the original puppy adrv (the original puppy adrv being renamed first to ydrv........).

Not sure if that was the cause of the error you had. Anyway, don't try yet since I still have to fix BionicPup32 dpkg_apt filesystem hierarchy to better match the Puppy one... Will post once download ready again. FossaPup addon should be okay though.

I will fix the FossaPup addon if something remains wrong with Puppy FS hierarchy with respect to official Ubuntu FS hierarchy, but for BionicPup32 I'm less likely to bother. It is too frustrating trying to match old Puppy not following Ubuntu FS hierarchy (despite relying on upstream Ubuntu repos) - that was a poor design decision on Puppy's part though apparently addressed at last in FossaPup release. There may be other non-UbuntuFS-compliant aspects of FossaPup FS, I don't know - e.g. I'm not sure about the symlink /usr/lib/terminfo used in FossaPup, but that maybe not a problem causer... (I don't have official Ubuntu on this machine to check if they have that one, or if it matters anyway)

[wiak]

@wiak
I've run into problems with adduser!

Yes, I can confirm the issue. Actually, nothing is working for me with any of these addons at the moment so I think I may have broken the build script somehow. It's odd because I've definitely had them all working at one point... Alas, I'm a bit unwell at the moment so having to come back to it sometime later.

[rockedge]

Alas, I'm a bit unwell at the moment so having to come back to it sometime later.

I am instantly concerned when read this. Hang in there and get some fresh air and rest.

Somewhere something is slightly amiss....can't be more than something simple and overlooked, since I have Fossapup64 fully loaded running with the firstrib_rootfs.sfs and APT is installing everything I've thrown at it so far. And Zoneminder is running smoothly with all it's complexity.

So I am confident the problems that arose will be slain as any other Orc from Mordor...stormtroopers sent by the Empire.......or those pesky dragons we all know live in New Zealand.

[wiak]

Modified the fossapup dpkg/apt addon but only to remove the no longer required firstrib static busybox.

It seems to be working to install that isaac connor master zoneminder (though I amended instructions to add gnupg and apt-add his 'public key' so no issues with apt update - alas apt prompty install the systemd pollution that wrecks underlying Pup when done that way... New instructions roughly added to howto post:

viewtopic.php?p=15747#p15747

Probably needs some more work, but I'll be away for a few days. Bionic32 addon will have to wait - maybe unresolvable because of Bionic Puppy using symlinks for lib locations unlike actual Debian/Ubuntu hierarchy (FossaPup changed to Ubuntu hierarchy so should be fine) though I thought I had that one working at one stage... to be determined later...

What is needed is a fix-it-back-to-non-systemd-Puppy-script for after running apt install since I see no way anyone could guarantee some systemd components won't be installed sometimes... seems pretty regular occurrence though maybe some kind of apt pinning could be used to protect underlying Pup system, though I wouldn't know enough about that. Up to some Puppian to work such measures out since I want to concentrate on WDL since I have tons enough to do there... Main thing is that dpkg_apt addon works and works well (at least for latest FossaPup organisation) - protecting against systemd-pollution, or fixing it (which is surely not a huge task - just need to re-write effected Puppy system scripts/files or maybe 'pin' some dummy systemd files to fool apt into not re-installing systemd components), should be a good project for someone (assuming anyone else cares to use apt with Puppy that is...)

[rockedge]

Set up a Fossapup64 and using the apt_sfs_load_fossa_amd64.sfs loaded via SFS_Load_on_the_fly. With the adrv renamed as ydrv and the replacement adrv in place for loading during the boot process.

Completed the steps for installing the LAMP and then Zoneminder after creating the needed user's and the installation completed SUCCESSFULLY.

Also added xscreensaver with apt and using run-as-spot to start it also is working 100%.

So far all the installations made by APT have gone well. Also the errors I experienced running

Code: Select all

pkg repo-update

are not occurring and Pkg is functioning as expected. PPM is also working and can uninstall and install.
Only Pkg and PPM know what each other have done with APT keeping it's own records.

But this is acceptable in this system because the main tests were to install a LAMP and Zoneminder correctly with APT, which has happened, along with some extra packages for good measure.

Next test will be :

Code: Select all

apt update
apt upgrade

though so far this test has not had good results, the tests were run on a system similar but not as stable as this version is.

[s243a]

At some point I might get around to learning how to use pam but I will note that on debain the "passwd" package seems to require pam. Presumably puppy gets around this by using a busybox version. I'm guessing that some package install scripts expect the full version of "passwd". Perhaps if someone didn't want to use pam the required functionality could be emulated via a wrapper script to the busybox version but at the cost of losing whatever security advantages that pam provides.

I am interested in a more security intense version of puppy and for that reason I was looking at puli. On puli I was not able to run ungoogled-chromium without the --no-sandbox option. The chromium sandbox may have been incompatible with the older libs (the latest version of Puli is Xenial). The error message did mention a suid sandbox. However, I think this is a deprecated option. One way to do a suid sandbox is with firejail. Firejail can also be integrated with apparmor with is a kernal security feature. I think that debain based distros prefer selinux over apparmor and while debain packages have dependencies for selinux, I don't think that puppy uses any of the selinux features. As a consequence selinux adds some bloat (maybe very small) to debain/ubuntu versions of puppy without providing any of the security benefits.

[wiak]

I've been away for some days and just returned home. Some things to catch up with around the house but then I'll get back to WDLGO since I wan't to double check the build script to see if BionicPup32 variant is a no-go or not - seemed to work at one stage, but thereafter definitely not - so I just want to make sure I didn't mess up when trying to create a special variant. Fossa dpkg_apt addon version seems fine (within the limitations caused by some packages messing up Puppy via systemd additions...). Good that Puppy woof-CE team seems to have moved towards using Debian filesystem arrangement now and presumably for future Pups. Certainly WDLGO will continue to produce latest Ubuntu-release versions (and could relatively easily provide similar for Debian-release variants) so nice if these can also be easily adapted as dpkg_apt_PAM addons for newer Pups, which will be the case if newer pups continue with Debian-compatible filesystems.

[wiak]

I may have fixed the dpkg_apt_multiuserPAM addon for BionicPup32. Please find download script in first post of this thread:

https://weedoglinux.rockedge.org/viewto ... p=335#p335

Note that I wasn't able to test it with zoneminder install because isaac connor ppa didn't seem to be providing an i386 compile (or maybe most recent wasn't ready?).

I did however:

Code: Select all

apt upgrade
apt install nano
apt install mpv
apt install simplescreenrecorder

as a quick test.

I have been away till a couple of days ago and going away for a few more days tomorrow, but at least able to leave this for you to try out and play with!

The same double-sfs files should be able to be used to upgrade older systems. The key is that adrv loads above the puppyXXX.sfs so anything put in that new WDLGO adrv addon can be used to overwrite default puppy libs. At the moment all such WDLGO libs are in apt_sfs_loadXXX.sfs so anyone experimenting with upgrading older systems would have to manually move them across and then resquash the filesystems. As provided, however, the double-sfs are ready for immediate use as dpkg_apt_multiuserPAM addon.

wiak

[mikeslr]

Hi Guys,
An obstacle has hindered my understanding your conversation. Having run across them before I could string together the terms dpkg_apt and multiuser and obtain a suspicion of what's involved. But I wasn't familiar with the acronym PAM. So taking a page from Mark Twain's Encounter with an Interviewer, I googled for a picture. I'm still at a loss. Could you kindly identify to which of these PAM's you're referring?

PAM.png (175.38 KiB) Viewed 1350 times

Your response may make a difference as to how much further interest I devote to a multiuserPAM.

[rockedge]

Linux-PAM is a system of libraries that handle the authentication tasks of applications
(services) on the system.

http://manpages.ubuntu.com/manpages/bio ... PAM.7.html

basically it is for multi-user systems, like those that do not run regularly as "root"! (Like Ubuntu, Debian in most cases)

Linux-PAM separates the tasks of authentication into four independent management groups:
account management; authentication management; password management; and session
management.

[mikeslr]

Ah, thanks. I didn't think of limiting my google-search with the qualification 'linux'.
dpkg_apt_multiuserPAM isn't quite as exciting as I might have hoped. And I have to wonder whether dpkg_apt_multiuserPAM is also a red-head.

To paraphrase Mel Brooks, I think: "Never let the plot get in the way of a joke."

[rockedge]

I'll ask the wife...she's a red head, about what she knows!

Ready to begin a test run with Bionic32-8+25 with the latest version I call Bionic32+25-A.
Set up as follows:

Screenshot(22).png (22.96 KiB) Viewed 1332 times

I renamed the orginal adrv as ydrv then inserted the renamed apt_adrv_bionic.sfs to replace it.
Loading of the apt_sfs_load_bionic_i386.sfs will be done after booting and by using SFS-Load-on-the-fly

Booting went smoothly as did loading the SFS. All systems are running and have everything prepared and pre-installed to do a full LAMP and Zoneminder install. I changed the iconner PPA from focal to bionic in the file
/etc/apt/source.list

I was able to apt update and install gnup with apt install worked flawlessly. Have also a successful error free installation of Apache2 and PHP 7 and both are up and running. Used:

Code: Select all

apt install apache2 php php-cgi

I have included PHP-CGI for using Hiawatha instead of Apache for the web server component. Hiawatha is updated to v10.11 from Here

[rockedge]

Finalized the mysql-server and Zoneminder installation. Went really well using APT.

Screenshot.png (101.48 KiB) Viewed 1491 times

[wiak]

Could you kindly identify to which of these PAM's you're referring?PAM.png
Your response may make a difference as to how much further interest I devote to a multiuserPAM.

It is the one in the photo on the right. If you don't have multiuser it means PAM can't also use your computer

[rockedge]

Rebooted from terminal with

Code: Select all

busybox reboot

And the reboot resulted in a kernel panic!
Working on finding out the why this is happening. Disappointing but I went ahead and moved the save folder and the system booted right up and APT is working.

This time I will note the steps to install more detailed and do the rename trick and not the command line busybox reboot

[wiak]

Rebooted from terminal with

Code: Select all

busybox reboot

And the reboot resulted in a kernel panic!
Working on finding out the why this is happening. Disappointing but I went ahead and moved the save folder and the system booted right up and APT is working.

This time I will note the steps to install more detailed and do the rename trick and not the command line busybox reboot

Sounds like /sbin/init has been moved to systemd by apt. What we really need is person who works with Puppy to determine in detail what scripts Puppy calls at boot time for SysVinit. Then it should be easy matter to reinstate these boot files (or appropriate symlinks to them) each time apt is used. Certainly, apt does not, I've found, always install systemd - will depend on the package being installed and its dpkg-provided dependencies, but it would be a failsafe procedure if a post-apt-script was always called that fixed any boot script alterations that apt/dpkg has made - probably not much involved, but I don't myself use Puppy other than for quick experiments to provide new apps/utilities or now this potential dpkg/apt/PAM addon.

Do know that Puppy calls a BarryK script for /sbin/init, but I think some other scripts/config-files probably get whacked by systemd-related installations. The alternative would be to alter systemd scripts to include Puppy-necessary stuff (i.e. turning Puppy into systemd booted distro) but that is probably much trickier to do and not wanted by most.

[s243a]

Rebooted from terminal with

Code: Select all

busybox reboot

And the reboot resulted in a kernel panic!
Working on finding out the why this is happening. Disappointing but I went ahead and moved the save folder and the system booted right up and APT is working.

This time I will note the steps to install more detailed and do the rename trick and not the command line busybox reboot

Sounds like /sbin/init has been moved to systemd by apt. What we really need is person who works with Puppy to determine in detail what scripts Puppy calls at boot time for SysVinit.

This is based on older code but it might give you an idea:

woof-next/woof-code/rootfs-packages/puppycore_sysinit/
woof-next/woof-code/rootfs-packages/puppycore_sysinit_net/
*from my version of woof-next, which isn't ready for general use.

Code: Select all

 Then it should be easy matter to reinstate these boot files (or appropriate symlinks to them) each time apt is used. Certainly, apt does not, I've found, always install systemd - will depend on the package being installed and its dpkg-provided dependencies, but it would be a failsafe procedure if a post-apt-script was always called that fixed any boot script alterations that apt/dpkg has made -

Alternatively, you can create dummy packages and then lock the related packages such as upstart and systemd. This is done in woof-next.

Here is the lock function

Code: Select all

# $@-pkg to lock
lock_pkg() {
	if [ $WITHOUT_DPKG ]; then
		# dpkg-less lock method
		while [ "$1" ]; do
			sed -i -e "/^Package: ${1}\$/,/^$/ {/^Status:/ s/install/hold/}" "$CHROOT_DIR$ADMIN_DIR/status"	
			shift
		done
	else
		# use dpkg to lock it
		while [ "$1" ]; do
			echo "$1" hold
			shift
		done | dpkg --root=$CHROOT_DIR --admindir=$CHROOT_DIR$ADMIN_DIR --set-selections
	fi
}

s243a/woof-next/.../woof-next/builders/deb-build.sh#L579

and the code to create a dummy package:

Code: Select all

### so that apt-get is happy
# $1 dummy pkgname. Note dependencies of dummy packages are not pulled.
install_dummy() {
	set -x
	while [ "$1" ]; do
		get_pkg_info "$1"; shift
		[ -z $PKG ] && continue
		is_already_installed $PKG && continue
		echo Installing dummy for $PKG ...
		echo "/." > "$CHROOT_DIR$ADMIN_DIR/info/${PKG}.list"
		update_pkg_status "$PKG" "$PKGPRIO" "$PKGSECTION" "$PKGVER" ""
	done
	set +x
}

/s243a/woof-next/.../builders/deb-build.sh#L596

In addition to locking systemd we should also create dummy packages and lock the following: upstart, SysVinit and libc6.

Code: Select all

  probably not much involved, but I don't myself use Puppy other than for quick experiments to provide new apps/utilities or now this potential dpkg/apt/PAM addon.

Do know that Puppy calls a BarryK script for /sbin/init, but I think some other scripts/config-files probably get whacked by systemd-related installations. The alternative would be to alter systemd scripts to include Puppy-necessary stuff (i.e. turning Puppy into systemd booted distro) but that is probably much trickier to do and not wanted by most.
[/quote]

[rockedge]

I was able to repair the save folder by replacing the links for init, poweroff, reboot with the ones from the main puppy file system sfs.
Although I am have connection issues to sort out since the incorrect reboot occured.

The LAMP and Zoneminder are working but not tested to any serious degree but can't communicate with the Internet until I find out why and what. The network cameras work, so it is some config.

Found out that the /etc/resolv.conf was replaced by a symlink to systemd. I renamed this file and copied a fresh Puppy version from the backup and all is good and the browsers can reach the forum!

[wiak]

@rockedgeThat's good that you've identified the Puppy system files that systemd-related installation upset.

@s243aYes, locking dpkg via dummy packages to protect against unwanted systemd and, as you say, unwanted glibc updates would be good way to handle things. Only issue, I can only imagine, might be if something then doesn't get installed that is needed by the likes of zoneminder, but I wouldn't know.

I won't myself be working on such fixit-improvements since (asides from not knowing much about Puppy system scripts), for one thing, I'm not a major Puppy user but just like to help out where I see a possibility (be it with app or utility version for Pup, or, in this case an addon for dpkg_apt_PAM), but mainly because I am short of time for WeeDogLinux developments so I want to get back to that.

What I am planning to do, however, assuming Puppy users are clearly finding current addons useful, is to create similar dpkg_apt Puppy addon for next version of Ubuntu once it becomes stable, and I'm considering later making one for DevuanPup since that should have no systemd issues by default of course.

Basically, looks like the addons work so anyone wanting to use these or improve there compatibility with Puppy can now hopefully do so. I certainly encourage anyone so inclined to tailor the end result to make it work more flawlessly with the Puppy target system and I'll happily add links/documentation to any final 'fixit-after-apt' solution thus created.

[rockedge]

After sorting out the symlinks to remove in /sbin and /etc/resolv.conf, the system seems to be running very well.
Now will experiment with installing Pkg and installing something small from the PPM. Also this Bionic32 is running a kernel I compiled for 32 bit, 5.0.1

Screenshot(1).png (43.88 KiB) Viewed 1421 times

Screenshot(4).png (13.02 KiB) Viewed 1420 times

[wiak]

Currently (slightly) working on related WDLGO system, so may result in improvement to dpkg_apt_multiuserPAM addons. Will likely post copy to WDL developers' storage area plus any script updates once I've checked all looking good. Not sure whether I'll produce further dpkg_apt public releases though since not posting to Puppy areas any more, but will continue with main WDLGO systems for possible re-release later if I feel sufficiently inspired still.

Admittedly, I find my overall development efforts slowed to a crawl just now - find myself a bit fed up doing Linux-related work at the moment - maybe cos its winter approaching, so winter discontent. Hopefully will get back to some of it more actively later I hope (I'm still pushed by my family to work on WDL_Ubuntu version of WDL_Arch64 still and by my sons to train them more in maintaining/developing WDL - I guess I'll have to eventually... Not currently high priority though).

[wiak]

Hmmm... So today I discovered a wee bluetooth receiver (audio plug output) for NZ$2 in what we call a 2 dollar shop. Was like a usb flash stick with a 3mm audio socket. Bought it, took it home, plugged it into a usb port on my main machine (which I do all dev work on), plugged computer speakers into it, switched on my android phone bluetooth, connected to the new device, played a youtube video, yeah... the sound played through the computer speakers... success!!! Then, for the first time in history of me using it, WDL_Arch64 crashed. ?????!!!!!!!!!!!!!!!!!! All I was using it for was to provide power to the bluetooth receiver... oops.... it wasn't a usb port that says it supplied power (never thought that wee BT receiver would need much - seems I was wrong...

Result: my computer generally seems fine (posting from it now), but... the SSD 128GB hard drive is fried... I guess something to do with usb voltage shorting out and somehow taking the drive with it... I have lost heaps of work (yes, I have github for most scripts, but not the WDLGO ones, which I hadn't posted up yet... I do have some kind of backups I had emailed to myself every now and then, but goodness knows what versions...). Such is life - it has been a bad week or two for me dev wise. Definitely time for a break and to consider what is worth doing still. Meanwhile I better start searching for a new cheap SSD drive - currently swapped in a spare 32GB SSD just to get my machine basically running - busy installing WDL_Arch64 on that again. I lost so much though that I don't even really know what I lost - thank goodness for email, and for the bits and pieces on my google drive, and for github WDL site (incomplete though it is) - WDLGO has definitely suffered a blow though and likelihood of further dpkg_apt next Ubuntu release for Puppy even less likely for me to bother with since some of my notes have probably evaporated (though should have relatively recent cherrytree notes for a lot of stuff up on google drive - time will tell - I should have been more careful with backups and with that dodgy bluetooth dongle...).