Subject: Re: Debian quirks?

From: [email-masked] (Bruce Perens)
Date: Tue, 20 Aug 96 13:18 PDT

From: Vebjoern Forsmo <[email-masked]>
> /etc/inittab:
> 1:2345:respawn:/bin/login root </dev/tty1 >/dev/tty1 2>&1

Login does have a built-in 60-second timeout at the "password:" prompt,
and might have a timeout at the "login:" prompt too, I don't remember.

If you run a more normal getty/login on this terminal, you won't have the
problem. If you insist on doing it this way, you might have to hack the
source code if you can't find a solution in the login man page.

> Several programs seems to prefer /tmp over /var/tmp.

/tmp should probably be a symbolic link to var/tmp .

	Bruce

---

From: Vebjoern Forsmo <[email-masked]>
Date: Wed, 21 Aug 1996 11:07:15 +0200 (METDST)

> and might have a timeout at the "login:" prompt too, I don't remember.

The above line puts you right at the password: prompt, so the 60 second
password timeout is the cause of the problem.

> source code if you can't find a solution in the login man page.

I've changed this back to a "normal" entry, but the above is what was
installed by the bootdisks available sometime around the beginning of
August when I installed Debian on a server.  Sysvinit 2.64-1 has a normal
looking inittab.

Anyway, there was a comment too:

# This is the only special line - the rest is straight from the normal inittab.
1:2345:respawn:/bin/login root </dev/tty1 >/dev/tty1 2>&1

> /tmp should probably be a symbolic link to var/tmp .

I too thought about doing it this way, but I'm a bit unsure about what
happens if the partition /var/tmp resides on can't be mounted? (Are there
any important programs that depend upon /tmp?)

Vebby

---

From: Pete Harlan <[email-masked]>
Date: Wed, 21 Aug 1996 14:11:37 -0500 (CDT)

> > /tmp should probably be a symbolic link to var/tmp .

I believe the way to do it is to have /tmp be a real directory in the
root filesystem, and then mount a larger filesystem over it later.
Programs that get run before /tmp is mounted over have the limited
space, and all others (i.e., just about everyone) see the large /tmp.

Root's /tmp can't be seen once it's mounted over, but processes that
have an open file there can still access it.  When the overlaying
device is unmounted, root's /tmp becomes visible again.

The biggest danger is that it's difficult to see what's building up in
root's /tmp if it's always covered up by the time you log in.

--
Pete Harlan
[email-masked]

---

From: Dominik Kubla <[email-masked]>
Date: Thu, 22 Aug 1996 05:55:43 +0200

>>>>> Pete Harlan writes:

> I believe the way to do it is to have /tmp be a real directory in
> the root filesystem, and then mount a larger filesystem over it
> later.  Programs that get run before /tmp is mounted over have the
> limited space, and all others (i.e., just about everyone) see the
> large /tmp.

Nope, the way to go is to finally implement a true memory-fs and make
/tmp a mfs.  Every other U**x (except HP-UX) does it that way (or has
the option to do it that way).

Dominik

---

From: [email-masked] (Miquel van Smoorenburg)
Date: 21 Aug 1996 19:38:24 +0200

In article <[email-masked]>,
>any important programs that depend upon /tmp?)

A nice solution is to boot into single user mode, umount /var, and
do the following:

mkdir /var/tmp
chmod 1777 /var/tmp
rmdir /tmp
ln -s /var/tmp /tmp

Now there is a /var/tmp directory. When you mount the real /var "over" it
you won't see it anymore but it will be there if /var can't be mounted.

The only thing you have to watch for is that you don't put any junk
in it when you are working with /var unmounted; you can't get to it
anymore to cleanup as soon as you have mounted the real /var over it.
(It _is_ an ideal place to hide stuff, though :))

Mike.
-- 
+   Miquel van Smoorenburg   + Cistron Internet Services +  Living is a     |
|  [email-masked] (SP6)  | Independent Dutch ISP     |   horizontal     |
+ [email-masked] + http://www.cistron.nl/    +      fall        +