New 1.3 installation report
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 services for college and bootp/tftp services for the printers; it all worked out of the box. Congratulations everyone! -- Steve McIntyre, CURS Secretary, Cambridge, UK. [EMAIL PROTECTED] Whenever you eat, chew Can't keep my eyes from the circling sky, +-- Tongue-tied twisted, Just an earth-bound misfit, I... |Finger for PGP key Mail for me sent to cam.ac.uk addresses will start bouncing soon. Please use [EMAIL PROTECTED] or [EMAIL PROTECTED] instead. Thanks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report
[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, which is never parsed because gv/ghostview doesn't install because there's no gs. Repeating the installation step doesn't solve this. - the problem with dselect not trying a section because there was an error in a previous section returns with pinepgp from contrib not installing because it depends on pine and pgp, in non-free resp. local. Here too, repeating the process doesn't solve the problem. This behaviour of dselect should be anticipated on when determining the proper (pre)dependecies, or otherwise a mention of it should be added to the documentation - along with a hint of possible solutions. Repeating the installation step (the current panacea) is no solution in these cases. Well, this is one thing that dpkg-mountable seems to get right. Maybe other installation methods could be fixed to do the same? In short, dpkg-mountable does not scan through the archive and unpack every package it finds that is wanted, it first tries to locate the packages and then unpacks them in order. Actually, it has problems, too - dpkg-mountable doesn't (yet?) understand pre-dependencies, except to complain about unresolved ones. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report
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 could be fixed to do the same? In short, dpkg-mountable does not scan through the archive and unpack every package it finds that is wanted, it first tries to locate the packages and then unpacks them in order. Alphabetical order right now, actually. ;) Actually, it has problems, too - dpkg-mountable doesn't (yet?) understand pre-dependencies, except to complain about unresolved ones. No, it still doesn't, but this should be coming in v0.5 in the next couple of weeks, once I've got Manoj's pkg-order working; in fact, it'll do full ordering of the install by dependencies, thereby hopefully making a one-pass from-scratch install possible. I would have done this a while ago, except for exams, but they're thankfully now over! E -- Andy Mortimer, [EMAIL PROTECTED] http://www.poboxes.com/andy.mortimer PGP public key available on key servers -- I found myself alone, alone above a raging sea That stole the only girl I loved and drowned her deep inside of me. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report
[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 thing that dpkg-mountable seems to get right. Maybe other installation methods could be fixed to do the same? In short, dpkg-mountable does not scan through the archive and unpack every package it finds that is wanted, it first tries to locate the packages and then unpacks them in order. Alphabetical order right now, actually. ;) Well, the important thing is (and I _was_ not particularly clear on that) that it doesn't install by section (main, contrib, non-free, ...) but in one pass. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report
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 version and in the package xyz version.). Perhaps this is something that gnats can be used for. I know FreeBSD is using gnats in this way. -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
1.3 installation report
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 minor problem with bind and some dselect annoyance with installation order, which tends to break installation in a way that cycling dselect installation doesn't solve the dependency problems. Mostly things went quite fine though. Base install from May 28 floppies is very smooth and without any problems on my hardware (pci p133 32mb) I made a 2+Gb ext2 partition without memory problems. I did install any modules, because I rolled my own 2.0.29 kernel with some patches to get my ne2000 recognised and I just compiled everything needed in. After rebooting and entering dselect I chose nfs access method. Every time the stable/binary tree is checked by dselect it prints an (apparently harmless) error about a broken pipe. Before, I had tried to select a whole bunch of packages, but this tends to give a lot of dependency problems. So this time I first did the already selected + all important packages + all packages suggested because of dependencies - no problems. Then all standard packages + depended on packages - no problems. Then all optional packages + depends. This included x, which gave some problems: 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 point. Also, sometimes xdm does get configured properly because of similar reasons - a missing Xservers file. This time it worked though, but only because I installed more than one xserver and xbase got installed before the one I actually use. This also saved the day for xsetup, so in fact I did get x running in one dselect run. Had to rerun dselect anyway because of the unconfigured xserver-vga16 etc. On the point of xsetup: I found that things hang really badly if I run xvidtune from xsetup. Maybe that is not so bad actually because it is quite a dangerous program to your monitor - I once found out. Apart from x, there were no obvious problems with the otional packages. 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, which is never parsed because gv/ghostview doesn't install because there's no gs. Repeating the installation step doesn't solve this. - the problem with dselect not trying a section because there was an error in a previous section returns with pinepgp from contrib not installing because it depends on pine and pgp, in non-free resp. local. Here too, repeating the process doesn't solve the problem. This behaviour of dselect should be anticipated on when determining the proper (pre)dependecies, or otherwise a mention of it should be added to the documentation - along with a hint of possible solutions. Repeating the installation step (the current panacea) is no solution in these cases. So this makes more or less 3 problems with installation of more than 300 packages. Quite good actually! Add to that that these problems were not really serious - very good actually! 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 that it is this combination that prevents him/her from logging in. 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. IMHO a _big_ warning in CAPS should be added to the installation messages or, much better, this should be fixed in frozen before a release is made. If this isn't fixed in time, then I think we can consider shadow sort of broken in 1.3. Another problem that I have seen reprorts of is the problems with bind. I let the bind upgrade touch a working setup on a 1.2 machine and it broke it. I set it up on a fresh machine and I can't even do a nslookup localhost. Haven't had thhe time to investigate what went wrong. So far my longish report at a rather late time - hope it is still of some use. Cheers, Joost Here are the install logs: first run adduser install ae install base-files install base-passwd install bashinstall bsdutilsinstall debianutils
Re: 1.3 installation report
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 that it is this combination that prevents him/her from logging in. 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 figure out how we messed up the xdm install. 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 been release? I can think of a number of questions that could go onto it. This could be prominently featured on the web site and the ftp server. Cheers, - Jim pgppoWRhgYUGn.pgp Description: PGP signature
Re: 1.3 installation report
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 here is that the server packages don't need the X packages; only the configuration tools do. Would it be enough if the X server packages suggest xbase? That way normal users would get them, but people who really knew that they wanted to make a machine into an xterminal can just ignore the suggestion. 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 Or even, shadowconfig off; shadowconfig on -- I'm told that shadowconfig does the right thing with xdm *if* X is already installed... _Mark_ [9:30pm US/Eastern, still no 3.3 release...] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report
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 UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report
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 figure out how we messed up the xdm install. Just in case you are under the impression that xdm doesn't support shadow, I thought I'd clear it up a bit. You can get shadow and xdm to work by doing this: shadowconfig off shadowconfig on So what's happening here ? The xdm package contains two binaries (xdm xdm-shadow), the default /etc/init.d/xdm invokes xdm, but shadowconfig edits this to be xdm-shadow when you run shadowconfig on. The reason you see the problem, is that xdm gets installed after shadow, so shadowconfig doesn't get a chance to tweak the startup script. 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. From shadowconfig itself: # xdm-shadow works fine with non-shadowed systems also, so it's # not necessary to reverse this in shadowoff Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report
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 been release? I can think of a number of questions that could go onto it. This could be prominently featured on the web site and the ftp server. 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 version and in the package xyz version.). look at other distributions : they have support databases (www.suse.de, maybe also www.suse.com and other distributions). the bug archive is ok for us developers, but after a bug is closed, it wouldn't help. and a user should not have to read the whole discussion, he only needs the bug description and the solution to solve it. regards, andreas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report
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 about a release-specific FAQ that we can update after 1.3 has been release? I can think of a number of questions that could go onto it. This could be prominently featured on the web site and the ftp server. 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 version and in the package xyz version.). look at other distributions : they have support databases (www.suse.de, maybe also www.suse.com and other distributions). the bug archive is ok for us developers, but after a bug is closed, it wouldn't help. and a user should not have to read the whole discussion, he only needs the bug description and the solution to solve it. Matt Surico and I have been slowly (very) developing a call/problem tracking system/knowledge base system. Maybe we need to make it speed up a little more... Tim -- (work) [EMAIL PROTECTED] / (home) [EMAIL PROTECTED] - http://www.buoy.com/~tps The squeaky wheel gets the grease, but gets changed at the next opportunity if it squeaks habitually. ** Disclaimer: My views/comments/beliefs, as strange as they are, are my own.** -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report
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 gets right, but 3.3 isn't on the ftp site yet... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
xdm-shadow (was Re: 1.3 installation report.)
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 /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. :-) There was indeed a problem with XFree86-3.1.2 (xdm-shadow didn't work with non-shadow passwords), but not with 3.2 and higher. With 3.2 and 3.2A, the only thing that remains to be fixed is the Imakefile that still generates two separate xdm binaries. I reported this to the XFree86 upstream maintainers, and got a reply from David Dawes: We've dealt with this finally, and it will be fixed in 3.3. So, I would appreciate if it could be fixed in the next Debian 1.3 xbase release. Just move that single binary... I've never understood why the debian shadow code was so primitive. Not just Debian, and not just Linux - getspnam() is also used on several other systems, Solaris being one of them. Like many other UN*X things, it is not perfect, maybe it is even primitive, but it works and is standard. Most reasonably current, portable sources, already know about getspnam(). Any reason why the classic getpw* give you a password field if you've got root implementation isn't used? I can think of a few reasons (avoiding coredumps in programs not actually needing passwords) but Another reason is that in the past some setuid root programs (chfn, chsh) used to get the passwd entry using getpwnam(), modify it, and write it back to /etc/passwd. Congratulations, you just unshadowed your system... Sure, they can (and should) be fixed, but I prefer to play it safe. Besides, there is more information in /etc/shadow than just the encrypted passwords, and that information (password aging) would be lost. The people at ATT who added getspnam() to SVR4 a few years back could probably give a better answer to this question than I did. Of course this is a matter of personal opinion, but I for one consider getspnam() to be the classic shadow password implementation. (Some systems actually do the getpw* thing, but I think it is a little unsafe.) they're kind of weak [and could be handled better by simply providing a shadow_need_passwords() call to enable the feature...] Non-standard - there are already so many different shadow password implementations... Regards, Marek -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: xdm-shadow (was Re: 1.3 installation report.)
# 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 changed a *small* amount, but I guess it was sufficient.)
sp = getspnam(greet-name);
if (sp == NULL) {
Debug (getspnam() failed, errno=%d. Are you root?\n, errno);
} else {
So I'll change that text a bit, and have the next release install both
xdm and xdm-shadow but make them the same executable (safest path, I
think, since I can't count on everything else being updated to know
about the change.)
HOWEVER, it doesn't make any sense to do a new release just for this,
since it's just an annoyance, not a bug (the shadow convert scripts
currently do the right thing if you run them with X already
installed.) There is a better reason though -- someone sent me
patches for what they claim are all of the Xt buffer overruns. If
there's a 1.3.1 planned, and someone lets me know the deadline and/or
schedule at least a week (preferably two) in advance, I'll get both of
these in.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report.
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 rearrangement. (If you run xdm-shadow on a non-shadow system, you *lose*...) I've never understood why the debian shadow code was so primitive. Any reason why the classic getpw* give you a password field if you've got root implementation isn't used? I can think of a few reasons (avoiding coredumps in programs not actually needing passwords) but they're kind of weak [and could be handled better by simply providing a shadow_need_passwords() call to enable the feature...] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report.
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 manage this by itself. (I think, the most recent xbase does so) P.S. I have a feeling the NIS problem appears under 2.0.30 kernels and downgrading to 2.0.29 should fix it --- don't know why though. I am running 2.0.27 and also have problems with NIS. I guess, it is a libc problem ( cf. bug 9843) Cheers, Thomas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report.
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 fix the problem. I'm not sure what to put this down to, any suggestions? (I can log in as root via ssh fine). I have got a similiar problem but have not yet got the time to look at it closely. I can log in at the text console but but at the xdm login screen. I don't have NIS installed but shadowed passwords. Cheers, Thomas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report.
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 doing a shadowconfig off and that still didn't fix the problem. I'm not sure what to put this down to, any suggestions? (I can log in as root via ssh fine). Can you use any yp commands ? For instance does this work: ypcat passwd I can use them, but I get the standard stuff (it's a NIS slave server) locally and no user details. /usr/lib/yp/ypinit -s servername gives a whole lot of errors as well. -- Karl Ferguson, Tower Networking Pty LtdTel: +61-8-9456-[EMAIL PROTECTED] t/a STAR Online ServicesFax: +61-8-9455-2776[EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report.
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 fix the problem. I'm not sure what to put this down to, any suggestions? (I can log in as root via ssh fine). I have got a similiar problem but have not yet got the time to look at it closely. I can log in at the text console but but at the xdm login screen. I don't have NIS installed but shadowed passwords. 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. Cheers, Phil. P.S. I have a feeling the NIS problem appears under 2.0.30 kernels and downgrading to 2.0.29 should fix it --- don't know why though. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report.
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 Ferguson Tower Networking Pty Ltd Tel: +61-8-9456- [EMAIL PROTECTED] t/a STAR Online Services Fax: +61-8-9455-2776 [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report.
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 - still no success there I think. But is the last line in the file? Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report.
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 11:14:03 aurora sshd[6413]: log: Connection from 203.22.233.1 port 1023 May 19 11:14:04 aurora sshd[6413]: log: Rhosts authentication refused for karl: bad modes for /home/karl/.rhos ts May 19 11:14:06 aurora sshd[6413]: fatal: Connection closed by remote host. When I try to log in in my normal account. /home is nfs mounted from another server, so what I tried to do was unmount /home and leave the default 'karl' account there and I got this error: May 19 11:17:00 aurora sshd[6433]: log: Connection from 203.22.233.1 port 1023 May 19 11:17:03 aurora sshd[6433]: fatal: Connection closed by remote host. I ran sshd in debug mode and got this: log: Connection from 203.22.233.3 port 1022 debug: Client protocol version 1.5; client software version 1.2.20 debug: Sent 768 bit public key and 1024 bit host key. debug: Encryption type: idea debug: Received session key; encryption turned on. debug: Attempting authentication for karl. debug: Trying rhosts with RSA host authentication for root debug: RhostsRSA authentication failed for 'karl', remote 'root', host 'orion.tower.net.au'. debug: Password authentication for karl failed. fatal: Connection closed by remote host. So, I cannot figure this out - it's baffling me, I *know* I can login alright and I'm fingerable. -- Karl Ferguson, Tower Networking Pty LtdTel: +61-8-9456-[EMAIL PROTECTED] t/a STAR Online ServicesFax: +61-8-9455-2776[EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report.
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 the problem. I'm not sure what to put this down to, any suggestions? (I can log in as root via ssh fine). Can you use any yp commands ? For instance does this work: ypcat passwd I noticed after upgrading a client's system to 2.0.30 that this command died halfway through the first time it was run after stopping and restarting nis. After running the ypcat once it would then claim that the server was down until nis is restarted. This made it impossible to log into the system, so I had to boot of a rescue disk and remove the + entry from /etc/passwd. Once that was done I logged in and found the ypcat problem --- going back to 2.0.29 fixed it. I've not had chance to track it down any more than that. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
1.3 installation report.
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 not get a free page... error come up - however the format finishes and the partition seems fine and usable. (This could be hardware related - I've had FATAL GCC errors before when compling after a 0.93r6 install). 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 the problem. I'm not sure what to put this down to, any suggestions? (I can log in as root via ssh fine). -- Karl Ferguson Tower Networking Pty Ltd Tel: +61-8-9456- [EMAIL PROTECTED] t/a STAR Online Services Fax: +61-8-9455-2776 [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report.
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 shadowconfig off and that still didn't fix the problem. I'm not sure what to put this down to, any suggestions? (I can log in as root via ssh fine). 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. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report.
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 need to blame the hardware. As long as it continues it is sufficiently fine, but sometimes this hangs the system ... Sven -- Sven Rudolph [EMAIL PROTECTED] ; WWW : http://www.sax.de/~sr1/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
