Re: changing hostname
On Fri, Jun 22, 2001 at 02:15:12PM +0000, Iain Smith wrote:
> > Until I found out about this wonderful "-r" option to gnu grep:
> >
> > grep -r myregex /etc
> >
> > wants to be your friend too.
>
> Hmmm.... I managed to miss that one completely. Time to re-rtfm! I knew of
> rgrep but found it was rarely available in avg distros... I guess I know why
> now!
Yes, rtfm is good. Good sysadmin books will not teach you how to be
r00t in 24 hours, but instead tell you "stop reading here and only come
back when you've read all of your system's manpages". :-)
In my experience, the best one is the bash(1) manpage. It is is really
vital. You don't properly realise how much until you've read all of it
(well maybe read a little faster over the readline bits).
Next come grep(1), sed(1) and awk(1). They come together quite naturally.
These are one of the first unix tools and they are still around.
Conceptual simplicity is the essence of their strength and the reason
for why they're still around so much. Studying them is about more than
these tools per se, it opens up a view on unix concepts and approaches.
And that is the real gem to be won.
Meanwhile you may be tempted into taking a little detour through regex(3)
and printf(3) and maybe some others too, that would be okay.
At this point I could start on perl and how it another example of a
place that harbors the unix mindset, even though nowadays you can run it
everywhere but on a nintendo. You can even run it on your (developer
edition) playstation2 :-) I've heard perl being described as "Schaum's
outline on unix" and there's a lot of truth in that if you ask me.
But if you were to jump into the perl sea, I would not really expect
you to ever come drifting back to that sysadmin book ever again. :-)
Of course, all this is meaningless without the proper background.
There's no escape to reading K&R C book, even though it might seem very
little relevant from a distance. It is tremendously relevant, because
all the basic unix stuff is built on it and largely in its spirit.
Also must do is to read a book on unix systems. I suggest the 4.4 bsd
book, because it is a lot more readable than some of the more well-known
pamphlets by various illustruous academics[1]. Also, Kirk McKusick has
a video with the book and you're missing out if you have not seen it.
It is brilliant. I wish that some day, there will be something similar
for linux and that it will have all the beautiful anectdotes that light
up the McKusick tapes. This is really unix at its best: vibrant with
culture.
[1] Tanenbaum's "Structured computer organisation" otoh is very lucid,
yet quite straightforward about the technical details aspect that is so
inherent to the matter at hand. It also shows a good sense for anectdotal
evidence and putting things in a bigger picture. in retrospect, maybe
I should have put it before the C book, because you probably don't get
all of C if architectural concepts are like magic to you. But in another
sense it also a bit to far off course here.
> > > rather than using cat, you'll get the names of any files containing matches
> > > back using this method. Also, it may be worth changing the search base to /
> > > as IIRC a search on a potato box turned up some matches elsewhere on the
> > > filesystem...
> >
> > Watch out for all the rope hanging about in dark corners of /proc and
> > /dev. Your point is valid though, but I doubt that you'll find
> > much of importance outside of /var. And then most of what is in /var
> > should probably change itself when daemons restart or should just stay
> > like it was, like your archived logfiles.
>
> /proc and /dev? Shirley the next reboot would cure /proc... though admittedly
> it's not always an option... and an all together too windowsish solution! ;)
You really don't want to mess with /dev/kmem and /proc/kcore. Install and
setup a user-mode-linux system if you like to toy with that stuff without
exposing real data to real danger.
Cheers,
Joost
Reply to: