| > How does the netsetup program determine what
> interfaces are on the system?
I don't believe netsetup does the determination, I think
the OS does it at boot up.
> And is there a way to determine which
> interface is the on board one?
Yes. We think it is the last one (which the OS numbers as
the highest numbered one). Lee is going to check with the
vanilla Unix driver people upstairs.
> We need to determine this as well in one of
> our programs and we have not been successful in figuring out how
> to determine it. The systems for SOUTHCOM all have tu0 and tu1 interfaces but
> I don't think we can count on this being the case on all systems and in any
> case, we need to be able to determine how many boards are there and what
> the interface name for them is. And we need to determine this without the
> interfaces being configured in /etc/rc.config. Just one point on this
> question - we need to determine this from a program in single user mode
> with no user intervention before the interfaces have been configured.
In the statement "we need to be be able to determine how many boards
are there and what the interface name is for them", by "we" I presume
you mean "we want to write a program or script to determine..."
For the purposes of this discussion, assume the highest numbered one
is the on-board card. (We're double-checking that.)
The uerf command reports the syslog events, and in the uerf output
you will see what the OS thinks about what hardware is there each
time it boots.
I would think that it's possible to either write code to look at the
system log or scripts to look at uerf output, and from that determine
the devices that exist, and what they are numbered. The highest
numbered one will be the on-board one.
> Also, I've been told that the system sets the tu0 interface to be the first
> board it finds when doing the hardware check during boot and that is not
> going to be the on board interface when there are additional ethernet cards
> installed. This rings true with what we are finding. Our systems have an
> on board interface and one additional ethernet card. The additional
> ethernet card turns out to be tu0 and the on board one is tu1. Does this
> mean that if I remove the additional ethernet board, the on board one
> automatically becomes tu0 and I have to go reset the interface up?
I think so, yes.
> This could cause some potential problems. On our systems we set up
> multiple interfaces, one from system high to system low and then multiple
> others at some lower subset. For example, we may have the highest
> interface have data from Top Secret down to Unclassified. Another
> interface may have data from Secret down to Unclassified and another one
> may have data from Confidential down to Unclassified. Each of these
> interfaces is connected a network that is accredited to have data at ONLY
> those sensitivity levels. Before now, we always made the on board
> interface be the one that was at system high to system low and then lined
> the others up on the additional boards. If one of the extra interfaces was
> removed, it only affected that network.
Not exactly. It affected that network *and* all the network cards
"to the right of it" (if you are looking at the backplane from
left=low and right=high). Even if Unix numbered the logical units
starting with 0 for the "highest" board on the bus, the ISSO still
has the problem of adjusting software configuration for the other
cards.
If you did write a script to reverify which card is the on-board card,
and have it make sure that the on-board card is {a, the only} card
that gets the syslo<->syshi accrediation range, what security policy
are you going to establish about the other cards, if when you boot up
you discover that the on-board card now has a new unit number?
Are you going to invalidate all the others if there is a mismatch
between the "current card count in TNETIDB" and the actual card
count your check routine finds during startup? If not, how are you
going to reassign the accreditation ranges for the remaining cards?
Are you going to maintain a database that associates each MAC address
for the card with some accreditation range? What if someone swaps
a card out for maintenance? Who is going to keep that table
up-to-date? What if someone changes the cables in the back,
without even removing a card?
What I'm trying to point out here is that, as soon as you allow someone
to mess with the hardware configuration, you *ought* to require
someone to mess with the software configuration. To be sure, one
could make the software configuration adjustments more user-friendly
-- but if you make them automatic, you are going to have to write
a security policy for what the automated procedures are going to do.
And no matter how automated they are, there still have to be
instructions for people messing with the cables in the back, or
moving or removing cards.
> It appears now that the interface
> name of the on board interface (and potentially all the others as well)
> will change if the one or more of the additional ethernet boards is
> removed. This could be a big problem for us if customers don't realize
> they then have to go in and reassigned the sensitivity levels to all the
> interfaces because the names of them changed.
If what you are asking for is to have Unix assign logical names to
the devices that match the fixed hardware slots for the devices,
then that's a suggestion we could pass on to the base Unix developers.
Perhaps there's a reason for the way they did it other than "it was
easy to write the code that way".
However, doing that still does not mean you get out of reconfiguring
the software at some point -- unless there is some AI way to determine
which card you want to have what accreditation range (mind reading
does not count) -- because what do you do if someone moves a card
from one slot to another? Or if you base the identification on
the MAC address, if they swap out cards? Or change the cables in
the back?
> I'd like to be able to
> maintain the rule that the on board interface is the one with the system
> high to system low data on it, but we can't find a way to determine which
> interface is the on board one. Is there a mechanism to do this or is there
> some naming scheme that we can count on to be true in all cases for all
> types of hardware?
Yes, it's the algorithm that the OS software uses today to logically
(I use that as computer term, not as a cognitive one) name the
hardware devices and units that it sees when it boots up. That is,
I don't believe it's an arbitrary assignment. However, it may not
be what appears to be a friendly process for users to change -- but
that's what keeps Unix software engineers employed, no? :-) At least
for the short{sighted}-term...
Perhaps if we had some better idea of what you are trying to
automate for the user -- is it just the initial configuration
setup? Or is it some on-going self-adjusting procedure?
If you are just trying to make the system come up with at
least one card already configured when they first install the
"packaged" system, then it should be possible to write a start-up
script that finds out what the on-board card is and set it up
with "default" characteristics...
|