Rob wrote:

> Hello,
>
> I'm experiencing a strange problem on a SuSE 10.2 system. When I use
> vi to edit my /etc/hosts file and then attempt to save the file, the
> system hangs. In the subsequent reboot the system comes up without
> being able to read the hosts file. Further edits of the /etc/hosts
> file using vi prompt me with a "warning, previous .swp file found from
> prevous edit".
>
> To update the hosts file I copy a backup hosts file, modified, to /etc/
> hosts and then reboot the system again to bring it up correctly.
> Additionally, I just modified my /etc/motd and encountered the same
> problem.
>
> The box is idle and I'm the only user logged in when making these
> changes. Any ideas why this might be happening?
>
> Thanks!
>
> Rob

Do you have permission to save to this directory ? You'll need to be ROOT
(su) in most cases. So open vi as root then save.

i.e. -> su -> (provide root password) -> vi /etc/fstab. Save.

Just guessing but this seems obvious.

On Sep 14, 6:55 pm, Michael Soibelman
wrote:
> Rob wrote:
> > Hello,
>
> > I'm experiencing a strange problem on a SuSE 10.2 system. When I use
> > vi to edit my /etc/hosts file and then attempt to save the file, the
> > system hangs. In the subsequent reboot the system comes up without
> > being able to read the hosts file. Further edits of the /etc/hosts
> > file using vi prompt me with a "warning, previous .swp file found from
> > prevous edit".
>
> > To update the hosts file I copy a backup hosts file, modified, to /etc/
> > hosts and then reboot the system again to bring it up correctly.
> > Additionally, I just modified my /etc/motd and encountered the same
> > problem.
>
> > The box is idle and I'm the only user logged in when making these
> > changes. Any ideas why this might be happening?
>
> > Thanks!
>
> > Rob
>
> Do you have permission to save to this directory ? You'll need to be ROOT
> (su) in most cases. So open vi as root then save.
>
> i.e. -> su -> (provide root password) -> vi /etc/fstab. Save.
>
> Just guessing but this seems obvious.

If I try to edit /etc/hosts without the rights to do it, I get
"/etc/hosts" E212: Can't open file for writing
The system does NOT freeze, none of the other symptoms are observed.

Having said that, I don't have a clue what the real problem is here
either.

Rob wrote:

> Hello,
>
> I'm experiencing a strange problem on a SuSE 10.2 system. When I use
> vi to edit my /etc/hosts file and then attempt to save the file, the
> system hangs. In the subsequent reboot the system comes up without
> being able to read the hosts file. Further edits of the /etc/hosts
> file using vi prompt me with a "warning, previous .swp file found from
> prevous edit".
>
> To update the hosts file I copy a backup hosts file, modified, to /etc/
> hosts and then reboot the system again to bring it up correctly.
> Additionally, I just modified my /etc/motd and encountered the same
> problem.
>
> The box is idle and I'm the only user logged in when making these
> changes. Any ideas why this might be happening?
>
> Thanks!
>
> Rob

Perhaps launch vi from a terminal to see error messages.

Rob wrote:
>Hello,

>I'm experiencing a strange problem on a SuSE 10.2 system. When I use
>vi to edit my /etc/hosts file and then attempt to save the file, the
>system hangs. In the subsequent reboot the system comes up without
>being able to read the hosts file. Further edits of the /etc/hosts
>file using vi prompt me with a "warning, previous .swp file found from
>prevous edit".

>To update the hosts file I copy a backup hosts file, modified, to /etc/
>hosts and then reboot the system again to bring it up correctly.
>Additionally, I just modified my /etc/motd and encountered the same
>problem.

>The box is idle and I'm the only user logged in when making these
>changes. Any ideas why this might be happening?

>Thanks!

This is very strange.

Have you tried to edit any other file in /etc?

Does cp /etc/hosts /etc/hosts.backup work?

Do you have this problem in any other directories?

In other words, I'd try to find the extent of this problem.

I assume, of course, that you are root when all of this happens.

It is clear that something out of the ordinary is going on. There
is either an incomplete or broken file somewhere or you've been
rooted and some programs have been trojaned. Or, perhaps there is
a strange bad region on your hard drive. Or Martians have landed.
Or something...

--
--- Paul J. Gans

Rob writes:

>Hello,

>I'm experiencing a strange problem on a SuSE 10.2 system. When I use
>vi to edit my /etc/hosts file and then attempt to save the file, the

As root?

>system hangs. In the subsequent reboot the system comes up without

It should not. WHat changes have you made?

You can do
cp /etc/hosts /etc/hosts.modify
vi /etc/hosts.modify
mv /etc/hosts.modify /etc/hosts


>being able to read the hosts file. Further edits of the /etc/hosts
>file using vi prompt me with a "warning, previous .swp file found from
>prevous edit".

>To update the hosts file I copy a backup hosts file, modified, to /etc/
>hosts and then reboot the system again to bring it up correctly.

No need to reboot. /etc/hosts is reread each time it is needed. Ie there is
no buffering of /etc/hosts.

>Additionally, I just modified my /etc/motd and encountered the same
>problem.

Weird.


>The box is idle and I'm the only user logged in when making these
>changes. Any ideas why this might be happening?

>Thanks!

>Rob

On Sep 14, 11:36 am, Paul J Gans wrote:
> Rob wrote:
> >Hello,
> >I'm experiencing a strange problem on a SuSE 10.2 system. When I use
> >vi to edit my /etc/hosts file and then attempt to save the file, the
> >system hangs. In the subsequent reboot the system comes up without
> >being able to read the hosts file. Further edits of the /etc/hosts
> >file using vi prompt me with a "warning, previous .swp file found from
> >prevous edit".
> >To update the hosts file I copy a backup hosts file, modified, to /etc/
> >hosts and then reboot the system again to bring it up correctly.
> >Additionally, I just modified my /etc/motd and encountered the same
> >problem.
> >The box is idle and I'm the only user logged in when making these
> >changes. Any ideas why this might be happening?
> >Thanks!
>
> This is very strange.
>
> Have you tried to edit any other file in /etc?
>
> Does cp /etc/hosts /etc/hosts.backup work?
>
> Do you have this problem in any other directories?
>
> In other words, I'd try to find the extent of this problem.
>
> I assume, of course, that you are root when all of this happens.
>
> It is clear that something out of the ordinary is going on. There
> is either an incomplete or broken file somewhere or you've been
> rooted and some programs have been trojaned. Or, perhaps there is
> a strange bad region on your hard drive. Or Martians have landed.
> Or something...
>
> --
> --- Paul J. Gans

Hello Paul,

I guess I assumed that bring root was implied. Yes, in every case I'm
operating as root. I've used vi for editing other files and vi seems
to operate and save files as expected. The only files I've had
problems with are hosts and motd. I've got a user on the box right
now so I can't play with it, but I'll try some other system files in
etc and see what happens. I know I've edited systems, fstab, and
profile without any problems. My work around for this problem is to
copy the hosts file to /tmp and modify it there. Once modified I copy
it back to /etc. Same thing with motd. To verify I simply cat the
files and they look normal.

This system was built on a closed network. I've been patching the
systems using a patch CD. At no time has the system been connected to
the internet. The system is fully patched as of yesterday.

Is there more information I could provide that would be helpful?

Thanks!

Rob

On Sep 14, 11:36 am, Paul J Gans wrote:
> Rob wrote:
> >Hello,
> >I'm experiencing a strange problem on a SuSE 10.2 system. When I use
> >vi to edit my /etc/hosts file and then attempt to save the file, the
> >system hangs. In the subsequent reboot the system comes up without
> >being able to read the hosts file. Further edits of the /etc/hosts
> >file using vi prompt me with a "warning, previous .swp file found from
> >prevous edit".
> >To update the hosts file I copy a backup hosts file, modified, to /etc/
> >hosts and then reboot the system again to bring it up correctly.
> >Additionally, I just modified my /etc/motd and encountered the same
> >problem.
> >The box is idle and I'm the only user logged in when making these
> >changes. Any ideas why this might be happening?
> >Thanks!
>
> This is very strange.
>
> Have you tried to edit any other file in /etc?
>
> Does cp /etc/hosts /etc/hosts.backup work?
>
> Do you have this problem in any other directories?
>
> In other words, I'd try to find the extent of this problem.
>
> I assume, of course, that you are root when all of this happens.
>
> It is clear that something out of the ordinary is going on. There
> is either an incomplete or broken file somewhere or you've been
> rooted and some programs have been trojaned. Or, perhaps there is
> a strange bad region on your hard drive. Or Martians have landed.
> Or something...
>
> --
> --- Paul J. Gans

Hello Paul,

So, it looks like the files affected are being audited. I'm using the
following /etc/audit.rules

----------------------------------------------------------------------------------------------
##
## This file contains the a sample audit configuration intended to
## meet the NISPOM Chapter 8 rules.
##
## This file should be saved as /etc/audit/audit.rules.
##

## Remove any existing rules
-D

## Increase buffer size to handle the increased number of messages.
## Feel free to increase this if the machine panic's
-b 8192

## Set failure mode to panic
-f 2

## Audit 1, 1(a) Enough information to determine the date and time of
## action (e.g., common network time), the system locale of the
action,
## the system entity that initiated or completed the action, the
resources
## involved, and the action involved.

## Things that could affect time
-a entry,always -S adjtimex -S settimeofday -k time-change
-w /etc/localtime -p wa -k time-change

## Things that could affect system locale
-a exit,always -S sethostname -k system-locale
-w /etc/issue -p wa -k system-locale
-w /etc/issue.net -p wa -k system-locale
-w /etc/motd -p wa -k system-locale
-w /etc/ssh/sshd_config -p wa -k system-locale
-w /opt/kde3/share/config/kdm/kdmrc -p wa -k system-locale
-w /etc/hosts -p wa -k system-locale
-w /etc/sysconfig/network -p wa -k system-locale

## Audit 1, 1(b) Successful and unsuccessful logons and logoffs.
## This is covered by patches to login, gdm, and openssh
## Might also want to watch these files if needing extra information
-w /var/log/faillog -p wa -k logins
-w /var/log/lastlog -p wa -k logins

## Audit 1, 1(c) Successful and unsuccessful accesses to
## security-relevant objects and directories, including
## creation, open, close, modification, and deletion.

## unsuccessful creation
-a exit,always -S creat -S mkdir -S mknod -S link -S symlink -F
exit=-13 -k creation
-a exit,always -S mkdirat -S mknodat -S linkat -S symlinkat -F
exit=-13 -k creation

## unsuccessful open
-a exit,always -S open -F exit=-13 -k open
-a exit,always -S openat -F exit=-13 -k open

## unsuccessful close
-a exit,always -S close -F exit=-13 -k close

## unsuccessful modifications
-a exit,always -S rename -S truncate -S ftruncate -F exit=-13 -k mods
-a exit,always -S renameat -F exit=-13 -k mods
#-a exit,always -F perm=a -F exit=-13 -k mods

## unsuccessful deletion
-a exit,always -S rmdir -S unlink -F exit=-13 -k delete
-a exit,always -S unlinkat -F exit=-13 -k delete

## Audit 1, 1(d) Changes in user authenticators.
## Covered by patches to libpam, passwd, and shadow-utils
## Might also want to watch these files for changes
-w /etc/group -p wa -k auth
-w /etc/passwd -p wa -k auth
-w /etc/gshadow -p wa -k auth
-w /etc/shadow -p wa -k auth
-w /etc/security/opasswd -p wa -k auth
-w /etc/samba/smbpasswd -p wa -k auth

## Audit 1, 1(e) The blocking or blacklisting of a user ID,
## terminal, or access port and the reason for the action.
## Covered by patches to pam_tally

## Audit 1, 1(f) Denial of access resulting from an excessive
## number of unsuccessful logon attempts.
## Covered by patches to pam_tally

## Audit 1, 2 Audit Trail Protection. The contents of audit trails
## shall be protected against unauthorized access, modification,
## or deletion.
## This should be covered by file permissions, but we can watch it
## to see any activity
-w /var/log/audit/ -k audit-logs
-w /var/log/audit/audit.log -k audit-logs
-w /var/log/messages -k audit-logs
-w /var/log/wtmp -k audit-logs
-w /var/log/lastlog -k audit-logs
#-w /var/log/audit/audit.log.1 -k audit-logs
#-w /var/log/audit/audit.log.2 -k audit-logs
#-w /var/log/audit/audit.log.3 -k audit-logs
#-w /var/log/audit/audit.log.4 -k audit-logs

## Not specifically required by NISPOM; but common sense items
## Optional - could indicate someone trying to do something bad or
## just debugging
#-a entry,always -S ptrace

## Optional - could be an attempt to bypass audit or simply legacy
program
#-a exit,always -S personality

## Put your own watches after this point
# -w /your-file -p rwxa -k mykey
-w /boot -p rwxa -k boot-config
----------------------------------------------------------------------------------------------

Each of the files listed in audit.rules listed above, /etc/passwd, /
etc/group, /etc/motd, /etc/issue, etc. hang the system when saved in
vi. Other files like /etc/services and such are uneffected. Below is
the final bits of an strace vi /etc/group

----------------------------------------------------------------------------------------------
read(0, "\r", 250) = 1
select(1, [0], NULL, [0], {0, 0}) = 0 (Timeout)
write(1, "\r", 1) = 1
write(1, "\33[?25l", 6) = 6
ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon
echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0
write(1, "\"/etc/group\" ", 13) = 13
stat("/etc/group", {st_mode=S_IFREG|0644, st_size=765, ...}) = 0
access("/etc/group", W_OK) = 0
getxattr("/etc/group", "system.posix_acl_access", 0x7fff52ac0500, 132)
= -1 ENODATA (No data available)
stat("/etc/group", {st_mode=S_IFREG|0644, st_size=765, ...}) = 0
lstat("/etc/group", {st_mode=S_IFREG|0644, st_size=765, ...}) = 0
lstat("/etc/4913", 0x7fff52ac0870) = -1 ENOENT (No such file or
directory)
open("/etc/4913", O_WRONLY|O_CREAT|O_EXCL, 0100644) = 5
fchown(5, 0, 0) = 0
stat("/etc/4913", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
close(5) = 0
unlink("/etc/4913") = 0
stat("/etc/group~", {st_mode=S_IFREG|0644, st_size=679, ...}) = 0
stat("/etc/grouz~", 0x7fff52ac05b0) = -1 ENOENT (No such file or
directory)
stat("/etc/group", {st_mode=S_IFREG|0644, st_size=765, ...}) = 0
unlink("/etc/grouz~") = -1 ENOENT (No such file or
directory)
rename("/etc/group", "/etc/grouz~"

----------------------------------------------------------------------------------------------
Any ideas on why this is causing problems? I'm using this same config
file on six other SuSE 10.2 systems that are not experiencing this
problem.

Thanks!

Rob

Rob wrote:


>Hello Paul,

>I guess I assumed that bring root was implied. Yes, in every case I'm
>operating as root. I've used vi for editing other files and vi seems
>to operate and save files as expected. The only files I've had
>problems with are hosts and motd. I've got a user on the box right
>now so I can't play with it, but I'll try some other system files in
>etc and see what happens. I know I've edited systems, fstab, and
>profile without any problems. My work around for this problem is to
>copy the hosts file to /tmp and modify it there. Once modified I copy
>it back to /etc. Same thing with motd. To verify I simply cat the
>files and they look normal.

>This system was built on a closed network. I've been patching the
>systems using a patch CD. At no time has the system been connected to
>the internet. The system is fully patched as of yesterday.

>Is there more information I could provide that would be helpful?

>Thanks!

No. I think that we are forced to the conclusion that either
your software has been modified in some strange way or that
your computer setup is very strange.

The "hanging" indicates of course that the operation was not
finished. The system has no reason to treat different filenames
differently, nor to treat different directories differently.

All that assumes proper permissions. But as root I'd not think
that would matter.

Have you tried using a different editor? That might be instructive.

--
--- Paul J. Gans