|
Phil -- See the last question/answer -- You have to "Phil" in the
blanks before sending this out. Also, I would like to be in
on the conversation so I can post the repartee -- unless you
want to take notes :-)
> >From: Susan A. Heath[SMTP:sheath@tcs-sec.com]
> >Sent: Thursday, April 24, 1997 3:29 PM
> >To: Philip Becker
> >Subject: RE: 4.0 questions
> >
> >Couple of questions.
> >
> >1. I needed to change the host name on a system. I ran the hostname
> >command and changed it with that. Then changed it in /etc/hosts and
> >/etc/rc.config. The system seems to be fine but I want to know if I
> >changed it everywhere that it really needs to be changed.
Every entry in /etc/hosts must have a corresponding entry in
TNETRHDB (see man TNETRHDB).
The best way to do this is to shutdown all network connections,
run dxhostmanager ("Network ISSO" option of the dxtp menu) and
add a new host with the proper name and IP address (you may have
to change your current hostname entry IP address).
Then exit dxhostmanager and edit /etc/rc.config with the new
name, then reboot.
But if you obey the syntax rules correctly for TNETRHDB,
then you can edit it. NOT a recommended procedure. Warning:
if you make a typo, there is no nice way it will tell you, it
just won't work.
> >2. When I am restoring from tape, the first time I try to access the tape
> >drive with the restore command, I get the following error "Tape read error:
> >not owner". If I do the command again, it works fine. So why do we get
> >the error?
I have not see this happen. If you can provide more detail,
perhaps we can reproduce this.
The only place I can find in the dump/restore code where
this message appears is where it initially tries to find the
tape block size if it already hasn't figured it out. What is
the exact syntax of the restore command you are using; and
what was the exact syntax of the dump command you used to
create the tape? (And on what rev, etc., did you create it
and what rev are you restoring it?)
> >3. When restoring, I get warnings about not being able to import
> >multilevel child directories - I think the exact error is "Warning: Cannot
> >import multilevel child directory" followed by the name of the child
> >multilevel directory. However, the directory seems to be restored ok. So
> >again, why the error and is it significant?
A multilevel child directory is a directory that is known
as an MLD directory. You may not see these unless you have
the multileveldir privilege. If you were unaware that you
had created these, then that's another issue. (They are
special-purpose SecureWare compatible directory types.)
What user are you when you are doing the dump? The restore?
(and what privs do they have if they are not root?)
Be sure you are running dump and restore at system high process SL.
> >4. We are frequently getting panics during boot. I haven't written down
> >the specific error yet because it goes by too quickly but I will write it
> >down and pass it on. Is there a known problem with panics during boot?
No. We need to have the panic information. At a minimum,
in /var/adm/crash, you should find a file named "crash-data.n"
where "n" is incremented each time a crash dump is taken.
There will also be corresponding vmcore and vmunix files.
For starters, mail us the crash-data file. Then we may
also ask you for your vmcore and vmunix files (will have to
be sent on tape). Don't delete these, write them to tape
if you need the space back in /var, until we see what the
problem is.
> >5. We are also attempting to start X in single user mode to run our
> >configuration tools and having a bunch of problems. I think we aren't
> >shutting down the X server correctly. I may need to talk to someone on the
> >phone about this. Is that possible?
[ Phil: Please make arrangements with Meg Williams about
possibly getting John's time to do this. I didn't think
you could run X in single-user mode: you need to have /usr
mounted and some other things -- maybe they mean in
multi-user mode when the network is not up? It is true
that if you want to start the X server by hand, you have
to worry about some things... ]
|
| From: US2RMC::"Becker@mail.dec.com" "Philip Becker" 25-APR-1997 14:05:53.12
To: "'BAT@smurf.enet.dec.com'" <smurf::BAT>
CC:
Subj: More from TCS on the answers
>----------
>From: Susan A. Heath[SMTP:sheath@tcs-sec.com]
>Sent: Friday, April 25, 1997 11:46 AM
>To: Philip Becker
>Subject: Re: More answers
>
>Phil,
>
>More data on this stuff.
>
>>>> >2. When I am restoring from tape, the first time I try to access the
>tape
>>>> >drive with the restore command, I get the following error "Tape read
>>>>error:
>>>> >not owner". If I do the command again, it works fine. So why do we get
>>>> >the error?
>>>
>>> I have not see this happen. If you can provide more detail,
>>> perhaps we can reproduce this.
>>>
>>> The only place I can find in the dump/restore code where
>>> this message appears is where it initially tries to find the
>>> tape block size if it already hasn't figured it out. What is
>>> the exact syntax of the restore command you are using; and
>>> what was the exact syntax of the dump command you used to
>>> create the tape? (And on what rev, etc., did you create it
>>> and what rev are you restoring it?)
>
>The tape was created on a 4.0a system and is being restored while booted
>off the 4.0a CDROM. The dump command was
>
>"dump -0nu -f /dev/nrmt0h /" (or whatever filesystem it was)
>
>The restore was done following the procedures that Phil faxed to me out of
>the Security Management Guide, section 6.4.
>
>Both dump and restore were done in single user mode, but we didn't set the
>sensitivity level to syshi before doing the dump so maybe that's part of
>the problem.
>
>>>> >3. When restoring, I get warnings about not being able to import
>>>> >multilevel child directories - I think the exact error is "Warning:
>Cannot
>>>> >import multilevel child directory" followed by the name of the child
>>>> >multilevel directory. However, the directory seems to be restored ok.
> So
>>>> >again, why the error and is it significant?
>>>
>>> A multilevel child directory is a directory that is known
>>> as an MLD directory. You may not see these unless you have
>>> the multileveldir privilege. If you were unaware that you
>>> had created these, then that's another issue. (They are
>>> special-purpose SecureWare compatible directory types.)
>>>
>>> What user are you when you are doing the dump? The restore?
>>> (and what privs do they have if they are not root?)
>>>
>>> Be sure you are running dump and restore at system high process SL.
>
>Yes, we were aware that we created an MLD. I think the problem is probably
>because the tape wasn't written at syshi. It didn't occur to me to do
>that. duh!
>
>>>
>>>> >4. We are frequently getting panics during boot. I haven't written
>>>>down
>>>> >the specific error yet because it goes by too quickly but I will write
>>>>it
>>>> >down and pass it on. Is there a known problem with panics during boot?
>>>
>>> No. We need to have the panic information. At a minimum,
>>> in /var/adm/crash, you should find a file named "crash-data.n"
>>> where "n" is incremented each time a crash dump is taken.
>>> There will also be corresponding vmcore and vmunix files.
>>> For starters, mail us the crash-data file. Then we may
>>> also ask you for your vmcore and vmunix files (will have to
>>> be sent on tape). Don't delete these, write them to tape
>>> if you need the space back in /var, until we see what the
>>> problem is.
>>>
>
>I'm not finding anything in the /var/adm/crash directory. I'll wait and
>check it each time. Would the panic message be in a syslog somewhere?
>
>Thanks for your help.
>
>Sue
>
>==========================================================================
>Susan A. Heath sheath@tcs-sec.com
>Trusted Computer Solutions, Inc. Phone: 703-318-7134
>13873 Park Center Road Fax: 703-318-5041
>Suite 225
>Herndon, VA 20171
>==========================================================================
|
| >The tape was created on a 4.0a system and is being restored while booted
>off the 4.0a CDROM. The dump command was
>
>"dump -0nu -f /dev/nrmt0h /" (or whatever filesystem it was)
So the dump took place while the system was up and running,
in multi-user mode, and you were user root?
>The restore was done following the procedures that Phil faxed to me out of
>the Security Management Guide, section 6.4.
Thanks, now we have a better picture of what you are trying to
do, we'll try and reproduce.
>I'm not finding anything in the /var/adm/crash directory. I'll wait and
>check it each time. Would the panic message be in a syslog somewhere?
Do you have sufficient space on the disk? There is also
a file which controls whether it will save core when you
crash, based on how much free space you want preserved on
the disk. See the savecore(8) man page. It also writes the
panic string (reason for panic) to a log file,
/var/adm/syslog/auth.log by default I think
|
| To: thomson
Cc: lct, may
Subject: DECnotes Reply 493 (dec_mls_plus)
Date: Fri, 25 Apr 97 13:28:21 -0400
From: lct
X-Mts: smtp
>1. I needed to change the host name on a system. I ran the hostname
>command and changed it with that. Then changed it in /etc/hosts and
>/etc/rc.config. The system seems to be fine but I want to know if I
>changed it everywhere that it really needs to be changed.
1) I believe that the command 'hostname' only sets the hostname for the
current boot. It does not change the name in /etc/rc.config.
2) The config files in /sys/conf are named the capitalized `hostname -s`
name. Any information that the user had put into the config file
would have to be recovered if/when they do another kernel build.
The default would be for doconfig to look for a file with the new
hostname.
3) In most cases, the users should use dxhostmanager for
adding, modifying, or deleting hosts. This prevents
all sorts of errors due to editing, format mistakes.
If the user did NOT reboot (the use of the hostname command would
imply no reboot), then, because of manual editing, the proper rh_flush
commands should be used to get the old information removed from
"in memory".
4) They also should run netsetup to correct the network
interface information instead of editing rc.config
(NETDEV_*= & IFCONFIG_*= lines) for the same reasons.
(if the IP address has also changed)
|