DSL Tips and Tricks :: DSL hard drive install 'improvement' ideas

I've finally posted a slimmed down 'hardening' guide for DSL hard drive installs. I focused primarily on updating a few things that can be important on a networked computer, including one that surfs the Internet. That includes upgrading zlib , SSL, and SSH. Hopefully Robert will consider either updating some or all of these or using a smaller replacement like dropbear (has this been considered before?) in DSL 4.x. I also cover a few things that I think should be changed on a hard drive install such as tightening sudoers and reconfiguring ssh/d. I like to keep my secure shell secure.

My own preference is to use as little from MyDSL on hard drive install as possible. With my most recent install (yesterday), I installed GNU utils and gcc. No UCIs. These can be made to work on hard drive installs, but they're not ideal (imo).

Default kernels are for the widest (sensible) array of possible hardware on which it can be used. That's important and ideal for a live CD, but maybe not so good on a fixed hard drive. To make my point, I also compiled a kernel this afternoon to show how wide the differences between the default kernel and one compiled for a particular computer can range. In my case, I was using 16MB of RAM upon booting into runlevel 3 with an updated version of BASH and 25MB after startx and my new modules take up less than 8.5% of the hard drive space used by the default (could've been even smaller) DSL modules. This is fully functional for that particular computer. I have an image showing before and after data, but the before includes a lot more running processes instead of at boot (I'll boot the DSL kernel again and update that).

(Since someone mentioned RAM use in one of the Eee threads, those RAM numbers above include cached -- which the default torsmorc excludes from what gets displayed on your screen.)

As I note, these aren't shortcomings in DSL. You just have to remember that DSL and Knoppix were engineered to run in a completely different form from a standard hard drive install. If you use it as intended, these things don't matter so much and would be impractical -- what good would it be to set up strong passwords on a live CD anyway? When you install DSL to hard drive, you're undoing some of that CD-based engineering. You can't reboot into a restored state, you have the same issues where you left off. I left out a lot more I wanted to write about some of the scripts which are ideal if you want to use DSL as it's intended to be used but can be less than ideal -- IMO -- on a hard drive install.

The page is here:

Dropbear and new Busybox are both likely for next 4.x
I have put the latest dropbear into DSL v4.4-testing and Tiny Core.
Does save us some space and much newer too.
Thanks for the suggestion.

Now on to the busybox update.

I have put the latest dropbear into DSL v4.4-testing and Tiny Core.
Does save us some space and much newer too.

Did you build MULTI=1 a la busybox? Did you leave out any of the program options (maybe leave out x forwarding since it only offers server?), reduce the number of encryption algorithms, or set small code? About the small code, I'm curious how accurate the comments in options.h (slows symmetrical ciphers by 50%) are. I might experiment more with it this weekend.

One more issue: sshfs. Since dropbear doesn't include sftp-server, this might be a problem for keeping sshfs (short of keeping sftp and any libs it requires -- libssh?). I don't know if there are any acceptable alternatives to openssh sftp. I'd hate to lose sshfs, but as long as I can scp I'm happy. If it is problematic, should fuse/sshfs and openssh be moved to extension?

I did a MULTI build. But now I see that dropbear does indeed break sshfs. I don't want to remove current features from 4.x. So, I am going to back out dropbear from 4.x and use it in tiny core only.

Tiny core is made to be small with most everything an extension. Therefore a  full openssh/fuse/sshfs can be an extension for the new system.

Next Page...
original here.