Re: bug reporting?
On Fri, Jan 14, 2005 at 11:56:31AM +0100, Giacomo Mulas wrote: > On Fri, 14 Jan 2005, Kaare Hviid wrote: > > >1) Using a pure64 amd64 box (or alpha for that matter) as an NIS slave > >with an i386 box as master _will_ work, albeit rpc.ypxfrd will complain. > > Yes, I actually came to this same conclusion, after some more work. What > puzzles me is that _every_ time I start the nis server with the stock > /etc/init.d/nis script, be it manually or at boot time, the maps are > transferred anew! Perhaps, due to the fact that map files are not > identical to the ones on the master server, the nis slave server thinks > its maps are outdated and tries to refresh them every time it is started, > every time falling back to the enumerate mechanism, and thus every time > creating new files which are not identical to the ones on the master > server... If I'm not mistaken, this functionality was introduced in the sarge NIS package. And if you think about it, it makes sense. The NIS slave has no way of telling if its maps are outdated or not (all updates are normally initiated from the master). Thus, if the slave server has been down, you might be sitting with an old passwd database without knowing about it - and you certainly want to avoid old passwds flying around on the net if you want to remain sane. If you've previously only used woody NIS servers, watch out! There are syntactic changes in the /etc/ypserv.conf file. Thanks to the excellent packaging of the Debian nis package, it should be an almost painless upgrade though. (Yes, I really do think the Debian nis package is extremely well maintained.) > >2) Avoid mixing architecture, OS, distro, implementation and version of > >NIS servers in a production environment unless you actually find > >pleasure in voodoo and the black magic of NIS/YP. (I obviously do :-)) > > Well, I do find some pleasure in a moderate use of voodoo and the black > magic of NIS/YP myself, but I do not have a choice. I will replace old > x86 computers in the cluster I administer with amd64 ones, gradually, > which means that for some time I will have to live with a mixed > environment. And I will have to do my best to ensure that 64bits machines > are used near their full potential (hence a 64bit system) but still > sacrificing as little functionality as possible (hence a full 32 bit > system in a chroot cage as well). Oh, and it should be as transparent as > possible to users, as well. I think I am going to need some psychiatric > help in the near future... IMHO, NIS doesn't make use of much resources - thus, dedicating an old low-memory box with reliable hardware is my own personal policy regarding slave NIS servers. -ukh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug reporting?
On Fri, 14 Jan 2005, Kaare Hviid wrote: 1) Using a pure64 amd64 box (or alpha for that matter) as an NIS slave with an i386 box as master _will_ work, albeit rpc.ypxfrd will complain. Yes, I actually came to this same conclusion, after some more work. What puzzles me is that _every_ time I start the nis server with the stock /etc/init.d/nis script, be it manually or at boot time, the maps are transferred anew! Perhaps, due to the fact that map files are not identical to the ones on the master server, the nis slave server thinks its maps are outdated and tries to refresh them every time it is started, every time falling back to the enumerate mechanism, and thus every time creating new files which are not identical to the ones on the master server... 2) Avoid mixing architecture, OS, distro, implementation and version of NIS servers in a production environment unless you actually find pleasure in voodoo and the black magic of NIS/YP. (I obviously do :-)) Well, I do find some pleasure in a moderate use of voodoo and the black magic of NIS/YP myself, but I do not have a choice. I will replace old x86 computers in the cluster I administer with amd64 ones, gradually, which means that for some time I will have to live with a mixed environment. And I will have to do my best to ensure that 64bits machines are used near their full potential (hence a 64bit system) but still sacrificing as little functionality as possible (hence a full 32 bit system in a chroot cage as well). Oh, and it should be as transparent as possible to users, as well. I think I am going to need some psychiatric help in the near future... Bye Giacomo -- _ Giacomo Mulas <[EMAIL PROTECTED]> _ OSSERVATORIO ASTRONOMICO DI CAGLIARI Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222 Tel. (UNICA): +39 070 675 4916 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug reporting?
OK, I just conducted a few non-scientific tests regarding the use of
amd64 as an NIS slave. This is, as I suspected, not a gcc-3.4/pure64
issue, nor an amd64 issue. IIRC, rpc.ypxfrd transfers the raw
databases in the host native format - and if I'm not mistaken that's
the way it works in the original Sun ONC implementation as well. (The
Linux NIS/YP stuff is reverse engineered, since Sun wants $$$ and NDAs
for code and/or proper protocol documentation.) Indeed, the problem
arises when trying to use an alpha as a slave server as well, and I
wouldn't be surprised if it will happen on, say, PPC too because of the
endianess. The Linux NIS/YP implementation does, however, have a
fallback mechanism for these cases. If, after doing the ypinit, you
actually check your /var/yp/${nisdomainname} catalog, you should find
all the databases there anyway, and you should also find that the slave
server actually works. In other words, ypinit complains, but it still
should work and function.
To make a long story short:
1) Using a pure64 amd64 box (or alpha for that matter) as an NIS slave
with an i386 box as master _will_ work, albeit rpc.ypxfrd will complain.
2) Avoid mixing architecture, OS, distro, implementation and version of
NIS servers in a production environment unless you actually find
pleasure in voodoo and the black magic of NIS/YP. (I obviously do :-))
-ukh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug reporting?
On Thu, 13 Jan 2005, Kurt Roeckx wrote: I have to disagree if it's build using an experimental compiler. Please do not submit bugs to the debian bts about those. Ok, so I take this to mean that one should file bugs to the bts _if_ they refer to pure64 (which is built with gcc 3.3 and, very few packages, with gcc 3.4) but _not_ if they refer to packages in gcc34, most of which are, or will be, compiled with gcc 4.0. Would this be an acceptable policy? What about adding a clear statement about this in the FAQ and/or HOWTO (if it's not there already and I missed it)? bye Giacomo -- _ Giacomo Mulas <[EMAIL PROTECTED]> _ OSSERVATORIO ASTRONOMICO DI CAGLIARI Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222 Tel. (UNICA): +39 070 675 4916 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug reporting?
On Thu, Jan 13, 2005 at 08:25:35PM +0100, Harald Dunkel wrote: > Bob Proulx wrote: > | Giacomo Mulas wrote: > | > |>Now the questions: should I use the standard debian bug tracking system to > |>report amd64 bugs? I am uncertain, since it is not (yet) an official port. > | > > MHO: Yes. > > I would say that the package owner is best to decide whether > the problem is caused by the new compiler and can be put > on hold, or whether there is a more general problem affecting > the "official" platforms, too. I have to disagree if it's build using an experimental compiler. Please do not submit bugs to the debian bts about those. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug reporting?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bob Proulx wrote: | Giacomo Mulas wrote: | |>Now the questions: should I use the standard debian bug tracking system to |>report amd64 bugs? I am uncertain, since it is not (yet) an official port. | MHO: Yes. I would say that the package owner is best to decide whether the problem is caused by the new compiler and can be put on hold, or whether there is a more general problem affecting the "official" platforms, too. This way the bts can be used to collect and document possible fixes or workarounds. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB5ssvUTlbRTxpHjcRAreVAJ9x5g3yEvARwJy9Fse6Kgu9c2rjGQCdHGDj S1ZBLhJYBx0XVwlOtrEIWWM= =DuFu -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug reporting?
Giacomo Mulas wrote: > Now the questions: should I use the standard debian bug tracking system to > report amd64 bugs? I am uncertain, since it is not (yet) an official port. A good concern. Depending upon the bug I compare with ia64 or alpha which are an official ports. If it is a bug in the 64-bit port from a 32-bit system you can report it as such against all of the 64-bit architectures. Otherwise I file it as a normal bug, no higher. Most package maintainers understand the issues of amd64 being only an unofficial port and still want to see their packages work on all platforms. > In the meanwhile, the second question: did anybody (try to) install a > slave nis server on a pure64 and get it to transfer the nis maps from a > debian x86 nis master server? Did anybody actually _succeed_ at it? Hmm... I could probably try it two weeks from now but no sooner. :-} > Problem description: when I run > > /usr/lib/yp/ypinit -s > > on the wannabe pure64 nis slave server, I get something like: > > Transferring passwd.byuid... > Trying ypxfrd ...rpc.ypxfrd doesn't support the needed database type > call to rpc.ypxfrd failed: RPC: Can't decode result > > (failed, fallback to enumeration) > > which is replicated for each and every nis map. The above occurs also each > and every time I start the nis server/daemon using the provided > /etc/init.d/nis script. If I replicate the configuration in the 32 bit > chroot and run the 32 bit ypinit and/or server/daemon, everything runs > smoothly. Does smell like a 64-bit problem from your description. > Any hints, suggestions (apart from abandoning nis, which I would if I > could, but I cannot...) File that as a wishlist bug. :-) Bob signature.asc Description: Digital signature
Re: bug reporting?
On Wed, Jan 12, 2005 at 02:41:07PM +0100, Giacomo Mulas wrote: > Problem description: when I run > > /usr/lib/yp/ypinit -s > > on the wannabe pure64 nis slave server, I get something like: > > Transferring passwd.byuid... > Trying ypxfrd ...rpc.ypxfrd doesn't support the needed database type > call to rpc.ypxfrd failed: RPC: Can't decode result > > (failed, fallback to enumeration) > > which is replicated for each and every nis map. The above occurs also each > and every time I start the nis server/daemon using the provided > /etc/init.d/nis script. If I replicate the configuration in the 32 bit > chroot and run the 32 bit ypinit and/or server/daemon, everything runs > smoothly. > > Any hints, suggestions (apart from abandoning nis, which I would if I > could, but I cannot...) > My suggestion is to analyse the exchange between your machine and the master with a network analyser and spot the differences between both (the 64bit run and the 32bit run). Ethereal is the boss for this. Once you have got the differences, check to the part of the code that is responsible for the encoding. The bug is certainly there. Seb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
bug reporting?
Hello, I am a long time Debian user but a newcomer to the amd64 port. I met a problem in setting up a pure64 machine as a slave nis server, connected to a standard debian woody x86 nis master. It looks like the problem is in the 64 bit version, as it does not appear in the 32 bit version I installed (as a test) in the chroot. Now the questions: should I use the standard debian bug tracking system to report amd64 bugs? I am uncertain, since it is not (yet) an official port. In the meanwhile, the second question: did anybody (try to) install a slave nis server on a pure64 and get it to transfer the nis maps from a debian x86 nis master server? Did anybody actually _succeed_ at it? Problem description: when I run /usr/lib/yp/ypinit -s on the wannabe pure64 nis slave server, I get something like: Transferring passwd.byuid... Trying ypxfrd ...rpc.ypxfrd doesn't support the needed database type call to rpc.ypxfrd failed: RPC: Can't decode result (failed, fallback to enumeration) which is replicated for each and every nis map. The above occurs also each and every time I start the nis server/daemon using the provided /etc/init.d/nis script. If I replicate the configuration in the 32 bit chroot and run the 32 bit ypinit and/or server/daemon, everything runs smoothly. Any hints, suggestions (apart from abandoning nis, which I would if I could, but I cannot...) Thanks, bye Giacomo -- _ Giacomo Mulas <[EMAIL PROTECTED]> _ OSSERVATORIO ASTRONOMICO DI CAGLIARI Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222 Tel. (UNICA): +39 070 675 4916 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
