as mentioned in the comment section of the network world article:
"of course, it's worth pointing out that Contra Costa County is the predominant county and tax base for the East Bay -- a sprawling set of towns/cities full of people that work in downtown San Francisco, Oakland, and Silicon Valley. It's the same county where median home prices for most of the towns are well north of $500,000.
To quote the Contra Costa website: "Due to the presence of relatively high-wage skilled jobs and relatively wealthy residents, the County achieves high rankings among all California counties on a variety of income measurements."
This isn't the story of an impoverish[ed] county begging for debt relief from an evil corporation. Move along."
here are some suggestions during the porting process:
1. generalize the helpdesk system from pure IT requests. a single point of entry for both IT and facilities requests would probably be beneficial to the end-user (who doesn't really care about the difference between the two)
2. introduce location identifiers into the system. preferably from the user's LDAP entry.
3. train MIS staff to actually post technical details regarding solutions when they close tickets with comments. the help desk system might be able to gateway into a knowledge-base system.
4. include an administration interface for metrics evaluation (to aid in training recommendations and personnel evaluation (both of mis staff and end-users).
5. allow for more formalized delegation and task-assignment.
6. time-ticker (of some sort) to track how long it takes to work a ticket from start to finish. this data would feed back into #4.
Both posts suggest that there's some either/or proposition here. Use a GUI or use the CLI. I certainly don't pretend that to be the case. As indicated in my post, use the GUI tools, play around with them, get started, but learn what they do!!!
One of linux's strengths (and one of the reasons for its appeal) is that it empowers the user with knowledge and control over the OS. A GUI can be of immense help to the linux novice. It can also be too much of an abstraction.
While I agree that not every linux user wants to be a UNIX sysadmin, I don't subscribe to over- simplifications that they just want to run quake and surf the web. There are just as many new users that want to "get into" UNIX, linux, and the technologies that are so successful on these platforms.
Then, there are also new users that want to be UNIX sysadmins.;-)
These are some of the reasons I hold smit up as an example of a good GUI tool. It supports the users who don't care about the internals, but it also helps instruct the people that do.
Although I can appreciate many people's desire to have GUI config tools to help with configuration in linux (devices, xwindows, daemons, startup, etc), I'd like to point out the following:
most GUI tools of this ilk are linux-specific. One thing I always tell friends (esp. when configuring apache, bind, sendmail, etc) is that they should go straight to the config files. One of the strengths of linux is that configuring it gives you an introduction to other unices as well.
If you can configure apache's httpd.conf on linux, then you can also configure it on freebsd, solaris, aix, and just about any other UNIX it will port to. That's a valuable skill to learn -- and one that the GUI tool won't help you with.
By all means, play around with GUI configurators, but learn what they actually configure and where. Look at the config files. Learn to configure these things with vi and you'll go a long way towards a wider world.
(one thing I did like about AIX Smit is that it displayed the CLI syntax once it kicked off a configuration task -- not bad).
In the "God Particle," you briefly describe super string theory and some the excitement it has generated in the search for a TOE.
Unfortunately, string theory's primary appeal has been due its mathematical elegance and consistency. Due to physical constraints, experimentation and empirical evidence have proven to be elusive, if not impossible.
As work in this field has continued, what are your current thoughts on the strength of string theory? Also, how likely is it that we'll actually be able to test its veracity experimentally?
My congratulations to Ralph on pbFORTH. It appears to be a great alternative to the Lego firmware in providing more granular control of the RCX and in its functionality. I especially enjoyed the ability to try out commands on the fly via a terminal (without having to compile or write a whole program first).
At this time, however, I find I'm spending more of my time in NQC. It's a fantastic tool -- very C like and feature-rich. I find I haven't really run into a situation yet where pbFORTH's extra functionality has been required (and consequently the installation of a firmware different from that which came with the RIS).
Ultimately, I'm not sure I need to spend the time learning FORTH, just to play with legos.
Last, I have no opinion of legOS, since I haven't tried it yet. It looks very cool, though.
It's probably worth mentioning that most of these alternatives are due to the reverse engineering of the RCX done by Kekoa Proudfoot:
Your point is well-taken. Windows doesn't play nice with UNIX. However, in the spirit of ingenuity, UNIX will play with Windows.;-)
Samba 2.x clients can both register with and query from WINS servers. Therefore, linux and UNIX users with samba properly configured can play the NetBIOS/WINS resolution game just like everybody else. You'll even show up in Network Neighborhood (since that seems to be so important to windows users).
As I point out in another post, WINS support in DNS is only a partial hack. The NT DNS server only queries for WINS values from the WINS server. It does NOT load that value into the zone itself. Therefore, if you had a secondary DNS server that wasn't NT DNS, it would not be capable of knowing about that hostname because its not in the zone and because it can't query directly to the WINS server.
As it stands, there are other products that do REAL DDNS injections during the DHCP process which do REALLY update the zone file with the new assignment (ISC DHCP + a script + BIND 8; MetaIP; Cisco IP Registrar).
Your point about NT DNS not being a good option for external DNS is a valid point. I agree.
A minor nitpick: MS DHCP Server doesn't really bind to MS WINS Server. What actually happens is that MS DHCP Server feeds WINS Server values to the DHCP client. It is up to the DHCP client to register/update with the WINS server. (sorry, that was just me being overly correct and nitpicky).
As you're aware BIND 8, according to the RFCs, will NOT recognize the unserscore in a record in any zone it is primary for. In other words, if BIND is primary server for foo.com, it will choke and refuse to load the entire foo.com zone if you put foo_bar.foo.com in that zone (there's a way to get around that with creative CNAMEs, but that's another story).
However, if BIND 8 is secondary to a primary that does allow underscores (ie, BIND 4.8.x or NT DNS), it will go ahead and accept the transfer of both the entire zone and the offending record. It will just complain in the log file.
Look, DDNS has had basic support in BIND 8.x for a couple of years now (with increasing quality in each update). BIND administrators could do DDNS injections with the nsupdate tool provided with the BIND distribution, they could roll their own scripts with the DNS module for perl, or they could incorporate DDNS into ISC DHCP with Irina Goble's scripts or with the new beta code in ISC DHCP 3.0. Cisco's IP Registrar and MetaIP are commercial products that perform similar functions.
In point of fact, the article got its history wrong. The examples cited above, along with the relevant RFCs, were help up to Microsoft as examples of why the WINS lookup feature in NT DNS was so inadequate. The incorporation of DDNS updates into the actual zones via IXFR allows for propagation of the DDNS injections to heterogenous secondary DNS servers unlike the WINS lookup "feature" in NT DNS.
so, don't fret about MS getting the upperhand on DDNS, in and of itself. BIND 8 (and the forthcoming BIND 9) has got MS beat. What this article was trying to allude to is this:
Although the Win2k implementation of DDNS might actually be RFC compliant, it is quite probable that the Active Directory tie-ins to DDNS will only work with the Win2k DDNS server. This is crucial: even if Active Directory sucks, it has huge appeal for Corporate America. It will be implemented far and wide. This is what the article alludes to: you'll have Win2k Active Directory admins trying to require the DNS hostmasters to convert to Win2K DDNS to support their Active Directory application.
Not quite... the WINS lookup feature on NT DNS will, as you pointed out, return WINS client values in response to dns queries to that NT DNS server. However, it does not actually add the WINS entry to the domain zone like DDNS does.
This doesn't really become too much of an issue until you start setting up other DNS servers like BIND to become secondaries to that NT DNS server. Because the WINS entries aren't actually in the zone, the secondary BIND servers CANNOT retrieve the WINS values or lookups. Further, they cannot retrieve the info from the WINS server directly since the WINS resource type is not RFC compliant and only works on NT DNS.
So, in this scenario, the non-NT DNS servers are incapable of returning dns lookup queries for any WINS client.
MS implemented DDNS in win2k to actually inject netBIOS names into the dns zone like DDNS does in ISC DHCP 3.0 and the nsupdate tool in BIND 8.x.
I enjoyed watching it. I thought the actors and actress were actually quite good and believable in their roles. Oddly enough, however, I didn't find it as scary or frightening as I had hoped, especially the events leading up to the climax. Also, there were a couple of things that were irritating but probably limitations of the choice of presentation: their constant giving up, sitting down in the grass, and complaining about how lost they are. I guess, though, that's better than a whole movie of video shots of them walking and complaining. Despise these things, I still liked the film.
It's not random at all. If you look closely, you'll see that the inet6 address was generated by wrapping an IPv6 compatible address around your MAC address.
I believe (if I recall correctly) that IPv6 has generated a site-local address (sort of equivalent to IPv4 private addressing) out of your MAC.
According to the allocation draft document, http://www.arin.net/IPv6.txt, the 3 Registries won't be initially assigning IP addresses to end users or sites. Instead, they'll be making sub-delegations to TLA registries (a sub-continental registry that will make allocations after the 1st 16 bit boundary of an ipv6 subnet). So, ARIN, APNIC, and RIPE will begin issuing TLA's to the TLA registries, who in turn, will begin making allocations at the NLA level level. These NLA assignments will go to large ISP's. Assignments to individual sites and end-users will be carved out of these NLA assignments. The last 64 bits is a hard boundary reserved for the host ID (based on the next-generation EUI-64 MAC address).
Slashdot Mirror
The T.M.W. Laboratory Complex has already solved the problem of modeling cat thoughts with this contraption:
http://www.thismodernworld.org/arc/1990/90cats.gif
as mentioned in the comment section of the network world article:
"of course, it's worth pointing out that Contra Costa County is the predominant county and tax base for the East Bay -- a sprawling set of towns/cities full of people that work in downtown San Francisco, Oakland, and Silicon Valley. It's the same county where median home prices for most of the towns are well north of $500,000.
To quote the Contra Costa website: "Due to the presence of relatively high-wage skilled jobs and relatively wealthy residents, the County achieves high rankings among all California counties on a variety of income measurements."
This isn't the story of an impoverish[ed] county begging for debt relief from an evil corporation. Move along."
introduce cookie-based login/authentication for
both end-users and IT staff.
that way, when they login, the first view they
get will a list of all tickets relevant to them:
1. end-users would immediately see all tickets
they've opened and what the status is
2. IT staff would see all tickets that they've
been assigned or are working on. (a second view
would take them to the complete queue)
here are some suggestions during the porting process:
1. generalize the helpdesk system from pure IT
requests. a single point of entry for both IT and
facilities requests would probably be beneficial
to the end-user (who doesn't really care about the
difference between the two)
2. introduce location identifiers into the system.
preferably from the user's LDAP entry.
3. train MIS staff to actually post technical details regarding solutions when they close tickets with comments. the help desk system might
be able to gateway into a knowledge-base system.
4. include an administration interface for metrics
evaluation (to aid in training recommendations and
personnel evaluation (both of mis staff and end-users).
5. allow for more formalized delegation and
task-assignment.
6. time-ticker (of some sort) to track how long
it takes to work a ticket from start to finish.
this data would feed back into #4.
Both posts suggest that there's some either/or
;-)
proposition here. Use a GUI or use the CLI. I
certainly don't pretend that to be the case. As
indicated in my post, use the GUI tools, play around with them, get started, but learn what they
do!!!
One of linux's strengths (and one of the reasons
for its appeal) is that it empowers the user with
knowledge and control over the OS. A GUI can
be of immense help to the linux novice. It can
also be too much of an abstraction.
While I agree that not every linux user wants to
be a UNIX sysadmin, I don't subscribe to over-
simplifications that they just want to run quake and surf the web. There are just as many new users
that want to "get into" UNIX, linux, and the
technologies that are so successful on these
platforms.
Then, there are also new users that want to be
UNIX sysadmins.
These are some of the reasons I hold smit up as
an example of a good GUI tool. It supports the
users who don't care about the internals, but it
also helps instruct the people that do.
Although I can appreciate many people's desire to
have GUI config tools to help with configuration
in linux (devices, xwindows, daemons, startup, etc), I'd like to point out the following:
most GUI tools of this ilk are linux-specific.
One thing I always tell friends (esp. when configuring apache, bind, sendmail, etc) is that
they should go straight to the config files. One
of the strengths of linux is that configuring it
gives you an introduction to other unices as well.
If you can configure apache's httpd.conf on linux,
then you can also configure it on freebsd, solaris, aix, and just about any other UNIX it will port to. That's a valuable skill to learn --
and one that the GUI tool won't help you with.
By all means, play around with GUI configurators,
but learn what they actually configure and where.
Look at the config files. Learn to configure these
things with vi and you'll go a long way towards a
wider world.
(one thing I did like about AIX Smit is that it
displayed the CLI syntax once it kicked off a
configuration task -- not bad).
In the "God Particle," you briefly describe
super string theory and some the excitement it
has generated in the search for a TOE.
Unfortunately, string theory's primary appeal has
been due its mathematical elegance and consistency. Due to physical constraints, experimentation and empirical evidence have proven
to be elusive, if not impossible.
As work in this field has continued, what are your
current thoughts on the strength of string theory?
Also, how likely is it that we'll actually be able
to test its veracity experimentally?
My congratulations to Ralph on pbFORTH. It appears
to be a great alternative to the Lego firmware
in providing more granular control of the RCX and
in its functionality. I especially enjoyed the
ability to try out commands on the fly via a terminal (without having to compile or write a
whole program first).
At this time, however, I find I'm spending more of
my time in NQC. It's a fantastic tool -- very C
like and feature-rich. I find I haven't really
run into a situation yet where pbFORTH's extra
functionality has been required (and consequently
the installation of a firmware different from that
which came with the RIS).
Ultimately, I'm not sure I need to spend the time learning FORTH, just to play with legos.
Last, I have no opinion of legOS, since I haven't
tried it yet. It looks very cool, though.
It's probably worth mentioning that most of these
alternatives are due to the reverse engineering
of the RCX done by Kekoa Proudfoot:
http://graphics.stanford.edu/~kekoa/rcx/
Your point is well-taken. Windows doesn't play ;-)
nice with UNIX. However, in the spirit of ingenuity, UNIX will play with Windows.
Samba 2.x clients can both register with and query
from WINS servers. Therefore, linux and UNIX users with samba properly configured can play the
NetBIOS/WINS resolution game just like everybody
else. You'll even show up in Network Neighborhood
(since that seems to be so important to windows
users).
As I point out in another post, WINS support in
DNS is only a partial hack. The NT DNS server only queries for WINS values from the
WINS server. It does NOT load that value into the
zone itself. Therefore, if you had a secondary
DNS server that wasn't NT DNS, it would not be
capable of knowing about that hostname because
its not in the zone and because it can't query
directly to the WINS server.
As it stands, there are other products that do
REAL DDNS injections during the DHCP process which
do REALLY update the zone file with the new
assignment (ISC DHCP + a script + BIND 8; MetaIP;
Cisco IP Registrar).
Your point about NT DNS not being a good option
for external DNS is a valid point. I agree.
A minor nitpick: MS DHCP Server doesn't really
bind to MS WINS Server. What actually happens is
that MS DHCP Server feeds WINS Server values to
the DHCP client. It is up to the DHCP client to
register/update with the WINS server. (sorry,
that was just me being overly correct and
nitpicky).
Partially correct:
As you're aware BIND 8, according to the RFCs, will NOT recognize the unserscore in a record in
any zone it is primary for. In other words, if BIND is primary server for foo.com, it will choke
and refuse to load the entire foo.com zone if
you put foo_bar.foo.com in that zone (there's a way to get around that with creative CNAMEs, but
that's another story).
However, if BIND 8 is secondary to a primary that
does allow underscores (ie, BIND 4.8.x or NT DNS),
it will go ahead and accept the transfer of both
the entire zone and the offending record. It will
just complain in the log file.
Look, DDNS has had basic support in BIND 8.x for
a couple of years now (with increasing quality in
each update). BIND administrators could do DDNS
injections with the nsupdate tool provided with
the BIND distribution, they could roll their own
scripts with the DNS module for perl, or they
could incorporate DDNS into ISC DHCP with Irina Goble's scripts or with the new beta code in ISC
DHCP 3.0. Cisco's IP Registrar and MetaIP are
commercial products that perform similar functions.
In point of fact, the article got its history wrong. The examples cited above, along with
the relevant RFCs, were help up to Microsoft as
examples of why the WINS lookup feature in NT DNS
was so inadequate. The incorporation of DDNS updates into the actual zones via IXFR allows for
propagation of the DDNS injections to heterogenous
secondary DNS servers unlike the WINS lookup "feature" in NT DNS.
so, don't fret about MS getting the upperhand on
DDNS, in and of itself. BIND 8 (and the forthcoming BIND 9) has got MS beat. What this
article was trying to allude to is this:
Although the Win2k implementation of DDNS might
actually be RFC compliant, it is quite probable
that the Active Directory tie-ins to DDNS will only work with the Win2k DDNS server. This is
crucial: even if Active Directory sucks, it has
huge appeal for Corporate America. It will be
implemented far and wide. This is what the article
alludes to: you'll have Win2k Active Directory
admins trying to require the DNS hostmasters to
convert to Win2K DDNS to support their Active Directory application.
Not quite ... the WINS lookup feature on NT DNS
will, as you pointed out, return WINS client values in response to dns queries to that NT
DNS server. However, it does not actually add
the WINS entry to the domain zone like DDNS does.
This doesn't really become too much of an issue
until you start setting up other DNS servers like
BIND to become secondaries to that NT DNS server.
Because the WINS entries aren't actually in the
zone, the secondary BIND servers CANNOT retrieve
the WINS values or lookups. Further, they cannot
retrieve the info from the WINS server directly
since the WINS resource type is not RFC compliant
and only works on NT DNS.
So, in this scenario, the non-NT DNS servers
are incapable of returning dns lookup queries
for any WINS client.
MS implemented DDNS in win2k to actually inject
netBIOS names into the dns zone like DDNS does
in ISC DHCP 3.0 and the nsupdate tool in BIND 8.x.
I enjoyed watching it. I thought the actors and
actress were actually quite good and believable
in their roles.
Oddly enough, however, I didn't find it as
scary or frightening as I had hoped, especially
the events leading up to the climax.
Also, there were a couple of things that were
irritating but probably limitations of the choice
of presentation: their constant giving up, sitting
down in the grass, and complaining about how lost
they are. I guess, though, that's better than a
whole movie of video shots of them walking and
complaining.
Despise these things, I still liked the film.
An ipv6 address is a hexadecimal address separated
by colons.
It looks like:
3ffe:1cf8:ff01:0:0:0:0:1 or:
fe80:0:0:0:0:0:cc60:c0a
where the first 64 bits is the network and
the last 64 bits is the host.
It's not random at all. If you look closely, you'll see that the inet6 address was generated
by wrapping an IPv6 compatible address around
your MAC address.
I believe (if I recall correctly) that IPv6
has generated a site-local address (sort of
equivalent to IPv4 private addressing) out of
your MAC.
According to the allocation draft document, http://www.arin.net/IPv6.txt, the 3 Registries
won't be initially assigning IP addresses to end users or sites. Instead, they'll be making sub-delegations to TLA registries (a sub-continental registry that will make allocations after the 1st 16 bit boundary of an
ipv6 subnet). So, ARIN, APNIC, and RIPE will begin
issuing TLA's to the TLA registries, who in turn,
will begin making allocations at the NLA level level. These NLA assignments will go to large ISP's. Assignments to individual sites and end-users will be carved out of these NLA assignments.
The last 64 bits is a hard boundary reserved for
the host ID (based on the next-generation EUI-64
MAC address).
Glossary:
TLA: Top-Level Aggregator
NLA: Next-Level Aggregator
SLA: Site-Level Aggregator