Hi there;

As per default install, the pcmcia services are started after network
mounts are done, and the NIS services are enabled.

This means that shares aren't enabled for users, and users aren't
able to log in from a yp server.

Whilst it's easy enough to /etc/init.d/nis restart and mount whatever,
I feel that this is a flaw in the functionality of the package.

A reordering of some of the init scripts (perhaps some mucking about in
/etc/rcS.d/) might fix it easily.

Cheers

Richard

Nothing is broken if the system is properly configured, and nothing
needs to be adjusted.  I no longer have time to explain this to people
who do not have enough initiative to read the FAQ.

- Brian

Hello Brian;

Thanks for being so helpful and pointing out my own personal lack of
initiative.  The fact remains that, of the six people I know with Linux on
laptops:

a) Two are not running Debian, and they work fine
b) Four running Debian have hacked their systems to get it to work

Either we've got some unrealistic expectations of the Debian package system,
or the items outlines in your FAQ are generally not widely accepted.  The
issue that it exists in the FAQ should be a good indication of the demand
for it.

To be blunt, "it should just work."  This is why people use packages.

Better alternatives are to mount nfs/whatever with the automounter (debian
package autofs), which works very well - but PCMCIA support is still raised
too late to enable correct functioning of NIS.  Moving the NIS startup
script works okay too.

I guess it's your perogative if you want to make assumptions about peoples
configurations, or dictate that they run their machines in the way you think
best.  I can see why you've done it, but I (and because it's in your FAQ,
probably a few others) don't find it helpful.  Yes, rebooting the system at
each network change is onerous; the use of an automounter, or having the
PCMCIA scripts parse the /etc/fstab, might be two workable solutions and
still provide bootup functionality for network shares and NIS support.

Richard

Hi again;

I thought an analogy of another popular operating system might be helpful.

If I'm running Windows 2000 Professional and using a PCMCIA network card, is
it reasonable to expect that I should have full network and DOMAIN / AD
access by the time I get to log on, or should I be required to monkey with
my configuration to get it to work to suit my "unique requirements?"

If I'm using Win2K Pro, do I need to reboot my machine to change my Ethernet
settings?

I know the analogy is inexact, but what I'm trying to drive at is that
people just want to use their computers.  If PCMCIA services are offered
right from the installation point, isn't it reasonable to expect your system
to work without spannerwork, right out of the box?

Cheers

Richard

Richard,

Please let me clear up one misconception.  Moving the PCMCIA init
script before the NIS script (as you have suggested) will NOT allow
one to hotswap the network card.  Indeed, by setting up your system
like this you are REQUIRING the administrator to reboot the system if
you want to change networks.

- Brian

Hi Brian;

Thanks for the more lengthy reply - this helps a bit more.  I've only got
a couple of comments...

I agree, it's a very relative term :)

However, I postulate to you that their requirements for having eth at boot
outweigh their requirements to be able to remove the card and re-install
it later, and this was (at a guess) the design consideration.

It doesn't make it correct, but it certainly allows them to gloat a lot :)

This is something I've discovered; the placement of the nis scripts is
important as it can cause dissapointment if too early.  The problem (for
me at least) is the delay between having card services, and having an
Ethernet device after that.

It's possible that in a hella fast system, with little to run in startup,
you'd get card services, but no ethernet, before hitting NIS.  Lucky for
me, my laptop was OEM on Noah's Ark, and is not faced with this speed
"disadvantage."

I was trying to provide some alternatives to what I (and others) have
found to be inadequate behaviour.  I'd agree that my solution does not
fully hold water for all values of the bucket :)  It does, however,
provide my sample group with adequate functionality.

Perhaps all that's required is some blurb from debconf or in the
installation system providing an indication of where to set up the
functionality needed (until such time as the NIS order, detailed
below, is sorted)?  The real problem is that setting up card serves
based systems is different from other standard systems (placing the mounts
and NIS in an alternative location than /etc/fstab, etc), and this is the
confusing part.

Reading between the lines, pcmcia-cs is running in the new,
"correct" mode, whereas NIS is running in "compatible" mode.  Not wanting
to pick a fight with the nis or nfs maintainers, but I think that
/etc/network is a sensible location and makes device configuration much
cleaner than the old school.

I now agree (not that it helps either of us) that moving the PCMCIA
services is not the panacea of fixing the system, and I also agree that my
alternatives (which do indeed work fine for me) won't fit all players.  I
know, however, that one of my sample group wasn't even aware there was a
FAQ in /usr/share/doc/pcmcia-cs - largely because of his unfamiliarity
with Debian documentation practice.  If he'd had a bit of blurb specifying
that the normal rules didn't apply, he'd probably have been better off.

Thanks for this, it's most useful.

Now this is quite cool, and very useful - fixes my problem nicely :)

Is it worth having an alternative nis package for this.  I don't know if
the package system supports this complexity, but if there was, for
instance:

nis, conflicts with pcmcia-cs, and
nis-pcmcia, suggested by pcmcia-cs

...which were essentially the same package binaries, but with different
script mechanisms, then that'd certainly be all good.

It does, unfortunately, mean a lot more pissing about for the package
maintainers (the nis maintainer), but fit with your suggestion below:

[...]

:)  Tell you what, I'll try and track down the NIS bug, and merge this
with that.  It'd make an interesting epistle at any rate, and would
probably help provide support for, "The New Order."
about initiative :)

Cheers

Richard
--
Richard Parry                          richard.parry@optimation.co.nz
Glue Guy: CCNA, CSE(SMB), MCP, makes pretty good coffee    Optimation
Phone: +64 4 470 5814 x 848    Pager: richardp.pager@optimation.co.nz

unmerge 111359 106705
severity 111359 wishlist
severity 106705 wishlist
merge 111359 106705
thanks

According to Debian Bug Tracking System:

This is not important. The mechanism used isn't even in policy, it
needs to be discussed first because there are quite a few subtle
things that are NOT right imho in the current /etc/networking/* stuff.

I did try to implement it but there were just to many problems.

I don't have the time right now to discuss it (I'm looking at
working a few days AND nights the next days)

Mike.

Processing commands for control@bugs.debian.org:
Unknown command or malformed arguments to command.
Bug#111359: pcmcia: NIS/NFS services started before PCMIA: no eth0 available
Bug#106705: NIS packaging incompatible with PCMCIA ethernet
Severity set to `wishlist'.
Bug#106705: NIS packaging incompatible with PCMCIA ethernet
Bug#111359: pcmcia: NIS/NFS services started before PCMIA: no eth0 available
Severity set to `wishlist'.
Bug#106705: NIS packaging incompatible with PCMCIA ethernet
Bug#111359: pcmcia: NIS/NFS services started before PCMIA: no eth0 available
Merged 106705 111359.
Stopping processing here.

Please contact me if you need assistance.

Darren Benham
(administrator, Debian Bugs database)

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
 Miquel van Smoorenburg <miquels@cistron.nl>

If you wish to continue to submit further information on your problem,
please send it to 111359@bugs.debian.org, as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
 Miquel van Smoorenburg <miquels@cistron.nl>

If you wish to continue to submit further information on your problem,
please send it to 106705@bugs.debian.org, as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)

Hey Mike;

Thanks for the quick reply.

Yeah, sorry about that - rather than adjust someone else's bug I matched my
priority to his to merge it.

Fair enough :)  From my perspective, as noted in my bug, "it should just
work," but I realise that we've got some shifts in the way things work vs.
the way they should work.

I've got a hackaround for my problem; the only thing in the short term might
be to put some murmer in the FAQ for the package.

Sweet as man, I appreciate that the package guys do a lot of unpaid work,
and things that are real priorities come first.  You obviously know it's a
problem and are working on it, that's all I need to know for now.

I'm sure Brian's in the same boat.

Cheers

Richard

In article <Pine.LNX.4.21.0109091712290.16095-100000@mini.optimation.co.nz>,
Richard Parry  <richardp@optimation.co.nz> wrote:

Sure, the idea is good. BUT.

- What about systems with /usr shared over NFS. When the network
  comes up, there is no /usr/sbin/ypbind yet so it's kind of
  hard to start.
- /etc/init.d/nis should have a good way to find out if it should
  start ypbind or not - and we need to retain /etc/init.d/nis
  because people EXPECT all scripts to start/stop daemons to be there
- I don't think scripts should be put in /etc/network/<bla>-up etc.
  I think that it should contain links to /etc/init.d scripts,
  just like /etc/rc?.d, and update-rc.d or a similar tool should
  be used to manage them
- The new system doesn't cleanly blend in with runlevels

Until all the above has been resolved, and has been made part
of policy, this NIS maintainer is not going to implement the
pcmcia stuff.

Mike.

We believe that the bug you reported is fixed in the latest version of
pcmcia-cs, which has been installed in the Debian FTP archive:

pcmcia-cs_3.1.29-1.dsc
  to pool/main/p/pcmcia-cs/pcmcia-cs_3.1.29-1.dsc
pcmcia-modules-2.2.19-ide_3.1.29-1k12_i386.deb
  to pool/main/p/pcmcia-cs/pcmcia-modules-2.2.19-ide_3.1.29-1k12_i386.deb
pcmcia-source_3.1.29-1_all.deb
  to pool/main/p/pcmcia-cs/pcmcia-source_3.1.29-1_all.deb
pcmcia-modules-2.4.10-k6_3.1.29-1k1_i386.deb
  to pool/main/p/pcmcia-cs/pcmcia-modules-2.4.10-k6_3.1.29-1k1_i386.deb
pcmcia-cs_3.1.29-1.diff.gz
  to pool/main/p/pcmcia-cs/pcmcia-cs_3.1.29-1.diff.gz
pcmcia-modules-2.2.19-idepci_3.1.29-1k12_i386.deb
  to pool/main/p/pcmcia-cs/pcmcia-modules-2.2.19-idepci_3.1.29-1k12_i386.deb
pcmcia-modules-2.2.19-reiserfs_3.1.29-1k4_i386.deb
  to pool/main/p/pcmcia-cs/pcmcia-modules-2.2.19-reiserfs_3.1.29-1k4_i386.deb
pcmcia-modules-2.2.19-compact_3.1.29-1k12_i386.deb
  to pool/main/p/pcmcia-cs/pcmcia-modules-2.2.19-compact_3.1.29-1k12_i386.deb
pcmcia-modules-2.2.19_3.1.29-1k12_i386.deb
  to pool/main/p/pcmcia-cs/pcmcia-modules-2.2.19_3.1.29-1k12_i386.deb
pcmcia-cs_3.1.29.orig.tar.gz
  to pool/main/p/pcmcia-cs/pcmcia-cs_3.1.29.orig.tar.gz
pcmcia-modules-2.4.12-k6_3.1.29-1k1_i386.deb
  to pool/main/p/pcmcia-cs/pcmcia-modules-2.4.12-k6_3.1.29-1k1_i386.deb
pcmcia-cs_3.1.29-1_i386.deb
  to pool/main/p/pcmcia-cs/pcmcia-cs_3.1.29-1_i386.deb
pcmcia-modules-2.2.19-ext3_3.1.29-1k6_i386.deb
  to pool/main/p/pcmcia-cs/pcmcia-modules-2.2.19-ext3_3.1.29-1k6_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 111359@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Brian Mays <brian@debian.org> (supplier of updated pcmcia-cs package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


Format: 1.7
Date: Wed, 24 Oct 2001 17:41:11 -0400
Source: pcmcia-cs
Binary: pcmcia-source pcmcia-modules-2.2.19-ext3 pcmcia-modules-2.2.19-compact pcmcia-modules-2.2.19-reiserfs pcmcia-modules-2.2.19-idepci pcmcia-modules-2.2.19 pcmcia-modules-2.4.12-k6 pcmcia-modules-2.4.10-k6 pcmcia-cs pcmcia-modules-2.2.19-ide
Architecture: source i386 all
Version: 3.1.29-1
Distribution: unstable
Urgency: low
Maintainer: Brian Mays <brian@debian.org>
Changed-By: Brian Mays <brian@debian.org>
Description:
 pcmcia-cs  - PCMCIA Card Services for Linux.
 pcmcia-modules-2.2.19 - PCMCIA Modules for Linux (kernel 2.2.19).
 pcmcia-modules-2.2.19-compact - PCMCIA Modules for Linux (kernel 2.2.19-compact).
 pcmcia-modules-2.2.19-ext3 - PCMCIA Modules for Linux (kernel 2.2.19-ext3).
 pcmcia-modules-2.2.19-ide - PCMCIA Modules for Linux (kernel 2.2.19-ide).
 pcmcia-modules-2.2.19-idepci - PCMCIA Modules for Linux (kernel 2.2.19-idepci).
 pcmcia-modules-2.2.19-reiserfs - PCMCIA Modules for Linux (kernel 2.2.19-reiserfs).
 pcmcia-modules-2.4.10-k6 - PCMCIA Modules for Linux (kernel 2.4.10-k6).
 pcmcia-modules-2.4.12-k6 - PCMCIA Modules for Linux (kernel 2.4.12-k6).
 pcmcia-source - PCMCIA Card Services source.
Closes: 111359 111664 112989 113117 113896 113901 113997 114374 114454 114907 115086 116276 116479
Changes:
 pcmcia-cs (3.1.29-1) unstable; urgency=low
 .
   * New upstream version.  (Closes: Bug#116276)
   * Build and install setpnp and lspnp.  (Closes: Bug#112989,
     Bug#114374)
   * Now employ "--force" configuration option to force building
     pcmcia-modules packages for kernels that have their own PCMCIA
     modules.  (Closes: Bug#113901, Bug#113997)
   * Added warning during installation of pcmcia-cs of problem with
     network services.  (Closes: Bug#111359, Bug#114907)
   * Removed empty /usr/src/modules directory from pcmcia-source package.
     (Closes: Bug#113117)
   * Changed ownership and permissions of the files in the pcmcia-source
     tarball to root.src and g+w.  (Closes: Bug#113896)
   * Added German templates.  (Closes: Bug#114454)
   * Moved examples from config.opts to the doc directory.  (Closes:
     Bug#115086)
   * Switched from insmod to modprobe in init.d script.  (Closes:
     Bug#111664)
   * Changed debian/rules to use KPATH if KSRC is not set.  (Closes:
     Bug#116479)
Files:
 d7b9e613f96b2e747eccbb9cd03a8a0f 646 base extra pcmcia-cs_3.1.29-1.dsc
 26f3ff199e5eda17f75e19fa6b9295e7 1226959 base extra pcmcia-cs_3.1.29.orig.tar.gz
 c6624dfb20e7e0a98e90088789ea86bd 61320 base extra pcmcia-cs_3.1.29-1.diff.gz
 dd64a4109ceab2806a7dffb155d02ed2 975400 admin extra pcmcia-source_3.1.29-1_all.deb
 297479168118843e6f5de2232ae0e947 254548 base extra pcmcia-cs_3.1.29-1_i386.deb
 71ff9d3e5932a4fca640f6cff8bfb5da 395302 admin extra pcmcia-modules-2.2.19_3.1.29-1k12_i386.deb
 1ef0c8a0798829ed484f3b9471e0675e 354908 admin extra pcmcia-modules-2.2.19-compact_3.1.29-1k12_i386.deb
 dc3f17478ec037a272bc168b0f41ee70 395368 admin extra pcmcia-modules-2.2.19-ide_3.1.29-1k12_i386.deb
 3cbf4cb7121c32bde9ea6101b4cb73b4 271500 admin extra pcmcia-modules-2.2.19-idepci_3.1.29-1k12_i386.deb
 2cf5e17981202c2ba2ade55fb56e3eb5 355304 admin extra pcmcia-modules-2.2.19-reiserfs_3.1.29-1k4_i386.deb
 cd6fc4372e1a63e319a58cf3ceba6179 402314 admin extra pcmcia-modules-2.2.19-ext3_3.1.29-1k6_i386.deb
 df12c443ebef50250ee2051e03ab03ba 401174 admin extra pcmcia-modules-2.4.10-k6_3.1.29-1k1_i386.deb
 c182ec286ce3361ad160035d1904a047 401188 admin extra pcmcia-modules-2.4.12-k6_3.1.29-1k1_i386.deb
iD8DBQE72FSFGfbHvThXxNoRAh4qAJ4wzqaao4kIZ8ChMLdhTpOLd2I0/QCfTyI4
3MCs8OuUAo/4rdKKiaMWYDE=
=OBLV
-----END PGP SIGNATURE-----

reopen 111359
thanks

Sorry.  Didn't mean to close this bug, since it has been reassigned to
another package.

- Brian