I was involved in a complete new installation of a 1.3 machine yesterday,
showing the college's computer officer how good Linux and Debian can be.
I'm very glad to report there were _no_ problems whatsoever on the way
through the installation.
We now have a machine up and running with DNS
[EMAIL PROTECTED] (Bruce Perens) wrote on 03.06.97 in [EMAIL PROTECTED]:
I wound up in a catch-22 with some of the extra packages:
- ghostview and gv both depend on gs. However, package gs-alladin which
provides gs never gets installed because dselect tries to: gs-alladin is
in non-free,
On Jun 8, Kai Henningsen wrote
[EMAIL PROTECTED] (Bruce Perens) wrote on 03.06.97 in [EMAIL PROTECTED]:
[dselect fails to install main packages depending on ones in non-free
or contrib]
Well, this is one thing that dpkg-mountable seems to get right. Maybe
other installation methods
[EMAIL PROTECTED] (Andy Mortimer) wrote on 08.06.97 in [EMAIL PROTECTED]:
On Jun 8, Kai Henningsen wrote
[EMAIL PROTECTED] (Bruce Perens) wrote on 03.06.97 in
[EMAIL PROTECTED]: [dselect fails to install main
packages depending on ones in non-free or contrib]
Well, this is one
Andreas Jellinghaus [EMAIL PROTECTED] writes:
i'm missing the same thing: debian should have a database with error
reports and how to fix them. every big bug should be documented (we had
this bud description, and you can solve it this way : solution. it's
also fixed in the new release debian
From: J.P.D. Kooij [EMAIL PROTECTED]
On Mon, 2 Jun 1997, Bruce Perens wrote:
We are in the process of releasing Debian 1.3 .
Tonight I made another attempt to install base + 300 packages. I've added
the list to the end of this message.
I experienced a _major_ problem with shadow and xdm, a
I did find a serious problem after rebooting (ok, I could probably have
done this more subtle) the machine to start xdm. From reading several
debian related lists I already knew that xdm will break with shadow
passwords. However, I doubt if everyone who just installed debian 1.3 will
realize
The xserver packages want to setup x, this gets stuck because xinitrc is
missing because it is part of xbase - which is not installed at that
Hmm. Yeah, I think I've probably always won because I use dpkg from
the shell, and with globbing get everything in alphabetical order :-)
The problem
and don't forget, there's *still* no written-down policy on shadow:
% grep -i shadow /usr/doc/dpkg/programmer.html/*
Exit 1
I mean, I will get this straightened out with 3.3, but the
picky-detail side of me is still miffed that debian's shadow policy is
still basically hearsay. :-}
--
TO
The fix is very simple: ctrl-alt-F1; log in as root; shadowconfig off;
return to x and log in normally. But you do have to know this.. and there
is no warning when installing shadow or xdm.
Arrrghhh!
I spent two hours yesterday (past midnite) on the phone with a client
trying to
On Jun 3, Jim Pick wrote
This flaw needs to be publicized a bit more. I'm sure I would have
figured out the problem via the bug system eventually - but I shouldn't
have to do that.
Is there a document where Errata can go? How about a release-specific
FAQ that we can update after 1.3 has
In your email to me, Andreas Jellinghaus, you wrote:
On Jun 3, Jim Pick wrote
This flaw needs to be publicized a bit more. I'm sure I would have
figured out the problem via the bug system eventually - but I shouldn't
have to do that.
Is there a document where Errata can go? How
correct analysis except:
As it happens xdm-shadow works fine on non-shadow systems, so I believe the
maintainer has (or is about to) uploaded a copy where xdm and xdm-shadow are
the same (shadow enabled) binary.
Not uploaded yet -- it's just one of the things I'll be sure the 3.3
upload
Hi,
Mark Eichin:
2) the xdm shadow support doesn't fall back in any sane way,
and it's more than just dropping a check -- a bunch of code needs
rearrangement. (If you run xdm-shadow on a non-shadow system, you *lose*...)
Well, I just did that with xbase-3.2-6:
# mv
# mv /usr/X11R6/bin/xdm-shadow /usr/X11R6/bin/xdm
I can switch back and forth between shadow and non-shadow passwords,
and can login via xdm just fine. Nothing bad happened, my machine
hasn't exploded yet, etc. :-)
Ah, I see, it just logs an error, but doesn't actually fail. (The
code only
nope, recent versions of xbase aren't any better about shadow support,
because
1) there's nothing in the programmers guide even mentioning it
2) the xdm shadow support doesn't fall back in any sane way,
and it's more than just dropping a check -- a bunch of code needs
Hi,
Presumably, you installed xdm after installing shadow. shadowconfig edits
/etc/init.d/xdm to switch between using xdm and xdm-shadow, so all you need
to
do is:
shadowconfig off
shadowconfig on
and all should be well.
Yes, thank you!
But I think, the xbase package should
Hi,
2. I installed shadowing as it suggested - started installing packages
merrily. I also installed and configured NIS - however, I cannot log in
any in my personal account - though I can finger anyone without trouble. I
deinstalled shadow by doing a shadowconfig off and that still didn't
At 09:26 AM 19/05/97 +0100, Philip Hands wrote:
2. I installed shadowing as it suggested - started installing packages
merrily. I also installed and configured NIS - however, I cannot log in
any in my personal account - though I can finger anyone without trouble. I
deinstalled shadow by
Hi,
2. I installed shadowing as it suggested - started installing packages
merrily. I also installed and configured NIS - however, I cannot log in
any in my personal account - though I can finger anyone without trouble. I
deinstalled shadow by doing a shadowconfig off and that still
At 02:09 PM 18/05/97 -0500, Guy Maor wrote:
This might be because the + entry is not at the end? (5634, 8734) I
plan to release a new passwd package today which fixes this.
I'm pretty sure I tried putting +:: in both /etc/passwd and /etc/shadow
- still no success there I think.
--
Karl
Karl Ferguson [EMAIL PROTECTED] writes:
At 02:09 PM 18/05/97 -0500, Guy Maor wrote:
This might be because the + entry is not at the end? (5634, 8734) I
plan to release a new passwd package today which fixes this.
I'm pretty sure I tried putting +:: in both /etc/passwd and /etc/shadow
-
At 10:07 PM 18/05/97 -0500, Guy Maor wrote:
But is the last line in the file?
Certainly is. I just saw someone post on a 'login' bug that they couldn't
log in as anyone except for root because of the passwd file being mode 600
- this isn't the case for me.
the daemon.log reports this:
May 19
2. I installed shadowing as it suggested - started installing packages
merrily. I also installed and configured NIS - however, I cannot log in
any in my personal account - though I can finger anyone without trouble. I
deinstalled shadow by doing a shadowconfig off and that still didn't fix
Hi Guys.
I just tested the new 1.3 disks and the system seems great. Of course,
there are some little qwerks which I'm not sure if they're related to my
hardware or not. They are:
1. After completing the badblocks scan when 'initalizing' a hard disk, it
starts writing the tables - I get Could
Karl Ferguson [EMAIL PROTECTED] writes:
2. I installed shadowing as it suggested - started installing packages
merrily. I also installed and configured NIS - however, I cannot log in
any in my personal account - though I can finger anyone without trouble. I
deinstalled shadow by doing a
Karl Ferguson [EMAIL PROTECTED] writes:
1. After completing the badblocks scan when 'initalizing' a hard disk, it
starts writing the tables - I get Could not get a free page... error come
up - however the format finishes and the partition seems fine and usable.
This is a kernel problem, no
27 matches
Mail list logo
