Re: [suse-linux-uk-schools] Working in Teacherland - opportunities please? (long)
--- Paul Graydon
Hmm.. I've got a slackware based test box at home, wonder how it'll take to it :-)
Well, I tried to run it on my Debian box, but I had to spend a considerable amount of time hacking it to death -- it's too dependant on one distro to ever be portable. This may not be a bad thing, if it is designed only for one specific distro -- the only problem with that is I personally wouldn't go near Mandrake...
Been there, done that, got the T-shirt?
Something like that, yes.
we could lock our system down even further, like specifying the workstations can only run x, y & z, program files etc, but that's just too much hassle to implement and maintain!
I wouldn't have said so -- in fact, it would be quite easy to do. -- Thomas Adam "The Linux Weekend Mechanic" -- http://linuxgazette.net "TAG Editor" -- http://linuxgazette.net "<shrug> We'll just save up your sins, Thomas, and punish you for all of them at once when you get better. The experience will probably kill you. :)" -- Benjamin A. Okopnik (Linux Gazette Technical Editor) Send instant messages to your online friends http://uk.messenger.yahoo.com
Ahh, I forgot to say so far it will only run on rpm based
distros....maybe this was why you were having problems?!?
If you can send me some feedback it would be nice as we can then improve it!!
Jo
On Wed, 16 Mar 2005 12:23:10 +0000 (GMT), Thomas Adam
--- Paul Graydon
wrote: Hmm.. I've got a slackware based test box at home, wonder how it'll take to it :-)
Well, I tried to run it on my Debian box, but I had to spend a considerable amount of time hacking it to death -- it's too dependant on one distro to ever be portable. This may not be a bad thing, if it is designed only for one specific distro -- the only problem with that is I personally wouldn't go near Mandrake...
Been there, done that, got the T-shirt?
Something like that, yes.
we could lock our system down even further, like specifying the workstations can only run x, y & z, program files etc, but that's just too much hassle to implement and maintain!
I wouldn't have said so -- in fact, it would be quite easy to do.
-- Thomas Adam
"The Linux Weekend Mechanic" -- http://linuxgazette.net "TAG Editor" -- http://linuxgazette.net
"<shrug> We'll just save up your sins, Thomas, and punish you for all of them at once when you get better. The experience will probably kill you. :)"
-- Benjamin A. Okopnik (Linux Gazette Technical Editor)
Send instant messages to your online friends http://uk.messenger.yahoo.com
-- To unsubscribe, e-mail: suse-linux-uk-schools-unsubscribe@suse.com For additional commands, e-mail: suse-linux-uk-schools-help@suse.com
-- Spread FireFox: http://www.spreadfirefox.com/?q=user/register&r=32751 Get FireFox: http://www.getfirefox.com OpenOffice: http://www.openoffice.org Mandrake: http://www.mandrakelinux.com Karoshi: http://www.karoshi.org.uk
--- linuxgirlie
Ahh, I forgot to say so far it will only run on rpm based distros....maybe this was why you were having problems?!?
If you can send me some feedback it would be nice as we can then improve it!!
Ok. Well, it certainly is possible to standardise some aspects of Karoshi such that it is more portable against different distros. Admittedly there isn't a great deal of difference between RPM-based distros -- but there is enough difference to merit some work in changing certain aspects. I know I've mentioned that I wouldn't go near Mandrake -- that's just me. I'm a crufty-imbecile that would use anything but. I would imagine that for 99.9% of others, Mandrake would be fine, but this is Linux, and choice is everything, so... :) As to how much work is involved, I couldn't say. I didn't have to do *too* much work to get Karoshi to run on Debian. Most of it involved changing a lot of your bash scripts. Meaning no disrepect to you, the scripts are quite poor, and badly needed re-writing anyway. For instance, in your 'serverselection' script, it would be nice if you tested if the directory existed, rather then shunting a non-existing error to /dev/null, something like: [ -d $HOME/.tempdata ] || mkdir $HOME/.tempdata Other issues to consider, if you want to make it portable are not to rely on installing your version of Xdialog that you package with karoshi. What happens if I already have it installed? Ka-boom, it fails. Now, it might be that the descision was made because Karoshi is intended to be installed just after a base/minimal installation. Fine, but at least check to make sure, even something simple would help: [ -z "$(which Xdialog)" ] && XDIALOGVERSION="XDialog-foo.rpm || \ # don't both installing it. (I'll ignore the poor naming of the variable... :P) I noticed also that the script is not detecting whether it is running as root or not -- hence I got a lot of errors. If the assumption is made that the user will be running the script as root anyway (hmm, see my "Logging in as root? Alternatives exist" post about caveats) that's possibly OK, but still check to ensure, something like: [[ $UID = 0 ]] || { echo "You must be user root to run this script" exit 0 } Issues of portability -- you could make it more robust if you could determine which distro is running. Now, this isn't an easy task, but one way is to do something like the following: for i in {mandrake,fedora,SuSE,redhat,gentoo}-release do [ -e "/etc/$i" ] && DISTRO=${i/-release/} done case "$DISTRO" in mandrake) # do something specific ;; SuSE) # do something specific ;; fedora) # do something specific *) # default to Mandrake? ;; esac You can then almost certainly get the underlying distro to install its own verion of packages -- thus saving you the need to ship with version of packages many (if not all) distro use, anyway. Debian and Slackware will/might be the oddities here, but not to be seemingly arrogant, the majority of people using these distros will usually be able to know what to do to fix various things. Other factors I've seen that could be improved -- you have a *hell* of a lot of redundant code -- you should modularise this into separate scripts that the main script can then source. For instance the 'serverselection' script's code is repeated in at least three other scripts -- why? It would have been far easier from a maintainability point of view to have common functions in one script, source and used as needed. It's a sticking point, because in order for Karoshi to run on Debian (at least), I then had to change every single script. Luckily, awk came to the rescue, but.... :) Spaces in filenames -- opps. Try and avoid that, the shell hates them. And it just means you have to use excessive quoting where you wouldn't normally had you used underscores. Very old shells (sh on HPUX for instance) hates them a great deal more -- sh and bash on Linux are far more forgiving. :) There's probably other things as well I've forgotten about, but I hope that helps... -- Thomas Adam Send instant messages to your online friends http://uk.messenger.yahoo.com
wow, that is great thanks :D If there is anything else just email, we will have a look when I get home. It has been very quiet on the dev side of things, most of the input has been in the features not the code, so any dev help will be greatly recieved. Jo -- Spread FireFox: http://www.spreadfirefox.com/?q=user/register&r=32751 Get FireFox: http://www.getfirefox.com OpenOffice: http://www.openoffice.org Mandrake: http://www.mandrakelinux.com Karoshi: http://www.karoshi.org.uk
On 16 Mar 2005 at 12:23, Thomas Adam wrote:
--- Paul Graydon
wrote: Hmm.. I've got a slackware based test box at home, wonder how it'll take to it :-)
Well, I tried to run it on my Debian box, but I had to spend a considerable amount of time hacking it to death -- it's too dependant on one distro to ever be portable. This may not be a bad thing, if it is designed only for one specific distro -- the only problem with that is I personally wouldn't go near Mandrake...
Been there, done that, got the T-shirt?
Something like that, yes.
we could lock our system down even further, like specifying the workstations can only run x, y & z, program files etc, but that's just too much hassle to implement and maintain!
I wouldn't have said so -- in fact, it would be quite easy to do.
Its easy to add the programs into the client management software. The hardest part I've found is trying to ensure you've got every program that gets used by the programs themselves. I tried to lock down a library machine last week, all I wanted it to run was the library catalogue software, so users could search from it. Some bizarre mapping issues meant we couldn't set the program (which runs from a network drive) as shell, it could see the program but wouldn't see the contents of the catalogue, which is in the same place as the program. Alternative approach was to tell it it could only run that one application, but that didn't work either, as it called on various windows programs and the like, but it was impossible to track the calls. In the end we gave up and just locked out the start menu, run, ctrl+alt+delete, and so on for the unique user account we created, and then set the box up to autologon.----- Paul Graydon Network Technician Haywards Heath College http://www.hhc.ac.uk (01444) 456281 "Joy is not in things; it is in us." Richard Wagner
participants (3)
-
linuxgirlie
-
Paul Graydon
-
Thomas Adam