To: Arthur Donkers
Subject: VTun article (October 2000)
Arthur, If the samples of the packet dumps you have given in your
VTun article for Sys Admin are real, then I would be very
wary of the "encryption" offered by VTun. If you study
the packets closely, you will see that the same data appears in
the same location in all the packets you showed in your example.
This indicates to me (I am no crypto-geek by any means) that the
encryption used is a simple bit-swizzle and that with a small amount
of effort the key could be extracted from the encrypted data using
differential decryption allowing the packets to be decrypted.
Computer Systems Administrator
The packet dumps are real dumps!
I haven't studied the encryption of VTun that closely
to be honest. I paid attention to the authentication part, which
makes sure the password is never sent over the tunnel. I will take
a closer look at the data encryption now, first by studying the
I must confess that since writing this article, I switched
over to IPsec (the FreeS/WAN implementation for Linux) for two reasons:
- It is a standard and makes interoperation between different
platforms and vendors a reality (I tested it between Linux and
- It has a better crypto foundation that VTun.
Thanks for pointing this out, and I will investigate it. If I turn
up anything interesting, I will let you know.
From: David R. Thome (email@example.com)
Please let me know if you have covered this suggestion in a previous
issue. I have a suggestion for very helpful article that I'd
like to see in your publication.
For all UNIX platforms, show how an SA would (by using cron)
go out and make copies of all critical config files as well as output
from commands such as ioscan, sysinfo, dmesg,
and critical Veritas commands, etc. Have the cron run them
weekly and maybe compare previous weeks in attempt to show potential
problems. Also if a server crashes or begins having problems, these
files would be good references to compare to. Which system files
should be available, which command out would be critical to always
have on hand? Does this make sense? Have you had articles on this
in the past?
Readers: I don't think Sys Admin has published
an article on this topic. If anyone can help, please let me know.
Thank you. --AA
From: Jeff Krintila (firstname.lastname@example.org)
I just got around to reading an older edition of your fantastic
mag and thought I would offer an additional snippet of info to the
letter from Nick Patetta (New Messages in August 2000) regarding
"Building a Jumpstart Server for Solaris" (Sys Admin
Patetta mentions two cluster-install options (SUNWCuser and SUNWCall).
I use the SUNWCXall cluster instead (includes the OEM distribution).
I have found that if you are going to be installing Oracle 8.1.6,
you need this type of install. Hope someone finds this helpful.
Thanks for the information, Jeff. --AA
From: Victoria Sadoff (email@example.com)
Subject: Viagra: Keeping Services Running on BSD (February 2001)
I find the metaphor implicitly comparing servers with penises
used in this article unneccessary, puerile, and unprofessional.
Why detract from useful information with infantile drivel?
Victoria, Thank you for taking the time to write to Sys
Admin. I appreciate all feedback from readers, and I regret that
you found the script name chosen by the author of this article to
be unprofessional and immature. Please accept my apology for any
From: Mark E. Dawson, Jr.
Subject: SA feedback
Thanks to fellow member of the AIX-L mailing list, Jonathan Tansley,
it was brought to my attention that I made a technical error in
my AIX Cloning article (Sys Admin March 2001). I mention
in the article that the "mkszfile" command creates
BOTH image.data and bosinst.data. The truth is that "mkszfile"
only creates the image.data file.
To customize the bosinst.data file, you must copy the example
bosinst.data file from /var/adm/ras directory, then make
your customizations to your copy of that file.
Thanks to Jonathan for bringing that error to my attention.
Mark E. Dawson, Jr.
From: Ian Jones
Subject: SA feedback
Having just purchased your Feb. 2001 issue, I must tell you that
I will not be looking for your next one at the bookstore. I could
justify spending $6 on something that imparts useful information
or is at least entertaining, but at a slim 80 pages it is quite
One of the very few articles you did bother to include didn't
even have the program listings (Spamivore). You must concede that
a detailed walk-through of the functions in this CGI is fairly useless
without the code that it describes. If you did it to save space
for more content I would understand, but it seems more like you
ran out ink and paper.
You need to get it together if you want to stay afloat. This was
a pretty slim offering.
Ian, I appreciate your comments about the magazine and regret that
you were unsatisfied with your purchase. In many cases, we do choose
to run the code listings only on our Web site so that we can include
more articles in the magazine. Our readers generally also find this
the easiest way to make use of the code.
Also, the total number of editorial pages we can run every
month is based on a number of factors. Basically, however, it boils
down to a stated editorial-to-ad ratio that we must maintain. I
hope this addresses your concerns, and I thank you for writing.