Re: Do we still need portmap(8)?

"Danny J. Zerkel" wrote: > Sigh... there should be a file listing incompatible files that is part of > the source tree. Every file in this list would be deleted as a pre-install > step. Perl would not have been in this list because it was not > incompatible. But the old C++ headers clearly wer

Re: Do we still need portmap(8)?

On Wednesday 09 October 2002 17:00, Terry Lambert wrote: > "Danny J. Zerkel" wrote: > > And a list of files to delete would have saved many emails about the > > GCC being broken when the old headers just needed to be deleted. > > No, it wouldn't. > > The same people who failed to read the mailing

Re: Do we still need portmap(8)?

Sheldon Hearn wrote: > On (2002/10/09 22:03), Terry Lambert wrote: > > The other problem with an mtree.obsolete is that it assumes > > the the upgrade process completes successfully. This doesn't > > mean that it completes without an error in the upgrade process, > > it means that the resulting s

Re: Do we still need portmap(8)?

On (2002/10/09 22:03), Terry Lambert wrote: > The other problem with an mtree.obsolete is that it assumes > the the upgrade process completes successfully. This doesn't > mean that it completes without an error in the upgrade process, > it means that the resulting system functions. Why not just

Re: Do we still need portmap(8)?

In message: <[EMAIL PROTECTED]> Terry Lambert <[EMAIL PROTECTED]> writes: : "M. Warner Losh" wrote: : > In message: : > Garance A Drosihn <[EMAIL PROTECTED]> writes: : > : I think most of us realize that we need a solution which can b

Re: Do we still need portmap(8)?

"M. Warner Losh" wrote: > In message: > Garance A Drosihn <[EMAIL PROTECTED]> writes: > : I think most of us realize that we need a solution which can be > : automatically executed as part of every installworld or mergemaster > : run. The debate

Re: Do we still need portmap(8)?

In message: Garance A Drosihn <[EMAIL PROTECTED]> writes: : I think most of us realize that we need a solution which can be : automatically executed as part of every installworld or mergemaster : run. The debate is over the most reasonable metho

Re: Do we still need portmap(8)?

At 2:00 PM -0700 10/9/02, Terry Lambert wrote: >"Danny J. Zerkel" wrote: > > And a list of files to delete would have saved many emails > > about the GCC being broken when the old headers just needed > > to be deleted. > >No, it wouldn't. > >The same people who failed to read the mailing list,

Re: Do we still need portmap(8)?

Garance A Drosihn writes: >>We could add 'rm -rf /usr/include/*' at a suitable point inside >>the installworld target. > >Installers should not be blindly removing entire directory structures. The only things that live under /usr/include are those owned by the system's install target, therefore

Re: Do we still need portmap(8)?

At 3:09 PM -0600 10/9/02, Lyndon Nerenberg wrote: > Danny> And a list of files to delete would have saved many emails > Danny> about the GCC being broken when the old headers just needed > Danny> to be deleted. > >We could add 'rm -rf /usr/include/*' at a suitable point inside >the ins

Re: Do we still need portmap(8)?

Danny> And a list of files to delete would have saved many emails Danny> about the GCC being broken when the old headers just needed Danny> to be deleted. We could add 'rm -rf /usr/include/*' at a suitable point inside the installworld target. --lyndon To Unsubscribe: send mail to [

Re: Do we still need portmap(8)?

"Danny J. Zerkel" wrote: > And a list of files to delete would have saved many emails about the > GCC being broken when the old headers just needed to be deleted. No, it wouldn't. The same people who failed to read the mailing list, and see the first time the problem came up, and was solved, wou

Re: Do we still need portmap(8)?

On Monday 07 October 2002 21:05, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > > Giorgos Keramidas <[EMAIL PROTECTED]> writes: > : On 2002-10-07 15:14, Archie Cobbs <[EMAIL PROTECTED]> wrote: > : > Anything that gets overwritten during the normal install process > : > is al

Re: Do we still need portmap(8)?

> "M" == M Warner Losh <[EMAIL PROTECTED]> writes: M> I think that we need a mtree.obsolete that goes through and M> deletes these sorts of things as part of installworld/upgrade M> scripts. No solution like this will ever work for everyone, or in every situation. For example, yo

Re: Removing old binaries (was: Do we still need portmap(8)?)

On Tue, Oct 08, 2002 at 10:35:39AM +0930, Greg 'groggy' Lehey wrote: > On Monday, 7 October 2002 at 20:07:37 -0400, Daniel Eischen wrote: > > On Tue, 8 Oct 2002, Greg 'groggy' Lehey wrote: > > > > I'd prefer this as a job for mergemaster, asking you confirmation > > for each binary. > > I'd much

Re: Removing old binaries (was: Do we still need portmap(8)?)

I wrote: >> >> I understand what the topic is. I don't understand your comment, "I'd >> be inclined just to remove all files in those directories which are older >> than some file in the build tree--*after* a successful >> installation." > > Ah, sorry, that might bear more explanation. > > > "i

Re: Removing old binaries (was: Do we still need portmap(8)?)

At 11:31 AM +0930 10/8/02, Greg 'groggy' Lehey wrote: > > "install -C" doesn't change the timestamp, so you'll have tons of >> files that are older than "some file in the build tree". > >What does the last access timestamp look like after install -C? What does the last-access timestamp look lik

Re: Removing old binaries (was: Do we still need portmap(8)?)

On Monday, 7 October 2002 at 18:46:35 -0700, Steve Kargl wrote: > On Tue, Oct 08, 2002 at 10:34:42AM +0930, Greg 'groggy' Lehey wrote: >> On Monday, 7 October 2002 at 17:44:42 -0700, Steve Kargl wrote: >>> On Tue, Oct 08, 2002 at 09:16:10AM +0930, Greg 'groggy' Lehey wrote: On Monday, 7 Oc

Re: Removing old binaries (was: Do we still need portmap(8)?)

On Tue, Oct 08, 2002 at 10:34:42AM +0930, Greg 'groggy' Lehey wrote: > On Monday, 7 October 2002 at 17:44:42 -0700, Steve Kargl wrote: > > On Tue, Oct 08, 2002 at 09:16:10AM +0930, Greg 'groggy' Lehey wrote: > >> On Monday, 7 October 2002 at 11:20:56 -0600, M. Warner Losh wrote: > >>> In message

Re: Removing old binaries (was: Do we still need portmap(8)?)

On Monday, 7 October 2002 at 21:18:10 -0400, Daniel Eischen wrote: > On Tue, 8 Oct 2002, Greg 'groggy' Lehey wrote: >> On Monday, 7 October 2002 at 20:07:37 -0400, Daniel Eischen wrote: >>> On Tue, 8 Oct 2002, Greg 'groggy' Lehey wrote: >>> I think we can greatly simplify things with one fi

Re: Removing old binaries (was: Do we still need portmap(8)?)

On Tue, 8 Oct 2002, Greg 'groggy' Lehey wrote: > On Monday, 7 October 2002 at 20:07:37 -0400, Daniel Eischen wrote: > > On Tue, 8 Oct 2002, Greg 'groggy' Lehey wrote: > > > >> I think we can greatly simplify things with one firm but relatively > >> bearable rule: > >> > >> The directories /bin,

Re: Removing old binaries (was: Do we still need portmap(8)?)

On Tue, Oct 08, 2002 at 10:34:42AM +0930, Greg 'groggy' Lehey wrote: > > What would you do about "install -C"? > > I think it confuses the issue rather than solving it. We're talking > about removing binaries which are no longer needed, not replacing > binaries that are needed. install -C will

Re: Do we still need portmap(8)?

In message: <[EMAIL PROTECTED]> Giorgos Keramidas <[EMAIL PROTECTED]> writes: : On 2002-10-07 15:14, Archie Cobbs <[EMAIL PROTECTED]> wrote: : > Anything that gets overwritten during the normal install process : > is already taken care of. We're just trying to get rid of files : > whic

Re: Removing old binaries (was: Do we still need portmap(8)?)

On Monday, 7 October 2002 at 20:07:37 -0400, Daniel Eischen wrote: > On Tue, 8 Oct 2002, Greg 'groggy' Lehey wrote: > >> I think we can greatly simplify things with one firm but relatively >> bearable rule: >> >> The directories /bin, /usr/bin, /sbin, /usr/sbin, > here> are for the exclusive

Re: Removing old binaries (was: Do we still need portmap(8)?)

; "Greg 'groggy' Lehey" <[EMAIL PROTECTED]> writes: >>>> It's been a while since we've used portmap(8) on -CURRENT systems. Is >>>> it still needed, or can it be removed completely? At the very least, >>>> the man page s

Re: Do we still need portmap(8)?

Archie Cobbs wrote: > You are right in that additional programs or custom modifications > that depend on the obsolete stuff would break if the obsolete stuff > were removed... so you'd have to confirm everything with mergemaster. > Possibly this is too dangerous to be useful. > > But it would be

Re: Removing old binaries (was: Do we still need portmap(8)?)

On Tue, Oct 08, 2002 at 09:16:10AM +0930, Greg 'groggy' Lehey wrote: > On Monday, 7 October 2002 at 11:20:56 -0600, M. Warner Losh wrote: > > In message: <[EMAIL PROTECTED]> > > "Greg 'groggy' Lehey" <[EMAIL PROTECTED]> writ

Re: Removing old binaries (was: Do we still need portmap(8)?)

On Tue, 8 Oct 2002, Greg 'groggy' Lehey wrote: > On Monday, 7 October 2002 at 11:20:56 -0600, M. Warner Losh wrote: > > In message: <[EMAIL PROTECTED]> > > "Greg 'groggy' Lehey" <[EMAIL PROTECTED]> writes: > >> It&#

Removing old binaries (was: Do we still need portmap(8)?)

On Monday, 7 October 2002 at 11:20:56 -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > "Greg 'groggy' Lehey" <[EMAIL PROTECTED]> writes: >> It's been a while since we've used portmap(8) on -CURRENT systems. Is &g

Re: Do we still need portmap(8)?

On 2002-10-07 15:14, Archie Cobbs <[EMAIL PROTECTED]> wrote: > Anything that gets overwritten during the normal install process > is already taken care of. We're just trying to get rid of files > which are not installed by 'make installword' but used to be once. > > I.e., if a file is not install

Re: Do we still need portmap(8)?

older shared library instances, not just header > files that are stale, etc.. Older shared libraries being removed > would break things. Older portmap being removed would break the You are right in that additional programs or custom modifications that depend on the obsolete stuff would br

Re: Do we still need portmap(8)?

In message: <[EMAIL PROTECTED]> Archie Cobbs <[EMAIL PROTECTED]> writes: : I.e., if a file is not installed by 'make installworld' then by : definition it's not required for a correctly functioning system. The only exceptions to this rule would be if something was once in the system,

Re: Do we still need portmap(8)?

t would include perl and older shared library instances, not just header files that are stale, etc.. Older shared libraries being removed would break things. Older portmap being removed would break the startup scripts that referenced "portmapper" instead of "rpc.bind" -- unless they we

Re: Do we still need portmap(8)?

Terry Lambert writes: > > > : It's been a while since we've used portmap(8) on -CURRENT systems. Is > > > : it still needed, or can it be removed completely? At the very least, > > > : the man page should stop claiming that it's necessary to r

Re: Do we still need portmap(8)?

Archie Cobbs wrote: > M. Warner Losh writes: > > : It's been a while since we've used portmap(8) on -CURRENT systems. Is > > : it still needed, or can it be removed completely? At the very least, > > : the man page should stop claiming that it's necessary

Re: Do we still need portmap(8)?

Daniel Flickinger wrote: > >Name: text >textType: Plain Text (text/plain) >Encoding: 7bit As an EMACS afficionado, perhaps I can get you to fix AtillaMail? Right now, even without attachments other than the message body, it adds: Content-Type: text/plain; ch

Re: Do we still need portmap(8)?

"Joel M. Baldwin" wrote: > Shouldn't ALL of the files in /bin, /usr/bin, /usr/include, /usr/lib > etc be replaced during an installworld? They are replaced... if they exist boith before and afterward. They are also created... if they did not exist before, but do exist afterward. What's not done

Re: Do we still need portmap(8)?

> In message: <[EMAIL PROTECTED]> > "Greg 'groggy' Lehey" <[EMAIL PROTECTED]> writes: > : It's been a while since we've used portmap(8) on -CURRENT systems. Is > : it still needed, or can it be removed completely? At the very

Re: Do we still need portmap(8)?

M. Warner Losh writes: > : It's been a while since we've used portmap(8) on -CURRENT systems. Is > : it still needed, or can it be removed completely? At the very least, > : the man page should stop claiming that it's necessary to run NFS. > > I think that we n

Re: Do we still need portmap(8)?

In message: <[EMAIL PROTECTED]> "Greg 'groggy' Lehey" <[EMAIL PROTECTED]> writes: : It's been a while since we've used portmap(8) on -CURRENT systems. Is : it still needed, or can it be removed completely? At the very least, : the man page s

Re: Do we still need portmap(8)?

On Mon, Oct 07, 2002 at 04:32:10AM -0700, Joel M. Baldwin wrote: > > Shouldn't ALL of the files in /bin, /usr/bin, /usr/include, /usr/lib > etc be replaced during an installworld? > It depends. If you have INSTALL='install -C" in /etc/make.conf, then some (or even all) of the files in the name

Re: Do we still need portmap(8)?

x27;re obsolete. > > ( aside, not delete, just in case ) Well, mostly all. (1) If a file is removed from the source tree, it won't be replaced, it will just get stale. That's what happened with grog's portmap and portmap.8.gz. Even more annoying are the man cache fil

Re: Do we still need portmap(8)?

04:02:51PM +0930, Greg 'groggy' Lehey wrote: >>>> It's been a while since we've used portmap(8) on -CURRENT systems. >>>> Is it still needed, or can it be removed completely? At the very >>>> least, the man page should stop claiming that it'

Re: Do we still need portmap(8)?

In message <[EMAIL PROTECTED]>, "Greg 'groggy' Lehey" writes: >On Sunday, 6 October 2002 at 23:42:55 -0700, David O'Brien wrote: >> On Mon, Oct 07, 2002 at 04:02:51PM +0930, Greg 'groggy' Lehey wrote: >>> It's been a while since we

Re: Do we still need portmap(8)?

On Sunday, 6 October 2002 at 23:42:55 -0700, David O'Brien wrote: > On Mon, Oct 07, 2002 at 04:02:51PM +0930, Greg 'groggy' Lehey wrote: >> It's been a while since we've used portmap(8) on -CURRENT systems. Is >> it still needed, or can it be removed co

Re: Do we still need portmap(8)?

On Mon, Oct 07, 2002 at 04:02:51PM +0930, Greg 'groggy' Lehey wrote: > It's been a while since we've used portmap(8) on -CURRENT systems. Is > it still needed, or can it be removed completely? At the very least, > the man page should stop claiming that it's nec

Do we still need portmap(8)?

It's been a while since we've used portmap(8) on -CURRENT systems. Is it still needed, or can it be removed completely? At the very least, the man page should stop claiming that it's necessary to run NFS. Greg -- See complete headers for address and phone numbers To Unsubscrib

Re: portmap

Hi! On Tue, Jul 30, 2002 at 09:52:26PM +0200, Radko Keves wrote: > i upgrade from 4.5 to 5.0 and portmap haven't found new, > and source for portmap haven't found too RPC-to-TCP/UDP port mapper now called 'rpcbind'. > i need your help You really should run '

portmap

i have problem with mountd, and i think that is portmap problem i upgrade from 4.5 to 5.0 and portmap haven't found new, and source for portmap haven't found too i need your help mountd write this logs: Jul 30 21:18:25 kripel mountd[16350]: can't register UDP RPCMNT_VER1 se

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

On Mon, Apr 09, 2001 at 08:49:59PM -0700, Rodney W. Grimes wrote: > > Question: Does the rpcbind program in -current have the same problem > > or has it already been fixed by whomever you imported the code from? > > (If it hasn't been fixed I'll be happy to fix it. I'm hoping it has,

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

ng to figure out why NFS wasn't drilling through two firewalls to one of our exodus machines (for a /usr/src and /usr/obj mount). It took about an hour to finally figure out that there was nothing wrong with the firewalls and portmap on the inside was trying to respond with an int

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

> Ok guys. I just had to fix a problem with portmap in -stable related > to binding to specific IP addresses so replies to UDP packets come > 'from' the proper IP address (for multi-homed hosts). This has been a problem with portmap for as long as I can remember

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

* Matt Dillon <[EMAIL PROTECTED]> [010409 19:40] wrote: > Ok guys. I just had to fix a problem with portmap in -stable related > to binding to specific IP addresses so replies to UDP packets come > 'from' the proper IP address (for multi-homed hosts). >

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

Ok guys. I just had to fix a problem with portmap in -stable related to binding to specific IP addresses so replies to UDP packets come 'from' the proper IP address (for multi-homed hosts). Question: Does the rpcbind program in -current have the same problem

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

#x27;t a big problem. However, for consistency, it probably is the case that someone should go slap s/portmap/rpcbind/ s/PORTMAP/RPCBIND/ strategically through /etc and associated man pages. Maybe adding a compatibility check that maps PORTMAP into RPCBIND, and then prints a message on boot in the styl

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

On Wed, Mar 28, 2001 at 10:14:07PM +0200, Karsten W. Rohrbach wrote: > Peter Wemm([EMAIL PROTECTED])@2001.03.28/06:24:34(epoch+985757074s): Drop this useless discussion, or take me off the blooming CC: list. Learn to use your editor! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscri

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

In message <[EMAIL PROTECTED]> "Karsten W. Rohrbach" writes: : Peter Wemm([EMAIL PROTECTED])@2001.03.28/06:24:34(epoch+985757074s): : > FYI: : > : > SYNOPSIS : > portmap [-d] [-v] : > : > SYNOPSIS : > rpcbind [-dilLs] : : yup, so i think it m

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

Peter Wemm([EMAIL PROTECTED])@2001.03.28/06:24:34(epoch+985757074s): > FYI: > > SYNOPSIS > portmap [-d] [-v] > > SYNOPSIS > rpcbind [-dilLs] yup, so i think it makes sense, to have the daemon called rpcbind, since it would probably break other people's

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

Doug Barton wrote: > "Karsten W. Rohrbach" wrote: > > > the idea is, that if rpcbind takes parameters different from portmap it > > would make sense to call rpcbind rpcbind because people's boxes will > > start to barf when rpcbind is called portmap, th

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

"Karsten W. Rohrbach" wrote: > the idea is, that if rpcbind takes parameters different from portmap it > would make sense to call rpcbind rpcbind because people's boxes will > start to barf when rpcbind is called portmap, they make world, and skip > reading the rp

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

Play the ball, not the man. > > > : > > > : I don't have an objection to the change, I was just asking. And > > > : "because System V does it this way" has never been a good answer for > > > : us. And no, I'm not picking on Doug, just maki

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

r > : us. And no, I'm not picking on Doug, just making a point. > > I see no reason why the name can't remain portmap. My previous comment was mostly an attempt at humor, in case anyone missed that. :) I have no problem with keeping the name the same as it is in netbsd t

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

hange, I was just asking. And > > : "because System V does it this way" has never been a good answer for > > : us. And no, I'm not picking on Doug, just making a point. > > > > I see no reason why the name can't remain portmap. > > > does it take

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

it this way" has never been a good answer for > : us. And no, I'm not picking on Doug, just making a point. > > I see no reason why the name can't remain portmap. > does it take parameters? then it would make sense to have it named rpcbind... /k -- > "Dope wi

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

ust making a point. I see no reason why the name can't remain portmap. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

001 at 10:44:38 -0800, David O'Brien wrote: >>>>> The Portmapper binary has been renamed from `portmap' to `rpcbind'. >>>> >>>> Why? >>> >>> So we can be more like sysV >> >> This is good? > > If it's the b

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

On Mon, Mar 26, 2001 at 05:24:14PM +0930, Greg Lehey wrote: > On Sunday, 25 March 2001 at 23:48:10 -0800, Doug Barton wrote: > > Greg Lehey wrote: > >> > >> On Wednesday, 21 March 2001 at 10:44:38 -0800, David O'Brien wrote: > >>> The Portmapper binary

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

On Sunday, 25 March 2001 at 23:48:10 -0800, Doug Barton wrote: > Greg Lehey wrote: >> >> On Wednesday, 21 March 2001 at 10:44:38 -0800, David O'Brien wrote: >>> The Portmapper binary has been renamed from `portmap' to `rpcbind'. >> >> Why?

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

Greg Lehey wrote: > > On Wednesday, 21 March 2001 at 10:44:38 -0800, David O'Brien wrote: > > The Portmapper binary has been renamed from `portmap' to `rpcbind'. > > Why? So we can be more like sysV -- Perhaps the greatest damage the American sy

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

* Greg Lehey <[EMAIL PROTECTED]> [010325 15:33] wrote: > On Wednesday, 21 March 2001 at 10:44:38 -0800, David O'Brien wrote: > > The Portmapper binary has been renamed from `portmap' to `rpcbind'. > > Why? We've upgraded to Sun's TIRPC code, this in

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

On Wednesday, 21 March 2001 at 10:44:38 -0800, David O'Brien wrote: > The Portmapper binary has been renamed from `portmap' to `rpcbind'. Why? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail t

Re: [FIX] Re: CFS - Portmap

Hi, > > /etc/mount -o port=3049,intr localhost:/null /crypt > > What machine are you doing this on?? FreeBSD has no /etc/mount? Correct. I've used the sbin/mount of course, this is just a cut'n'paste of the documentation. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscr

Re: [FIX] Re: CFS - Portmap

On Fri, Mar 23, 2001 at 12:49:33AM +0100, Martin Blapp wrote: > /etc/mount -o port=3049,intr localhost:/null /crypt What machine are you doing this on?? FreeBSD has no /etc/mount? -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMA

Re: [FIX] Re: CFS - Portmap

On Fri, Mar 23, 2001 at 19:35:33 +0100, Martin Blapp wrote: > > This should made cfs working again, please test the patch. > > http://home.teleport.ch/freebsd/mount_nfs.c.diff No, but bad effects are changed. There is no error diagnostic happens but mount hangs forever instead (I try several t

Re: [FIX] Re: CFS - Portmap

This should made cfs working again, please test the patch. http://home.teleport.ch/freebsd/mount_nfs.c.diff Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland

Re: [FIX] Re: CFS - Portmap

I'll go to bed now. It's not cfsd which does this. My update of mount_nfs (and syncing source with NetBSD) broke this. I'll change mount_nfs so this works again. There is no need for mount_nfs to register nfs within rpcbind if port=0. Sorry that this last so long to detect. Martin Martin Blap

Re: [FIX] Re: CFS - Portmap

I'm fixing now the code ... We have to use now Solaris code part and add #if defined(__FreeBSD__) || defined (__SOLARIS2X__) ifdef's and also fill out this: /* Assign the local bind address and type of service */ tp->xp_ltaddr = tres->addr; tp->xp_type = tinfo.servtype;

Re: [FIX] Re: CFS - Portmap

On Fri, Mar 23, 2001 at 00:49:33 +0100, Martin Blapp wrote: > > > Breaking nfs from working on user defined ports is a step backwards and > > should be fixed. Lots of people run nfsd and cfsd at the same time. > > No, you understand me wrong, the way this is done is bogus. If you set > -DCFS_PO

Re: [FIX] Re: CFS - Portmap

> Breaking nfs from working on user defined ports is a step backwards and > should be fixed. Lots of people run nfsd and cfsd at the same time. No, you understand me wrong, the way this is done is bogus. If you set -DCFS_PORT=3049 like it is done at the moment and use nc instead of NULL it work

Re: [FIX] Re: CFS - Portmap

Martin Blapp wrote: > > Ok, > > here is what I found: > > notes.ms, line 228 > > If your system does not support NFS mounts on ports other > than 2049, add -DCFS_PORT=2049; you will not be able to simultaneously > run the target system as an NFS server under this configuration. > > cfs.h:#def

Re: [FIX] Re: CFS - Portmap

On Fri, Mar 23, 2001 at 00:33:28 +0100, Martin Blapp wrote: > > > If you compile with -DCFS_PORT=2049, cfs works as normal. > It sounds like in that case it is impossible to run nfsd and cfsd at the same machine, i.e. does cfs disallows nfs? BTW, why it works before? -- Andrey A. Chernov h

Re: [FIX] Re: CFS - Portmap

Ok, here is what I found: notes.ms, line 228 If your system does not support NFS mounts on ports other than 2049, add -DCFS_PORT=2049; you will not be able to simultaneously run the target system as an NFS server under this configuration. cfs.h:#define CFS_PORT 2049 nfsproto.h:#define NF

Re: [FIX] Re: CFS - Portmap

* Martin Blapp <[EMAIL PROTECTED]> [010322 15:00] wrote: > > Hi, > > I see, seems that (port==2049? nc : NULL) has changed in some way. > I'll fix that. > > PS: let's change to private discussion and not cc current anymore. Please don't, I'd like to understand what's going on here. There's al

Re: [FIX] Re: CFS - Portmap

Hi, I see, seems that (port==2049? nc : NULL) has changed in some way. I'll fix that. PS: let's change to private discussion and not cc current anymore. Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zur

Re: [FIX] Re: CFS - Portmap

Hmm, look at this: # mount /crypt mount_nfs: rpcbind on server: RPC: Program not registered rpcbind debug output: PMAP_GETPORT req for (13, 2, udp) from 127.0.0.1.3.18 :port = 0 nfs is prgramm 13 For some strange reason there is a request for nfs. Martin To Unsubscribe: send mail t

Re: [FIX] Re: CFS - Portmap

On Fri, Mar 23, 2001 at 01:35:12 +0300, Andrey A. Chernov wrote: > On Thu, Mar 22, 2001 at 23:32:53 +0100, Martin Blapp wrote: > > > # nfsd > > ^ > > Not start nfsd - it is unneded for cfs, cfs handle all calls by itself. > At least it works without any nfsd previously. I.e. you have s

Re: [FIX] Re: CFS - Portmap

Without nfsd it doesn't work, right. Yes, this seems to be the problem. I'll go into source of cfs now and fix the problem. Or maybe a mount_nfs problem ? Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zu

Re: [FIX] Re: CFS - Portmap

On Thu, Mar 22, 2001 at 23:32:53 +0100, Martin Blapp wrote: > # nfsd ^ Not start nfsd - it is unneded for cfs, cfs handle all calls by itself. At least it works without any nfsd previously. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "

Re: [FIX] Re: CFS - Portmap

Hmm ? # /usr/local/etc/rc.d/cfsd.sh stop # killall mountd # killall -SIGUSR1 nfsd # killall rpcbind # rpcinfo rpcinfo: can't contact rpcbind: RPC: Remote system error - Connection refused # rpcbind -i # mountd -2 # nfsd # /usr/local/etc/rc.d/cfsd.sh start # mount_nfs -o port=3049,intr,nfsv2 lo

Re: [FIX] Re: CFS - Portmap

On Thu, Mar 22, 2001 at 23:07:08 +0100, Martin Blapp wrote: > > It seems you have to run rpcbind with -i flag: > -i not helps too. Diagnostic is the same. > > # mount_nfs -o port=3049,intr localhost:/null /crypt You miss "nfsv2" switch here. mountd is running with -2 option too. To make te

Re: CFS - Portmap

On Thu, Mar 22, 2001 at 22:53:29 +0100, Martin Blapp wrote: > > If you have not recompiled cfs, does starting the rpcbind with -L > fix this ? Old binarys resist to work without this option. -L not helps for old and for new binaries too. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe:

[FIX] Re: CFS - Portmap

It seems you have to run rpcbind with -i flag: -i ``insecure'' mode. Allows calls to SET and UNSET from an host. Normally rpcbind accepts these requests only from the loopback interface for security reasons. This change is necessary for programs that were compiled with earlier versions o

Re: CFS - Portmap

If you have not recompiled cfs, does starting the rpcbind with -L fix this ? Old binarys resist to work without this option. from rpcbind man-page: Allow old-style local connections over the loopback interface. Without this flag, local connections are only allowed over a local socket, /var/run/

Re: CFS - Portmap

On Thu, Mar 22, 2001 at 13:37:02 -0800, Alfred Perlstein wrote: > > 151udp 0.0.0.0.3.237 mountd superuser > > 151tcp 0.0.0.0.3.251 mountd superuser > > 10928305672udp 0.0.0.0.11.233 - superuser >

Re: CFS - Portmap

* Andrey A. Chernov <[EMAIL PROTECTED]> [010322 13:09] wrote: > On Thu, Mar 22, 2001 at 20:34:19 -0300, Daniel wrote: > > > > I also tried using rpcbind, mountd start working and cfsd start but: > > > > %/sbin/mount -o port=3049,intr,nfsv2 localhost:/usr/home/.cfs \ > > > > /usr/local/crypt > > >

Re: CFS - Portmap

On Thu, Mar 22, 2001 at 20:34:19 -0300, Daniel wrote: > > > I also tried using rpcbind, mountd start working and cfsd start but: > > > %/sbin/mount -o port=3049,intr,nfsv2 localhost:/usr/home/.cfs \ > > > /usr/local/crypt > > > > > > mount_nfs: rpcbind on server: RPC: Program not registered Yes,

Re: CFS - Portmap

On Thu, Mar 22, 2001 at 08:34:19PM -0300, Daniel wrote: > Yes I guess you overwrite portmap_program in /etc/rc.conf. Sync the line with /etc/defaults/rc.conf or better remove it completely. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] User

Re: CFS - Portmap

Yes On Thu, 22 Mar 2001, Alfred Perlstein wrote: > Date: Thu, 22 Mar 2001 09:48:30 -0800 > From: Alfred Perlstein <[EMAIL PROTECTED]> > To: Daniel <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: CFS - Portmap > > * Daniel <[EMAIL PROTECTED]>

Re: CFS - Portmap

* Daniel <[EMAIL PROTECTED]> [010322 09:41] wrote: > > Hi, I've upgraded my system yesterday and cfs stoped working, the problem > is that it is not possible to use portmap because mountd died with this > message: > Mar 20 17:48:30 apocalypse mountd[67251]: can&

CFS - Portmap

Hi, I've upgraded my system yesterday and cfs stoped working, the problem is that it is not possible to use portmap because mountd died with this message: Mar 20 17:48:30 apocalypse mountd[67251]: can't register UDP RPCMNT_VER1 service Mar 20 17:48:30 apocalypse mountd[67251]: can'

  1   2   >