How to Build a Locked-Down Installation of Puppy
rcrsn51 I like your approach.. Looks nice.. I think I have another method, any thoughts or ideas are welcome... It is not yet made, or tested, although I see no problems in making this a reality.
Anyway... Here's the method:
I plan to make a 'kiosk' (locked down) mode for puppy, by editing the initrd.gz and adding a new pfix option ('pfix=kiosk', of course)... Booting with 'pfix=kiosk' will add an entry into /etc/PUPSTATE (as I believe this is already done from the init script), that says KIOSK=true.
If KIOSK=true, the save interval in the Puppy Event Manager wil be forced to zero (no scheduled saves).. Also, rc.shutdown will be updated, so that it checks for kiosk mode in PUPSTATE and skips saving to the save file at shutdown.
I also have made a 'delaysave' pfix option, which simply forces PUPMODE 13 into PUPMODE 12 - which disables real-time saving to the save file. Kiosk mode, which must also force the 'delaysave' option, would create a locked-down puppy, that can be enabled and disabled at boot, regardless of which save file is being used.
This is much more complicated than your method, but I think it's really quite flexible, and I will give it a go! Just thought I'd share the approach that I was thinking of using, take it or leave it!
Hope I'm not invading the thread!
Anyway... Here's the method:
I plan to make a 'kiosk' (locked down) mode for puppy, by editing the initrd.gz and adding a new pfix option ('pfix=kiosk', of course)... Booting with 'pfix=kiosk' will add an entry into /etc/PUPSTATE (as I believe this is already done from the init script), that says KIOSK=true.
If KIOSK=true, the save interval in the Puppy Event Manager wil be forced to zero (no scheduled saves).. Also, rc.shutdown will be updated, so that it checks for kiosk mode in PUPSTATE and skips saving to the save file at shutdown.
I also have made a 'delaysave' pfix option, which simply forces PUPMODE 13 into PUPMODE 12 - which disables real-time saving to the save file. Kiosk mode, which must also force the 'delaysave' option, would create a locked-down puppy, that can be enabled and disabled at boot, regardless of which save file is being used.
This is much more complicated than your method, but I think it's really quite flexible, and I will give it a go! Just thought I'd share the approach that I was thinking of using, take it or leave it!
Hope I'm not invading the thread!
Last edited by sc0ttman on Sun 22 May 2011, 22:21, edited 2 times in total.
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]
The reason is that a /mnt/data directory doesn't exist in my fugal install. so I created one, ie: a data directory along with the nested directory puppy520, inside this I copied the file macpup_save.bak and edited the initrd entry accordingly.
only thing is (I know you guessed it!) the darn sav.bak file is never read or copied at boot time..
Must be related to it's location, which is why I wondered about the significance of the data directory.
I need to go back to square one I think.. and RTFM
only thing is (I know you guessed it!) the darn sav.bak file is never read or copied at boot time..
Must be related to it's location, which is why I wondered about the significance of the data directory.
I need to go back to square one I think.. and RTFM
Windows users are used to copying files from locations like C: to D:.Indy'spup wrote:this data directory?
mount /dev/sda1 /mnt/data
cp /mnt/data/puppy431/pup_save.bak /mnt/data/puppy431/pup_save.2fs
umount /mnt/data
But in Linux, you have to mount a partition before you can work with the files in it. You can think of a mount point as being a door that gives you access to the files in a partition. (Have you seen the children's movie Monsters Inc.?)
Since all Puppies have a predefined mount point named /mnt/data, the script uses it to copy the file pup_save.bak to pup_save.2fs.
There is nothing special about /mnt/data. You can use any directory as a mount point.
lol ok I understand I'm not looking in the correct places 90% of the time
sorry for hijacking the thread, maybe a moderator can move my posts back to my original thread..?
Meanwhile, is this a valid entry?
#######END MODULE LOADING TO ACCESS DRIVES##########
mount /mnt/sda1/puppy520
cp /mnt/sda1/puppy520/macpup_save.bak /mnt/sda1/puppy520/macpup_save.2fs
umount /mnt/sda1/puppy520
#########FINDING PUPPY FILES#############
sorry for hijacking the thread, maybe a moderator can move my posts back to my original thread..?
Meanwhile, is this a valid entry?
#######END MODULE LOADING TO ACCESS DRIVES##########
mount /mnt/sda1/puppy520
cp /mnt/sda1/puppy520/macpup_save.bak /mnt/sda1/puppy520/macpup_save.2fs
umount /mnt/sda1/puppy520
#########FINDING PUPPY FILES#############
This is correct.
Code: Select all
mount /dev/sda1 /mnt/data
cp /mnt/data/puppy520/macpup_save.bak /mnt/data/puppy520/macpup_save.2fs
umount /mnt/data
I've been under the impression that puppy will load any save file which ends in .2fs now I'm not so sure of that criteria..
Am also not so sure it was wise to configure the puppy installation saved to the puppy save file prior to editing the initrd script..
Since I've not been successful in keeping the save file after a reboot I've commented out the changes in the initrd script until I can get puppy to load the save file previously created..
brb
Am also not so sure it was wise to configure the puppy installation saved to the puppy save file prior to editing the initrd script..
Since I've not been successful in keeping the save file after a reboot I've commented out the changes in the initrd script until I can get puppy to load the save file previously created..
brb
Ok all back to normal frugal install loading previously configured save file at boot and initrd edited and corrected as per earlier post.
moving along to the next phase; I noticed the "Data" directory is infact available at boot now so does the renamed save.bak file need to be moved to this location (data directory)?
Ok Disregard that!! I think the Data directory is a pointer to the home directory because without moving save files the whole deal is working as published
YAY!!
just took forever getting there for a noob!! Thanks rcrsn51 for your patience
moving along to the next phase; I noticed the "Data" directory is infact available at boot now so does the renamed save.bak file need to be moved to this location (data directory)?
Ok Disregard that!! I think the Data directory is a pointer to the home directory because without moving save files the whole deal is working as published
YAY!!
just took forever getting there for a noob!! Thanks rcrsn51 for your patience
Last edited by Indy'spup on Sun 22 May 2011, 23:56, edited 2 times in total.
????Indy'spup wrote:moving along to the next phase; I noticed the "Data" directory is infact available at boot now so does the renamed save.bak file need to be moved to this location (data directory)?
It sounds like you made a "Data" directory either in /mnt/sda1 or in /mnt/home. This is incorrect. The mount point /mnt/data already exists in your Puppy filesystem.
You don't need to change anything else. What is the "next phase" to which you want to move?
Just so I understand what the heck just happened..
the mount point already exists, ok I understand that.
but the mount point is empty? yet the script copies the *save.bak file to the same empty location and renamed it *save.3fs
during boot up puppy loaded the newly created *save.3fs into memory and the file is found in the home directory. I think there is some hard linking going on??
the mount point already exists, ok I understand that.
but the mount point is empty? yet the script copies the *save.bak file to the same empty location and renamed it *save.3fs
during boot up puppy loaded the newly created *save.3fs into memory and the file is found in the home directory. I think there is some hard linking going on??
Ok how about this one.
in the /mnt/home/puppy520 directory i have two files (but others also) namely a *save.bak & *save.3fs
Q1 at every reboot puppy will overwrite the *save.3fs with the contents of *save.bak But what if the contents did not change? is the file overwritten regardless? What about a "What if" statement to compare if a change has been made then skip overwrite if they're the same?
Q2 if I need to make a change to the system AFAIK I need to delete the *save.bak file - make the changes and reboot saving to the *save.3fs file - On reboot to the live cd I only need to rename the *save.3fs file to *save.bak then reboot without saving changes (with respect to the live cd) correct??
Q3 Is puppy aware of save file name changes? eg is puppy expecting a specific save file as previously saved or if perhaps the name was changed via a live cd, will puppy load the *save file so long as it has a *.3fs or *.2fs file extension??
Q4 Are the 2fs or 3fs save file extensions reflective of the file system used within the save file??
in the /mnt/home/puppy520 directory i have two files (but others also) namely a *save.bak & *save.3fs
Q1 at every reboot puppy will overwrite the *save.3fs with the contents of *save.bak But what if the contents did not change? is the file overwritten regardless? What about a "What if" statement to compare if a change has been made then skip overwrite if they're the same?
Q2 if I need to make a change to the system AFAIK I need to delete the *save.bak file - make the changes and reboot saving to the *save.3fs file - On reboot to the live cd I only need to rename the *save.3fs file to *save.bak then reboot without saving changes (with respect to the live cd) correct??
Q3 Is puppy aware of save file name changes? eg is puppy expecting a specific save file as previously saved or if perhaps the name was changed via a live cd, will puppy load the *save file so long as it has a *.3fs or *.2fs file extension??
Q4 Are the 2fs or 3fs save file extensions reflective of the file system used within the save file??
Yes. The lines of code you added to the initrd don't check to see if the save file changed in the previous session. But it only takes a few seconds to overwrite the file.Indy'spup wrote:Q1 at every reboot puppy will overwrite the *save.3fs with the contents of *save.bak But what if the contents did not change? is the file overwritten regardless?
That sounds too complicated. When you make a change to the system, that change is immediately stored in the save.3fs. To "lock in" that change, boot off the Live CD, mount the Puppy partition and copy the current save.3fs over top of the save.bak file. Then reboot.Q2 if I need to make a change to the system AFAIK I need to delete the *save.bak file - make the changes and reboot saving to the *save.3fs file - On reboot to the live cd I only need to rename the *save.3fs file to *save.bak then reboot without saving changes (with respect to the live cd) correct??
Each Puppy version is coded to look for a savefile with a particular name. In your case it's either macpup_save.2fs or .3fs. If it finds other files that it thinks might also be savefiles, it gives you a menu.Q3 Is puppy aware of save file name changes? eg is puppy expecting a specific save file as previously saved or if perhaps the name was changed via a live cd, will puppy load the *save file so long as it has a *.3fs or *.2fs file extension??
I guess that depends on the size of the save file and how slow the equipment.. for me this took a minute approximately - a small price to pay but am thinking a changed save file is more rare than it is a daily occurrence is all..rcrsn51 wrote:Yes. The lines of code you added to the initrd don't check to see if the save file changed in the previous session. But it only takes a few seconds to overwrite the file.Indy'spup wrote:Q1 at every reboot puppy will overwrite the *save.3fs with the contents of *save.bak But what if the contents did not change? is the file overwritten regardless?
I agree, less steps are betterThat sounds too complicated. When you make a change to the system, that change is immediately stored in the save.3fs. To "lock in" that change, boot off the Live CD, mount the Puppy partition and copy the current save.3fs over top of the save.bak file. Then reboot.Q2 if I need to make a change to the system AFAIK I need to delete the *save.bak file - make the changes and reboot saving to the *save.3fs file - On reboot to the live cd I only need to rename the *save.3fs file to *save.bak then reboot without saving changes (with respect to the live cd) correct??
Interesting, thanks..Each Puppy version is coded to look for a savefile with a particular name. In your case it's either macpup_save.2fs or .3fs. If it finds other files that it thinks might also be savefiles, it gives you a menu.Q3 Is puppy aware of save file name changes? eg is puppy expecting a specific save file as previously saved or if perhaps the name was changed via a live cd, will puppy load the *save file so long as it has a *.3fs or *.2fs file extension??
sorry i kept returning to add more to each question, but what of Q4 ??