Puppy Linux Discussion Forum

[nooby]

[sickgut]

A shameless bump....

Just checking in to let you guys know i havent abandoned this project or anything... pussy will go ahead as planned... the info i promised to upload to my site has been delayed due to more seizure activity and its a real problem not being able to look at a screen for more than a few minutes.
it may be yet another few days before im back again, i just hope in the meantime the pussy doesnt go cold.

please know that i have not abandoned the project and when i return i fully intend on pumping this pussy for all its worth

[saintless]

Take care of your health, Sickgut and don't worry.
I'm sure a few more people are busy with testing and shaping pussy linux for their needs and will share the results here.

Now I'm learning how to work with mksquashfs and unsquashfs because it is new to me. This kernel modules folder is 75Mb uncompressed. It will free a lot of space if we don't need it in every separate squash file.

Maybe we should think about combining 1-filesystem and 2-base squash files into one main squash file. I don't see a reason to keep them separate. You have the 1-filesystem.squash in the server edition and if somone need it separate he can get it from there.

I'm testing different WM called LXDE. It looks promising as JWM alternative. I don't mean to change the default JWM. Just testing for more information.

[saintless]

This is my last code in grub with two changes:

[sickgut]

[jbv]

Samba is sorted

--[ Background ]--- For my setup, I intend to have a few domestic appliances (media players, TV's, Home Theater, etc) attach to my <insert distribution name here> server(s). Many of these devices don't play nice with security and I really want a clean setup on everything. I don't need or want to hide things from other family members and my network is secure from the outside world. All other machines in my place are WinXP, so most system stuff and copying files and the like will be done from WinXP. Basically, I just want my servers to be accessible from anything in my place without any hassle.

The following could be considered as very dangerous and a high security risk ... please use your own discretion.

This configures SAMBA in a manner that automatically allows any device to attach to the shared Public directory without any user logon or password. It also gives full root permissions to the device so all file read/write/create is exactly the same as if you had done it from the console as root.

[jbv]

Hi sickgut, saintless, aarf,

There is quite a bit of .squashfs space that can be freed-up by removing all of the hidden .wh files and directories also. From the bit of research I have done on these, they appear to be remnants from the aufs filesystem. They are needed while aufs and cow are doing their stuff however they aren't required afterwards.

The current "blind copy" of /cow also copies these.
They can be removed from all of the .squashfs files with no ill side affects I can see.

However, I think there are some more fundamental issues that needs to be addressed.

There are a few things being used in pussy that always write back to their configuration files and these end up in the .squashfs files. Quite often the result is undesirable as the final file that ends up in your .squashfs file isn't what you want or need, and you can spend quite a bit of time trying to work out what has just broken. From the little bit of playing I have done it seems to me that JWM and WICD are quite bad for this type of behavior.

I think the whole /var directory needs a bit of a re-think too. Now it could be my unfamiliarity with linux, but I'm sure that blindly copying /var is also having unintended consequences. Perhaps someone who really understands the /var directory can help out here and let us know what /var stuff should not be re-instated or saved into the .squashfs files. With my limited knowledge, it seems that /var/lock /var/log /var/run should not be saved and re-loaded. Are there others?

/var/cache is another interesting one.
With all of my apt-get install and then trimming, I've basically broken the apt-get database. apt-get still works but it is a little confused as to what I've already apt-got. Should this be kept separate?
From a distribution point of view, how do we handle this?

Is there a way I can rebuild or refresh the apt system so that it knows what has and hasn't been pulled down?

If I'm not mistaken, there may also be some broken links in the basic pussy. The worst offender seems to be /etc/ssl/certs I need to look a little deeper to see if I've broken these or even if they need to be there, but it does raise the question of are there more and what are the possible consequences?

should we run fslint over the base pussy?
How does pussy extra affect this sort of thing if you only load it once, do something and then perform a save?

The reason I'm thinking that loading extra can create issues is because I sometimes load it to build a package, snapshot the package and then cut-copy-past the resultant .squashfs file to slipstream the new package. I do this by renaming pussyextra.squashfs to be .squashfs.noload

Trying to keep this all clean and sorted is a bit messy and I'm pretty sure this is how I've broken my apt-get database/cache whatever. I really don't know exactly what the answer is yet.

I'm thinking it might be better/easier to keep the build system in a separate .squashfs and then mount it from a script, do my thing and then unmount it. Has anyone else given this any thought or are there any suggestions as to a nice clean way to handle this if you don't want the build system and associated stuff always loaded and accessible?

Cheers

[saintless]

Thanks for all this information, JBV
Apt-get must work 100% without problems on pussy linux. This is the main reason to have this OS.
I can't answer to your questions, but I did some unsquashing and squashing back yesterday. I put all the squash files + small fix squash file into one main squash. I copied 2 squash file over the first one, then 3 over the first one, then 4 over the first one and then 5 (my squash with fixes) over the first squash. I haven't shrink or trim anything inside.
While unsquashing 2-base and 4-extra there were some messages about can't unsquash because operation not permited. I think it was about hardlinks and some of those .wh files.
Anyway the result is one main squash file 608Mb and everything seems to work fine, including apt-get.

I think keeping everything needed for apt-get in the base squash file is a good idea. If we don't modify this base squash we can't broke the 100% apt-get compatibility.

[sickgut]

@jbv and others interested in squashiness and compressed save files etc.

The /var/run dir, wicd and JWM and other apps always write a new config file every time they are executed, this makes it to your save file. When making a compressed save file using the catroll-panel option to do so (dumping the contents of any existing compressed save into a dir, then the contents of /live/cow to the dir then resquashing) no matter how clean your system it you end up with 30 or so files in there like /etc/fstab, mtab, lighttpd conf, /var/run/* every thing that was changed or updated since you booted. This is ok for a save in a strict sense as your network settings (if you modified them) have been saved, any new jwm menu additions etc... this is how it should be... but this is far far far from ideal when all you want to do is just make an addon package for pussy, there is all kinda of junk copied there you dont need, and may infact screw up other peoples pussy when they run your squashfs on their system.

The compressed save file option isnt really a good way to make an application squashfs you intend to share unless you edit its contents (unsquashfs then delete all junk, then mksquashfs). If making a squashfs of a static application then its best to simply extract it and then make a squashfs out of it. If making a squashfs out of applications you have apt-getted and you want to keep the apt-get database intact then using the compressed save file method then a cleanup of junk is fine BUT it makes a difference if this package was made for the base or Xtra as to keep apt-get tracking happy, you need your own copy of the tracking system in the squashfs, and if made for the base os and is loaderd after it, this package must contain the base os apt-get tracking system as well as its own info.... if it just contains its own info then the base os's tracking system will be overwritten by the tracking system in this new squashfs.

In short:
1). We must keep the base OS and Xtra apt-get in tact, this lets us use apt-get anything we like.
2). Static packages like the cleanmode seamonkey and others are fine, these are often even cleaner than the apt-getted packages, and are simpler to manage and also remove.. I encourage Jbv to make his new samba package a static package for instance, i have no problem wih hosting it on the pussy site. Alot of users dont know how to setup samba and they would prefer an open system that works and this is the classic example of why preconfigured static packages are often better than apt-get ones. (simply removing any reference to dpkg/ apt from the squashfs will make it like a static package similar to seamonkey.squashfs that isnt registered with the apt system. Altho i have misused the word static here, as it probably scatters its files thoughout the filesystem not just one dir.. ) This requires no apt-get tracking system to be in the squashfs and so it doesnt really matter if it is used with the base or the xtra system or what order it gets loaded. This wont stop the user from "apt-get install samba" and reinstalling the entire samba package while the samba squashfs is there but pussy users arent idiots. We are covered if the samba squashfs package has a readme.txt or is accompanied by a readme.txt on the site its downloaded from, this will simply tell the users to use this samba package that is already working and configured OR apt-get samba yourself but dont do both. Note: the java package and assaultcube are static in the Xtra, the user can still apt-get java or assaultcube but this hasnt cause problems...

3). Altho apt-get is awesome and cool, sometimes there are better vendor released static packages than is available in the debian repos. In these cases we SHOULD use the static package, there is no real downside to static packages, only that the user must be aware that there is no need to apt-get install or apt-get remove something that they already have. Maybe we should have a static packagemanager in the catroll-panel. This would be easy to setup, when you make your packages that dont use the apt system you just put an uninstall script in /scripts somwhere that the catroll panel can link to.

[jbv]

Hi Guys,

sickgut, no problem with helping contribute a "clean" samba and documenting it. Give me a few days though. I think there may be a problem with cron that may have it's roots in the base pussy, but I need to dig deeper to suss this out. Currently the .sqf is 16.2Mb although I haven't tested against perfectly clean pussies and pussy base vs pussy extra, so there may be a little either way depending upon how that testing goes.

saintless, I'm not sure if you misunderstood my earlier message. I understand and agree that pussy needs to maintain 100% apt-get capability. I am not and never will advocate anything else.

apt-get is still working for me, although I have broken it's database or history. This is a self-inflicted wound and the result of my playing. I'll sort it although I think it does raise a potentially wider reaching issue that I can tell sickgut is and possibly always has been aware of. How or even if we address this needs to be considered. Anyway, that is one for next week (for me).

sickgut, there are a few things that I am trying to work out, but can't find the info easily. Perhaps you can help. Is there a document that tells me what directories Debian Squeeze Live has and what they are meant to hold? I am especially interested in the /var directory and in particular /var/lib/update-rc.d

Basically, I'm trying to work out if the stuff in the pussy base and pussy-extra really need to be there and if they have potential to create issues.

With regard to wicd and JWM, as you know, these definitely "touch" their config and hidden files which get included in snapshots. However, I'm not so sure about the benign nature of this touching and what always gets written to the snapshot.

With regard to the apt-get cache, I understand what you explained and had worked that out. I guess what I'm suggesting or asking from you as the Principle Architect is... Is this something we should or intend to address from a wider view? If so, we should give it some consideration now.

I'm all for creating some really clean and well documented .sqf add-ons that people can either use as-is or as the the basis for their custom injection (BTW, to me an "injection" is a .sqf that you eventually merge into one of the base .sqf files, so the stand-alone .sqf is no longer required) and I'm fine with the fact that this stand-alone .sqf or injection is external to apt-get.

However, this doesn't help those of us who are creating them
Where it starts to get really messy is when you are building packages from source code. I'm wondering if there isn't some way that we could put the apt-get database, build system and other tools into a dedicated .sqf that we can dynamically load, do whatever we need to do while it is loaded, then "refresh it" and put it back before unhooking (un-mounting) it. It may not be possible and I probably haven't explained it properly because in a way, I really don't know _exactly_ what we need yet. I'm really just throwing the idea out there for others playing as I am in the hope that between us we may be able to come up with an idea or two.

Cheers

[sickgut]

@ jbv

aaaah i get it now what you mean by injection. I think a system of merging all the squashfs on a system into one squashfs is great. Or atleast a system of merging additional squashfs into the OS squashfs.

sorry cant really help with issues related to building something from source code in pussy then making a squashfs from it, ive never done it. Absolutely everything in pussy right now is put together using binaries only. I have compiled some small things (mud text game and other things) using pussy xtra on a fresh system with no save but i have never added anything to the OS using such a method.

[jbv]

Hi sickgut,

I'm fine with the compiling and tools etc, and then cleaning the result to get a clean .sqf or injection file.

I guess what I was seeking was/is some direction (from an architectural viewpoint) on was how to handle apt-get and it's associated files.

It would be nice if we could hive off the apt-get stuff along with the original source files, build headers etc and then park them so you can just reload them when you want to add something else or freshen something. It isn't a big deal to manually mount a .squashfs file and it wouldn't take much to rebuild a replacement .squashfs with the "latest and up to date" source files, headers, apt files etc. when you're done. Then un-mount the build environment. The whole lot could probably be done with a two or perhaps three simple scripts.

I'm not really asking how to do it, but more of a "is it worth it" and what would be a good layout to use. I can and will work it out, but with my lack of familiarity with *nix and apt-get in general, anything I arrive at may not work out to be the most elegant from an architectural point of view. Sadly (for me), if this is the case you usually don't realise it until it is to late or you are in a deep hole. Then you've got to make a decision between throwing away a ton of work and starting from scratch or trying to dig your way out. Both of which are time consuming.

Perhaps someone else may have some ideas or I may work something out in a few days. I"ll give it a little more thought before I start digging


With regard to "pussy extras", you obviously just apt-got some stuff.
Can you let me know ALL of the things you apt-got to create "extras".

Cheers

[nooby]

Hope everybody take the following with a big pinch of salt.
I am a true pessimist so maybe or most likely I paint it too
dark.

but my experience of Linux Devs and especially those from
the big distros and Debian really is one of the most known
and big. Prestige and tradition and so on.

Why would them accept that Pussy users even with another
name would use their forum to ask questions. RTFM or some
similar standard reaction.

I dearly hope that I am wrong but I don't trust that it helps
that Pussy is 100% compatible doing the downloads from
Debian repo.

They would bark loud at any root or other non standard
thing that Pussy have.

Why else does Mepis or Knoppix need their own forums?

I hope I am wrong but I trust that they would react like
the Slackware folks over at LinuxQuestions when I asked
about Porteus in the Slackware section. Go to the Porteus
forum they told me and the Slackware devs where not
friendly at all.
The Porteus Devs where very patient and
friendly so all kudos to them.

So only if Sickgut personally know the leaders of Debian
and them have promised that Pussy is their baby will any
user of Pussy get accepted at their very strict forum?

Am I really wrong. They hate anything being able to be root?

[sickgut]

@ nooby

users getting help from #debian or #debian-live dont say they run pussy. All you need to say is you run debian live squeeze and ask whatever technical question, simple as that. Whatever they say will work on Pussy. Use common sense, dont ask: "Hey i got this obscure OS that claims to be 100% debian compatible, can you guys support it plz? its called pussy.. i need help with openssh-server.... can i ask my question here?"

Instead you simply ask: "can you guys help me with openssh-server configuration? i need to be able to block access from outside networks..."

if that is too hard for people then they shouldnt be using a computer to begin with. I prefer to take a giant leap forward and presume pussy users arent complete idiots.

i dont know anyone in the debian community and im not going to ask them to support pussy.

[saintless]