elvis elvis
elvis elvis321
elvis elvis123
elvis 1
elvis 12
elvis 123
elvis 1234
elvis 12345
elvis 123456
elvis password
elvis passwd
elvis test
elvis test123
elvis sivle
unix is secure. But only as secure as your passwords: Just came across this lame rootkit on some computer.
Above the passwords that it seems to try for all users it seems to be frequent enough. Pretty lame, but it seems to work.
If you think you are smart and have a password like ‘usermane’ then think again.
File servers. No big deal. I am dealing with kind of thing since more than ten years. And it works.
We tried OS X Server 10.2.8 a while back, and it was bad. Now I have to deal with it again: OS X 10.4.3
and it still is junk. It is broken. Things don’t work as they should. Apples way of doing things is
incompatible with everything. It is such a waste of time. If they add a guy then they should leave
the way things are done underneath as everybody would expect them. XServers get bought by people
for their shiny facade. Which is all ok for me. Just that the inner workings of it are simply rotten.
The non server version of OS X is much more consistent with having all features in the system preferences
sharing.
it’s all gory details. I don’t even want to go into it. It was broken with 10.2.8. With 10.4.3 it is still broken.
Fileservers are not THAT important that you want to waste your entire worklife administrating them.
And with Linux (or even SGI for that matter) you don’t have to. You learn the meaning of a few commands and
are done with it.
It really is bulshit. If you consider to get a server, don’t get an Apple one. They are too expensive and work not in a way that would make any sense …
… just don’t expect it to listen to a killall -HUP vsftpd. At least under Fedora Core 4 you need to do a /etc/init.d/vsftpd restart if you would like to see changes in /etc/vsftpd/vsftpd.conf to take effect.
Which is no problem if you know. Now you do …
I can only agree with most of this lenghtly text.
That’s how I felt when I switched much from SGI to OS X for parts of what I do.
When you start learning unix then the ls command is probably one of the first ones you come accross. It lists files. You need that. Allot. It is pretty easy to overlook that there is much more to files these days then the information that the ls command will provide you with. For OS X you have these additional commands that you can try:
stat -x FILENAME
This is a standard unix command. Helpful if you are looking for modification or access times or simply need to know which inode a file is starting on.
/Developer/Tools/GetFileInfo FILENAME
The default filesystem for OS X is HFS+. This can store extended attributes with your file, and if you have the free developer option insalled then you can use this to read the extended attributes. /Developer/Tools might be worth a casual ls as it contains a couple of other interesting tools
ls -ls FILENAME/rsrc
HFS+ allows files to have a so called ‘resource fork’. By adding /rsrc after the file name you can use the ls and even the cp command on these parts of the file.
mdls FILENAME
With OS X 10.4 apple introduced a searchable file content meta database. The spotlight icon sits prominently in the uppper right corner of the screen. But also in a command line you can access the information via mdls and a couple of other tools.
All these commands have a man page in case you need to know some details of how they work.
Yesterday I had to move a site that I wrote from LA to Paris. From redhat to debian. Overall not a bad experience. Debian is different but seems neither worse nor better than Redhat or Suse from what I can tell. apt-get is your friend. Why they felt that apache is a better name than httpd beats me.
Complex things go well and simple ones have surprises:
Changing the timezone back from Paris to LA I first ran tzselect.
That gave me the correct value. But then I had read on the web to change /etc/default/rcS. Which does not make sense to me: UTC is UTC is UTC. That’s what it’s there for. I then found /etc/timezone. I thought that would be it. Rebooted and, well, ssh
hash has changed. Interesting side effect. But still we were on the wrong time. Then I found that /etc/localtime was still (soft) linked to /usr/share/zoneinfo/Europe/Paris. After changing this to /usr/share/zoneinfo/America/Los_Angeles the date command gave me thee ‘right’ time. But apache/php still reported mod times of files in the old style. A second reboot fixed also that.
just discovered the
screen
again in linux. It is really nice: One person types screen the next
one screen -x and both type and read in the same session.
That is really nice for remote debugging etc etc.
and it costs?
Nothing
🙂
years of unix I spent without knowing about the
locate
“fool me once, shame on you” or however GWB would say that.
Now with spotlight in OS X 10.4 this became somewhat redundant.
It was only today that I realized:
mdfind
is your command line friend. With a command like
mdfind "kMDItemFSName == a.out"
you can easily replicate what
locate a.out
would have done. This works nicely around certain things I don’t like about the spotlight UI: sometimes I only want to see where a given file name might be hiding. Spotlight finds it, of course. However I did not find an easy and intuitve way to only find file names. The UI finds usually to much. And there seems not to be an easy way to get the directory in a copy paste buffer. Command line wins again.
Yeah! for mdutil mdls mdfind and all the others!
… so I am installing some ancient linux (redhat 9) on some similar ancient hardware (don’t ask).
All goes well. Suddenly the install hangs. I follow the instructions to get rid of __db.* in /var/lib/rpm and do a rpm –rebuilddb only to get an error message:
error: db4 error(16) from dbenv->remove: Device or resource busy
Too me that sounds like something is broken. Tried it again, and it behaved the very same way. Since nothing is running on the machine I decided to reboot. Still the same error. Finally, I google for it, and find that this is ‘harmless’. “harmless” ? OK, why dosen’t the error message say so then?? This is just plain stupid. It would have taken the original coder 3 minutes to give people a little hint that this error is well, not an error. That it is ‘harmless’.
An easy way to run things on remote machines in unix has been the ‘rsh’ command.
For instance:
rsh -l guest remote-machine command-to-run-on-that-machine
would execute the command on the other machine. Of course things need to be set up for that. It used to be simple, but the default installs
for redhat redhat (and possible other installs) need a bit of tweaking. Here a quick and dirty recipe. This openes the machine to the public,
so don’t do it on any computer exposed to the internet or a bunch of untrustworthy users.
useradd guess
(remove !! from /etc/shadow for user gues)
A user guest with no password exists. Cool and scary. Up to you.
rpm -i rsh-server-0.17-21.i386.rpm
Versions might be different, check if it does already exist
(set disabled="off" to disabled="on" in /etc/xinetd.d/rsh)
killall -HUP xinetd
Tell xinetd that it is allowed to start rshd if an incoming connection is being made.
cp /etc/pam.d/login /etc/pam.d/rsh
This is a true hack for people that don't know what they are doing. I have no idea what
the side effects are of this. It worked for what I had to do, but it might be completely
inapproiate.
From now on you can do things on that machine as the user 'guest'.