begin quoting Steven Gauna as of Sat, Feb 02, 2008 at 09:56:18PM -0800: > >begin quoting Steven Gauna as of Fri, Feb 01, 2008 at 03:55:16PM -0800: > >> This is my first time posting to the mailing list. Please let me know if > >> I'm not doing something > >> correctly. :X > > > >Wrap your lines before 80 characters to avoid the long-line-short-line > >effect, which is disconcerting for the reader. 72-76 is good, although > >anything less than 80 won't give cause for complaint. > > I'll remember that from now on. I'm using the gmail web interface > to send these messages; its not really set up well for this. :)
You'd think Google would have fixed that already. [chop] > >What do you use that's bash-specific? <poke> Hm... $RANDOM? Is that it? > > Is there an /bin/sh alternative? I don't know standard sh to be honest. > I wanted to make it /bin/sh but I didn't know enough about it to > pull it off safely. There's a few /bin/sh options (ash, sash, etc.) that do a better job of being /bin/sh than bash does; but be aware that $RANDOM doesn't work in /bin/sh, so you *are* using bashisms. I was just wondering what bashisms you were using. > >Why enforce being root? Maybe an appropriate user-account already > >exists; run this script too often, and you'll clutter stuff up. > > Its meant to run from a boot cd in which the environment isn't > saved after its been used, so clutter shouldn't be a problem. I'm starting to have a serious problem with programs that demand root to run, just on general principals. It starts off with stuff that NEEDs to be root to run, then the test gets put into code that would be NICE to run as root, and from there it gets put into code that has no reasonable justification for running as root. I think it might be a good idea to simply not tell a program what UID it's running as, or offer an easy way for the system to lie to programs about this. Until we have that capability, it's probably better to just emit a warning, and if the user insists, choke at the appropriate point with a useful error message. > >Having each exit code being a different value (to indicate what failed) > >is sometimes a good idea. > > I got lazy and didn't think anyone would care. :X Heh. It's an easy nit to pick. > >No special characters in the password? > > Nope, they can be added into the array easily if you want them. > I originally had some in there but took them out for ease on my > eyes. > > >Why use a password? You're using ssh -- use authorized_keys. > > Yeah, that would probably be easier and more secure. :/ > It takes all the fun out of the password generator though. :) Heh. If you use the authorized_keys approach, the character choice in the password becomes a moot point. [snip] > Since this is supposed to be for a boot cd, I really didn't think > stomping over the pre-existing settings was bad. That's a big assumption; since you're destroying data, you probably ought to check that you are, indeed, booting from a rescue CD and that you're modifying a filesystem in RAM. Or generate an alternate configuration and spawn up sshd directly, instead of using the /etc/init.d/sshd script. > Also, port > 22 gets brute forced all the time by scanners. I just thought > having another layer of obscurity would make it more fun. 'Fair nuff. [snip] > >You do not offer the user a chance to abort after telling them what > >you want to do. This coupled with must-run-as-root makes this a > >rather unfriendly tool... get rid of the little output there is, and > >it's sort of dastardly. > > I really only meant it to be used as a layout for the idea I had > in mind. It definitely shouldn't be used as is, I just thought > that setting up the idea would get something bigger in motion. > > Thanks for the comments TC :) You're welcome. -- What I mostly do is provide Feedback and opinions. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
