Re: Sizes and Packages in dselect

[Bill Mitchell]

On Wed, 4 Oct 1995, Ian Jackson wrote:

[...]
> > For each file in the files list, find the deepest existing directory
>   ^^^
> 
> This is where the problem starts :-).  Obviously this can be done
> fairly easily if you're willing to have the user download a list of
> all the files included in every package, plus their sizes.  I don't
> think that's reasonable, though; even compressed, the Contents file
> for just the main part of the distribution is 120Kb.

We've covered this ground before, several times.  I didn't take
the time to try to dredge up past discussions, but did a quick
test.  I don't have the current distribution handy at the
moment, but I do happen to have bits and pieces from 0.93r5.
The packages I have in the base directory total 3619624 bytes.
"dpkg --contents" gives a bit more verbose of a list than would
be needed for sizing.  "dpkg --contents" on all these packages,
putting the output into separate files, produces a total of 213503
bytes of data.  "gzip -9" on all those output files reduces that
to 25172 bytes of data.  That's about 0.7% additional overhead.
Actually, it'd be less that that since the "dpkg --contents" output
is more verbose than would be needed.  (my previous suggestion was
to include as part of package overhead a file with pathname, size,
and md5sum information for all files in the package -- with this
info being determined at package build time).

[...]
> I think it's probably better just to stick a single `Size' field in
> the Packages file.

Which wouldn't help in sizing per-partition usage.

Re: Sizes and Packages in dselect

[stick]

Ian Jackson said:
> From chuck Tue Oct  3 22:02:24 1995
> Return-Path: 
> Received: by bertha.richnet.net
>   id <[EMAIL PROTECTED]>
>   (Debian /\oo/\ Smail3.1.29.1 #29.33); Tue, 3 Oct 95 22:02 EDT
> Resent-Sender: chuck (Charles A. Stickelman)
> X-POP3-Rcpt: [EMAIL PROTECTED]
> Received: from mongo.pixar.com (mongo.pixar.com [138.72.50.60]) by 
> ns1.richnet.net (8.6.12/8.6.12) with SMTP id VAA11211 for <[EMAIL 
> PROTECTED]>; Tue, 3 Oct 1995 21:35:12 -0400
> Resent-Date: Tue, 3 Oct 1995 21:35:12 -0400
> Received: by mongo.pixar.com (Smail3.1.28.1 #15)
>   id m0t0IiA-000D7iC; Tue, 3 Oct 95 18:33 PDT
> Old-Return-Path: <[EMAIL PROTECTED]>
> Message-Id: <[EMAIL PROTECTED]>
> Date: Wed, 4 Oct 95 02:31 BST
> From: Ian Jackson <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Sizes and Packages in dselect 
> In-Reply-To: <[EMAIL PROTECTED]>
> References: <[EMAIL PROTECTED]>
>   <[EMAIL PROTECTED]>
> Resent-Message-ID: <"vUNHY.A.MFE.oRecw"@mongo>
> Resent-From: [EMAIL PROTECTED]
> X-Mailing-List: <[EMAIL PROTECTED]> archive/latest/6456
> X-Loop: [EMAIL PROTECTED]
> Precedence: list
> Resent-Sender: [EMAIL PROTECTED]
> 
> Bruce Perens writes ("Re: Sizes and Packages in dselect "):
> > I think I have the algorithm to do this. Please see if the following makes
> > sense. I can give you pseudocode (or real code) if necessary.
> > 
> > For each file in the files list, find the deepest existing directory
>   ^^^
> 
> This is where the problem starts :-).  Obviously this can be done
> fairly easily if you're willing to have the user download a list of
> all the files included in every package, plus their sizes.  I don't
> think that's reasonable, though; even compressed, the Contents file
> for just the main part of the distribution is 120Kb.
> 
> > Does this make sense? I can elaborate if you like.
> 
> Yes, your algorithm probably makes sense (I didn't read it in great
> detail).  However, the problem isn't the algorith, I think, but the
> question of how to get the data it needs to dselect.
> 
> I think it's probably better just to stick a single `Size' field in
> the Packages file.
> 

Maybe we should do both.  Include file sizes in the .list files, use
Bruce's algorithm (or something like that) to compute the 'Size'
field in the Packages file.  That way the users could get the information
initially when they grab the Packages file and a running system could
use the .list files to get more system-specific information.

It may not be necessary for dselect/dpkg to function identically
identically during install as they do on a running system.  If the
user is doing a "vanilla" Debian install (whatever that may be)
just show the 'Size' values.  If they are doing a more complicated
install with multiple partitions (networking or whatever) then why
not allow them to use this level of detailed information?

I'm an advocate of adding more information to the .list files
(user/group, mode, size, md5sum and perhaps hard-link info, etc.)
even if it forces us to use data-compression.

> Ian.
> 
> 
Chuck

-- 
Charles A. Stickelman   <[EMAIL PROTECTED]>
Practical Network Design(419) 529-3841
9 Chambers Road
Mansfield, OH 44906 USA
--

Test; please ignore (#1)

[J.H.M.Dassen]

Mailing lists archive test.
-- 
POPULATION EXPLOSION  Unique in human experience, an event which happened 
yesterday but which everyone swears won't happen until tomorrow.  
- The Hipcrime Vocab by Chad C. Mulligan 

Test; please ignore (#2)

[J.H.M.Dassen]

-- 
POPULATION EXPLOSION  Unique in human experience, an event which happened 
yesterday but which everyone swears won't happen until tomorrow.  
- The Hipcrime Vocab by Chad C. Mulligan 

Test; please ignore (#3)

[J.H.M.Dassen]

-- 
POPULATION EXPLOSION  Unique in human experience, an event which happened 
yesterday but which everyone swears won't happen until tomorrow.  
- The Hipcrime Vocab by Chad C. Mulligan 

Test; please ignore (#4)

[J.H.M.Dassen]

-- 
POPULATION EXPLOSION  Unique in human experience, an event which happened 
yesterday but which everyone swears won't happen until tomorrow.  
- The Hipcrime Vocab by Chad C. Mulligan 

Bug#1541: root can't login on /dev/tty2 4 and 6

[Erick Branderhorst]

Package: base
Version: 0.93.6-7
Libc: libc.so.4.6.27
Kernel etc: Linux morris 1.2.10 #1 Tue Jun 13 18:37:28 EST 1995 i486
Reporter: repair 0.1
Subject: root refused on this terminal and /etc/motd

I installed base with dpkg-1.0 and now I have my GPL in
/usr/doc/copyright back. That's why I did it.

Unfortunately I'm not able to login as root on the following tty's:
/dev/tty2 /dev/tty4 and /dev/tty6. This is since installing
base-0.93.6-7.deb.

Erick

I also decided to install /etc/motd from base-0.93.6-7.deb. The
default information in this file is somewhat misleading. The first
line is telling something about the system where it was created
on. This is not representative for my system of course. Perhaps this
line should change and show a more general valid message.

When I do uname --all this is what I get:
Linux morris 1.2.10 #1 Tue Jun 13 18:37:28 EST 1995 i486


The next line is in /etc/motd:
Linux beagle 1.3.20 #7 Thu Aug 17 10:55:46 PDT 1995 i486

Re: Sizes and Packages in dselect

[Ian Jackson]

Raul Miller writes ("Re: Sizes and Packages in dselect"):
> Ian Jackson:
>This is where the problem starts :-).  Obviously this can be done
>fairly easily if you're willing to have the user download a list of
>all the files included in every package, plus their sizes.  I don't
>think that's reasonable, though; even compressed, the Contents file
>for just the main part of the distribution is 120Kb.
> 
> On the other hand, it shouldn't be too hard to modify dpkg-deb to
> compute summary information for each directory which is being
> packaged.  (number of blocks, number of inodes directly in each
> directory).  For packages which have some significant postinst
> overhead, these estimates could be put in some file in the DEBIAN/
> directory for the package.

Yes, but where would that get you ?  When the user is initially
selecting packages all that dselect has seen is the Packages file -
this file is only 30K compressed.

The problem isn't extracting the information from .deb files.

There are two main problems: firstly, the information about sizes has
to be given to dselect somehow, and this has to be done *without*
processing all of the .deb files before the package selection takes
place.  Secondly, doing per-filesystem accounting may well produce
complicated and probably-incorrect code in dselect.

Set against this, I don't think many people will use this feature.
Almost all of the stuff that you might choose whether to install lives
in /usr somewhere, and few people subpartition /usr (I'm not counting
/usr/local, here).  Those that do will be experts who will be aware of
things like the relative sizes of /usr/lib and the rest of /usr.

> I don't think the storage requirements for this kind of information
> would be at all outrageous:

It's not the storage, it's the transmission.  For someone who is
downloading the distribution onto floppies an extra 120K file is
rather on the large side, considering that they'll probably never use
the extra functionality it buys the system.

> Besides, the packing problem is a hard one to deal with -- so it's
> very worthy of whatever automatic assistance we can provide.

I'm confused.  Which packing problem is this ?  I don't think the
decision about how to partition your disk is difficult: if you're
having trouble with it, make one big partition - this is fine for most
users, now that our fsck tools are as good as they are.

Do you refer to the problem of how to pack .deb files onto floppies,
if that's what you're doing ?  In that case I agree with you, but I
don't see how that's relevant to the question at hand.

Bill Mitchell writes ("Re: Sizes and Packages in dselect "):
> [...]
> The packages I have in the base directory total 3619624 bytes.
> "dpkg --contents" gives a bit more verbose of a list than would
> be needed for sizing.  "dpkg --contents" on all these packages,
> putting the output into separate files, produces a total of 213503
> bytes of data.  "gzip -9" on all those output files reduces that
> to 25172 bytes of data.  That's about 0.7% additional overhead.

If you look at the size of the whole main distribution, about 80Mb,
the Contents file (which compresses very well) is about 1.5%.
However, what you're forgetting there is that the user will have to
download the whole file even if they only want to install a small
subset of the packages.

I'd be interested to see someone find out how large a file is that
lists disk use per directory for each package.  Ie, something like
 hello:
  3 /usr/doc/copyright
  8 /usr/bin
  9 /usr/info
but for each package.  (The numbers are Kb, rounded up.)  If this
turns out to be a reasonable size then we could have a Size field in
the Packages file that contained this information.  (If we do
mkpackages right then we can have package maintainers override this
information simply by providing a Size field of the right form.)

> > I think it's probably better just to stick a single `Size' field in
> > the Packages file.
> 
> Which wouldn't help in sizing per-partition usage.

That's right.  How many people have needed to do this ?  Disks
nowadays are so big that subdividing the /usr partition doesn't have
much point, and the usages on /, /var and /home are (a) small and (b)
very dependent on the local situation.

Ian.

Bug#1391

[Nils Rennebarth]

texbin *does* depend on texlib. It is listed in the dependencies.
The dependencies however appear to be satisfied by an older revision
of texlib, that will not have all required scripts. Is this a bug
in dpkg? The poster didn't state the dpkg version.

Anyway it is not a texlib bug, so I close this one.

Bug#1542: adduser: doesnt create dirs

[Karl Ferguson]

Package: adduser
Version: 1.94

Hi again..

This isnt a bug - more a note...  If I create a directory in /etc/skel where
adduser copies the default files for new accounts in there it doesn't create
the directory.  Would it be good to have this feature?  ie: public_html
directories etc etc...

...Karl

--

 | PO Box 828   Office: (09)316-3036 Fax: (09)381-3909
 |OWER INTERNET SERVICES   Canning Bridge   After Hours:  015-779-828
   WA, 6153 Sales Support: [EMAIL PROTECTED]
Internet Service Providers
 and Networking Solutions

ppp 2.2?

[Ian Murdock]

Has anyone gotten ppp 2.2 to work?

I finally got it to compile, after realizing that I had to install a
few replacement kernel headers.  Why are these kernel headers not in
the standard distribution of the kernel?

After I got it to build and installed the new packages, PPP says:

   Sorry - PPP driver version 0.0.0 is out of date

What is this?  Does ppp 2.2 not work with linux 1.2.13?

Bug#1543: syslogd should start sooner

[Ian Murdock]

Package: syslogd
Version: 1.2-11

klogd and syslogd are started too late in the boot process.  The
result is that some daemons try to log information through syslogd,
but syslogd isn't listening yet.  The problem is due to the fact
that the links in /etc/rc?.d are created by update-rc.d with the
default value of 20.  I suggest using a value of 10.

Re: why all the .notar files on ftp.debian.org???

[Michael Alan Dorman]

On Tue, 3 Oct 1995, Michael E. Deisher wrote:
> Does anyone know why "get dirname.tar" has been disabled on the ftp
> site.

I would guess because a .notar file has (or had) been created in /debian.

Mike.
--
"And I swear that I don't have a gun."

Re: ppp 2.2?

[Michael Alan Dorman]

On Wed, 4 Oct 1995, Ian Murdock wrote:
> Has anyone gotten ppp 2.2 to work?

It has been shown to work on 1.2.XX.  I've not done it.

> I finally got it to compile, after realizing that I had to install a
> few replacement kernel headers.  Why are these kernel headers not in
> the standard distribution of the kernel?

Because I believe 2.2 was in beta for quite some time before it came out, 
and I think Al Longyear only produced it as a stopgap before rewriting 
the whole megillah for 2.3.

Obviously this is conjecture from what I've read on linux-ppp.  Ask Al 
for the definitive answer.

> After I got it to build and installed the new packages, PPP says:
>Sorry - PPP driver version 0.0.0 is out of date
> What is this?  Does ppp 2.2 not work with linux 1.2.13?

By default 2.2 installs in /usr/sbin, rather than /usr/lib (the previous 
default), so you might be running the wrong one.

If you can make what you've done available, I'd be willing to test it.  
I've got a known-good dedicated PPP connection.

Mike.
--
"And I swear that I don't have a gun."

Re: ppp 2.2?

[Ian Murdock]

   Date: Wed, 4 Oct 1995 08:46:30 -0400 (EDT)
   From: Michael Alan Dorman <[EMAIL PROTECTED]>

   > After I got it to build and installed the new packages, PPP says:
   >Sorry - PPP driver version 0.0.0 is out of date
   > What is this?  Does ppp 2.2 not work with linux 1.2.13?

   By default 2.2 installs in /usr/sbin, rather than /usr/lib (the previous 
   default), so you might be running the wrong one.

I installed chat and pppd to /usr/sbin in this and all previous
versions, so this isn't the problem.

   If you can make what you've done available, I'd be willing to test it.  
   I've got a known-good dedicated PPP connection.

I've got a good connection, too.  I've been happily using ppp 2.1.2b
for the last year-and-a-half without a single problem.  I cannot get
this new version to work at all.

Bug#1544: usergroups in adduser

[Ian Murdock]

Package: adduser
Version: 1.94-1

Users added when using usergroups should have home directories with
mode 2775, and all skeletal files should be g+w.  This is how it is
currently created:

$ ls -la /mnt/home/imurdock
total 4
drwxr-xr-x   2 imurdock imurdock 1024 Oct  3 23:14 .
drwxrwsr-x   3 root staff1024 Oct  3 23:14 ..
-rw-r--r--   1 imurdock imurdock  133 Oct  3 23:14 .bash_profile
-rw-r--r--   1 imurdock imurdock  114 Oct  3 23:14 .bashrc

Re: ppp 2.2?

[Ian Murdock]

Argh.  I just noticed that I'm going to have to rebuild the kernel to
support ppp 2.2.  Should I completely build another image package, or
should I just add the new ppp module to the ppp 2.2 package?

Re: ppp 2.2?

[Ian Murdock]

   Date: Wed, 4 Oct 95 08:39 EST
   From: Ian Murdock <[EMAIL PROTECTED]>

   Argh.  I just noticed that I'm going to have to rebuild the kernel to
   support ppp 2.2.  Should I completely build another image package, or
   should I just add the new ppp module to the ppp 2.2 package?

No, this is a bad idea; then we'd be including kernel-dependent
binaries in a non-kernel package.  I guess I'll have to rebuild the
image package to support this.

Bruce, please delay making the final basedisks until this evening,
after I've had a chance to upload the new image package.  I'll be away
from the office all day today, so I won't be able to start until later
this afternoon.

Ted (maintainer of adduser) and Martin (maintainer of syslogd), could
you fix the bugs I reported earlier sometime today?  (If not, it isn't
a big deal--I just want you to know that we're really close to making
the final version of the 0.93R6 basedisks, if you want fixed versions
included.)

Bug#1545: `write' can't write to telnet logins

[Ian Jackson]

Package: bsdutils? netstd?
Version: bsdutils 1.3-1, netstd 1.17-1

Are `mesg y' terminals on Debian supposed to be g+w, or go+w ?

telnetd (from netbase) and mesg (from bsdutils) seem to thing g+w
ought to be sufficient; however, write (also from bsdutils) seems to
require go+w (though `richard', who was writing to me in another
window at the time of the transcript below, didn't report that it
complained about his terminal being `mesg n').

Making write setgid tty may solve the problem, but such a decision
should only be taken after examining the code to make sure it's not a
security problem.

Ian.

[ Running in an xterm ... ]
chiark:~> finger
LoginName Tty  Idle  Login Time   Office Office Phone
[...]
iwj10Ian Jackson - unpriv  p4Oct  4 12:47 (ealingbroadway.c)
iwj10Ian Jackson - unpriv  p3  1:03  Oct  4 12:49 (ealingbroadway.c)
iwj10Ian Jackson - unpriv  p5Oct  4 12:50 (ealingbroadway.c)
iwj10Ian Jackson - unpriv  p6  1:05  Oct  4 12:53 (ealingbroadway.c)
richard  Richard Kettlewell   *p0Oct  4 10:05 (muskogee.elmail.)
richard  Richard Kettlewellp7Oct  4 12:59 (muskogee.elmail.)
chiark:~> write richard
write: /dev/ttyp7: Permission denied
chiark:~> ll /dev/ttyp7
crw--w   1 richard  tty4, 199 Oct  4 14:55 /dev/ttyp7
chiark:~> ls -al /usr/bin/write
-rwxr-xr-x   1 root root12292 Jun 22 20:25 /usr/bin/write*
chiark:~> ytalk richard
chiark:~> ytalk -x richard
chiark:~> grep mesg /etc/profile
mesg y
chiark:~> tty
/dev/ttyp5
chiark:~> id
uid=1001(iwj10) gid=1001(iwj10) groups=1001(iwj10)
chiark:~> ll /dev/ttyp5
crw--w--w-   1 iwj10iwj10  4, 197 Oct  4 15:01 /dev/ttyp5
chiark:~>

Trying 131.111.131.114...
Connected to chiark.chu.cam.ac.uk.
Escape character is '^]'.
Debian GNU/Linux 0.93
Copyright (C) 1994, 1995 Debian Association, Inc. and others

chiark login: iwj10
Password:
Last login: Wed Oct  4 12:31:00 on ttyc2
Copyright (C) 1994, 1995 Debian Association, Inc. and others

Linux chiark 1.2.13 #2 Sat Sep 30 11:40:37 BST 1995 i486

Unauthorised access prohibited; if you do not know that you are authorised
then you are not.  See /info/rules.text for the rules for the use of
chiark, and /info/chiark.text for information about the system.

Recent items in /info/new - see the file for full details:
1)  Problem with trn hanging believed fixed.  (3.10.1995)
2)  Default terminal message status is now `y'.  (3.10.1995)
3)  trn `l' (list groups) command should now work.  (3.10.1995)

--
  3:01pm  up 4 days,  2:56,  8 users,  load average: 0.48, 0.26, 0.09
chiark:~> tty
/dev/ttyp1
chiark:~> ll /dev/ttyp1
crw--w   1 iwj10tty4, 193 Oct  4 15:01 /dev/ttyp1
chiark:~> exit
exit
Connection closed by foreign host.

Re: why all the .notar files on ftp.debian.org???

[Matthew Bailey]

On Tue, 3 Oct 1995, Michael E. Deisher wrote:

> Does anyone know why "get dirname.tar" has been disabled on the ftp
> site.  I noticed that are .notar files in most directories.  Does this
> mean that "get dirname.tar" is disabled from those directories?  I
> asked Matt Bailey about this but he didn't know why this was
> happening.  Is anyone else having this trouble?  Since I'm
> using pmirror, tar is the only way I can mirror the ms-dos tree.
> 
> Should I report this as a bug?
> 
> --Mike
> 
They have been deleted.

Bug#1546: boot disk won't

[Michael E. Deisher]

Package: 1440_boot_floppy.gz
Version: 0.93R6 (Sep 27)

On Wed, 4 Oct 95 09:14 EST, Ian Murdock <[EMAIL PROTECTED]> said:

> Bruce, please delay making the final basedisks until this evening,
> after I've had a chance to upload the new image package.  I'll be
> away from the office all day today, so I won't be able to start
> until later this afternoon.

In the mean time, it might be wise to make a separate boot disk for
the people with Adaptec SCSI controllers.  The conflict with the
Buslogic driver is still preventing the bootdisk from working.  This
problem will affect (at least) all new debian users with Adaptec 1542B
controllers.

--Mike

Re: dpkg Selective Install

[David H. Silber]

> From: [EMAIL PROTECTED] (David Engel)
> Subject: Re: dpkg Selective Install
> 
> > A better solution is, I think, firstly to use a mechanism I propose to
> > add to dpkg to have it selectively not install certain files (those
> > matching a list of wildcards in a configuration file somewhere).
> > Secondly, if you install a link in /usr/local/sbin called install-info
> > pointing to /bin/true suddenly all the problems with install-info
> > vanish :-).
> > 
> > Do people think this is so gross a hack that we shouldn't recommend it
> > to people who don't want to install the info files ?
> 
> Yes.  I'd rather only give users a well defined, limited set of
> classes of files to not install (eg. man pages, info files, examples,
> etc.).  The install/remove scripts should then be modified to handle
> these cases.

Hear, hear!!  This matches my thinking on the subject.  For any given
package, we should install the copyright information (to protect ourselves)
and then most everything else should be optional.  (Someone /might/ want
_just_ the docs...)  There should be a system-wide configuration file
(/etc/dpkg ?) and an option within dselect to make these choices on a
per-package basis.  (The hacks that have been suggested will only cause
confusion.)

(More on this later, when I have more time.)

-- 
  David H. Silber [EMAIL PROTECTED] Project: Debian GNU/Linux (dbackup)
   Wanted:  Spare time.

 Programmer for hire.

Bug#1548: Minicom ignores old config files

[Dirk Eddelbuettel]

Package: minicom
Version: 1.71
Revision: 1

After upgrading minicom from 1.60 to 1.71, the two config files
/etc/minicom.users and /etc/minirc.dfl are now expected in /var/lib/minicom.

Because 1.60 has them as conffiles in /etc whereas 1.71 has them in
/var/lib/minicom. Either postinst shoudl move the old ones or 1.71 should
retain /etc as their position. Does the FSSTND prefer one location over
the other.


Dirk Eddelbuettel
<[EMAIL PROTECTED]>

Bug#1547: hostname -fqdn fails on the latest install disks

[Bruce Perens]

Can you send us the hosts file? I'd like to see what the root disk put
there when you configured your system.

My system didn't do that, by the way.

Thanks

Bruce
--
-- Attention Radio Amateurs: For information on "Linux for Hams",
-- read the WWW page http://www.hams.com/LinuxForHams,
-- or e-mail the word "help" to [EMAIL PROTECTED]

Re: Bug#1391

[Ian Jackson]

Nils Rennebarth writes ("Bug#1391"):
> texbin *does* depend on texlib. It is listed in the dependencies.
> The dependencies however appear to be satisfied by an older revision
> of texlib, that will not have all required scripts. Is this a bug
> in dpkg? The poster didn't state the dpkg version.
> 
> Anyway it is not a texlib bug, so I close this one.

I looked in the latest Packages-Master file, and texbin lists a
dependency on texlib, but doesn't specify a version number.

Have you considered saying
 Depends: texlib (>first-acceptable-version)
or whatever ?

Ian.

Bug#1544: usergroups in adduser

[Ian Jackson]

Ian Murdock writes ("Bug#1544: usergroups in adduser"):
> Package: adduser
> Version: 1.94-1
>
> Users added when using usergroups should have home directories with
> mode 2775, and all skeletal files should be g+w.  This is how it is
> currently created:
>
> $ ls -la /mnt/home/imurdock
> total 4
> drwxr-xr-x   2 imurdock imurdock 1024 Oct  3 23:14 .
> drwxrwsr-x   3 root staff1024 Oct  3 23:14 ..
> -rw-r--r--   1 imurdock imurdock  133 Oct  3 23:14 .bash_profile
> -rw-r--r--   1 imurdock imurdock  114 Oct  3 23:14 .bashrc

This is because it uses the umask (presumably your root umask is 022 -
mine is 002).

Here is yet another version of my patch to adduser.

This one incorporates all of my previous changes, and fixes a few
other problems too:
 * honour --home when creating non-system users
 * create home directory with setgid bit when using usergroups.
 * copy permissions of dotfiles from /etc/skel, but modified so that
   the group permissions are the same as the user permissions
   (usergroups) or as the other permissions (not user- groups).
 * run /usr/local/sbin/adduser.local if it exists.
 * don't break the dotfiles permissions while doing the umask
   modification.

Ian.

--- /usr/sbin/adduser   Mon Jul 10 02:10:53 1995
+++ /usr/local/sbin/adduser Wed Oct  4 21:50:45 1995
@@ -602,7 +602,11 @@
 ## add the new user to the passwd file
 ##
 print "Updating password file... " if ($verbose);
-$home_dir = $config{"home"} . "/" . $new_name;
+if ($special_home) {
+   $home_dir = $special_home;
+} else {
+   $home_dir = $config{"home"} . "/" . $new_name;
+}
 &add_user_to_file($new_name,
  $new_uid,
  $new_gid,
@@ -651,6 +655,7 @@
}
mkdir ($home_dir, $dir_mode);
chown ($new_uid, $new_gid, $home_dir);
+chmod ($dir_mode, $home_dir);
print "done.\n" if ($verbose);

##
@@ -666,19 +671,25 @@
## change umask lines in appropriate skel files
## if we're using usergroups.
##
+local (@statreturn);
if ($config{"usergroups"} eq "yes") {
foreach $file (".login", ".profile", ".bash_profile") {
$this_file = $home_dir . "/" . $file;
if (-f $this_file) {
open (FILE, "$this_file") || die "open: $!";
-   open (NEWFILE, ">$file.new") || die "open: $!";
+   open (NEWFILE, ">$this_file.new") || die "open: $!";
while ($line = ) {
$line =~ s/umask 0([267])\1/umask 00$1/;
-   print NEWFILE $line;
+   print(NEWFILE $line) || die "write: $!";
}
+
+(@statreturn= stat(FILE)) || die "fstat: $!";
+$filemode= $statreturn[2];
+chmod($statreturn[2],"$this_file.new") || die "chmod: $!";
+
close FILE;
-   close NEWFILE;
-   rename ("$file.new", "$file") || die "rename: $!";
+   close(NEWFILE) || die "close: $!";
+   rename ("$this_file.new", "$this_file") || die "rename: $!";
}
}
}
@@ -719,6 +730,11 @@
 }
 print "done.\n";
 &clean_up();
+if (-f "/usr/local/sbin/adduser.local") {
+exec("/usr/local/sbin/adduser.local",
+ $new_name, $new_uid, $new_gid, $home_dir);
+die "exec adduser.local: $!";
+}
 exit 0;
 }

@@ -867,11 +883,21 @@
 open (NEWFILE, ">$dir/$file") || die "open: $!";

 while () {
-   print NEWFILE;
+   print(NEWFILE) || die "print: $!";
 }

+local (@statreturn,$filemode);
+(@statreturn= stat(FILE)) || die "fstat: $!";
+$filemode= $statreturn[2];
+if ($config{"usergroups"} eq "yes") {
+$filemode= ($filemode & 0707) | (($filemode & 0700)>>3);
+} else {
+$filemode= ($filemode & 0707) | (($filemode & 0007)<<3);
+}
+chmod($filemode,"$dir/$file") || die "chmod: $!";
+
 close FILE;
-close NEWFILE;
+close(NEWFILE) || die "close: $!";

 return 1;
 }
@@ -1246,7 +1272,3 @@
 print STDERR "  --debug Display plenty of debugging 
information.\n";
 print STDERR "Global configuration is in the file '/etc/adduser.conf'\n";
 }
-
-
-
-

Bug#1549: bash should not have world-readable history

[Ian Jackson]

Package: bash
Version: 1.14.4-2

bash has a very annoying habit of creating a world-readable
.bash_history file, if you let it.

I have solved this problem by putting creating a mode 600 empty file
/etc/skel/.bash_history, so that the file already has the right
permissions when bash starts to use it.

There are other obvious solutions to the problem - I don't know which
is best, but something should be done.

Ian.