Re: Mentioning RFC numbers in /etc/services

[Peter Jeremy]

Assar Westerlund  wrote:

As an enhancement, the strtol() check should verify that the passed
service number is completely numeric:

>--- inetd.c.orig  Mon Aug  2 22:35:28 1999
>+++ inetd.c Mon Aug  2 22:41:52 1999
>@@ -830,34 +830,50 @@
>continue;
>}
>if (!sep->se_rpc) {
>+   int port;
+char *ep;
>+
>sp = getservbyname(sep->se_service, sep->se_proto);
>if (sp == 0) {
>- syslog(LOG_ERR, "%s/%s: unknown service",
>+   port = htons(strtol (sep->se_service,
+ &ep, 0));
+if (port <= 0 || *ep) {
...

and similarly for the RPC service number.

Brian Somers  wrote:
>I know I'd be pretty annoyed if I tried to do something like ``ssh -p 
>1234 somewhere'' after configuring my interface in single-user modem 
>with nis in /etc/host.conf and found that ssh was looking up 1234 in 
>/etc/services.  Even if this is right, it's not intuitive.

Adding definitions like ': 1 2 ;' to forth is always good for confusing
people.  Similarly, adding lines like '1234 4321/tcp' to /etc/services
will lead to counter-intuitive behaviour.

That said, I think that the get...byname() should preceed the strtol()
for general consistency.

Brian Somers  wrote:
>I've been stung with things like pipe() for exactly the same reasons. 
>IMHO, pipe() should *not* behave like socketpair() as it encourages 
>FreeBSD developers to write bad code :-(

SVR4 provides bi-directional pipe(2) FD's.  Digital UNIX (aka OSF/1
aka Tru64) seems to support both behaviours.  I suspect the trend will
be for pipe()'s to be bi-directional.  Feel free to add a sysctl to
make pipe's unidirectional.

Peter


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Peter Jeremy]

Assar Westerlund <[EMAIL PROTECTED]> wrote:

As an enhancement, the strtol() check should verify that the passed
service number is completely numeric:

>--- inetd.c.orig  Mon Aug  2 22:35:28 1999
>+++ inetd.c Mon Aug  2 22:41:52 1999
>@@ -830,34 +830,50 @@
>continue;
>}
>if (!sep->se_rpc) {
>+   int port;
+char *ep;
>+
>sp = getservbyname(sep->se_service, sep->se_proto);
>if (sp == 0) {
>- syslog(LOG_ERR, "%s/%s: unknown service",
>+   port = htons(strtol (sep->se_service,
+ &ep, 0));
+if (port <= 0 || *ep) {
...

and similarly for the RPC service number.

Brian Somers <[EMAIL PROTECTED]> wrote:
>I know I'd be pretty annoyed if I tried to do something like ``ssh -p 
>1234 somewhere'' after configuring my interface in single-user modem 
>with nis in /etc/host.conf and found that ssh was looking up 1234 in 
>/etc/services.  Even if this is right, it's not intuitive.

Adding definitions like ': 1 2 ;' to forth is always good for confusing
people.  Similarly, adding lines like '1234 4321/tcp' to /etc/services
will lead to counter-intuitive behaviour.

That said, I think that the get...byname() should preceed the strtol()
for general consistency.

Brian Somers <[EMAIL PROTECTED]> wrote:
>I've been stung with things like pipe() for exactly the same reasons. 
>IMHO, pipe() should *not* behave like socketpair() as it encourages 
>FreeBSD developers to write bad code :-(

SVR4 provides bi-directional pipe(2) FD's.  Digital UNIX (aka OSF/1
aka Tru64) seems to support both behaviours.  I suspect the trend will
be for pipe()'s to be bi-directional.  Feel free to add a sysctl to
make pipe's unidirectional.

Peter


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message <199908030624.haa00...@keep.lan.awfulhak.org> Brian Somers writes:
: Exactly - ditto for gethostbyname().  In the case of gethostbyname(), 
: I believe that domain names can't have a number as the first 
: character - I would have thought this idea should follow through with 
: services.

No.  That is in error.  3com.com or 2112.com.  See RFC 1123 for the
loosening of the restriction.  You have to parse the whole string to
know if it is a valid IP address or not anyway.

: I know I'd be pretty annoyed if I tried to do something like ``ssh -p 
: 1234 somewhere'' after configuring my interface in single-user modem 
: with nis in /etc/host.conf and found that ssh was looking up 1234 in 
: /etc/services.  Even if this is right, it's not intuitive.

But inetd isn't involved here at all.  You do bring up a good point
here in argument by analogy.

However your rule for isdigit(arg[0]) breaks the following services:

3com-tsmux  106/tcp
3com-tsmux  106/udp
914c/g  211/tcp#Texas Instruments 914C/G Terminal
914c/g  211/udp#Texas Instruments 914C/G Terminal
9pfs564/tcp#plan 9 file service
9pfs564/udp#plan 9 file service
3l-l1   1511/tcp
3l-l1   1511/udp
3ds-lm  1538/tcp
3ds-lm  1538/udp
3m-image-lm 1550/tcp#Image Storage license manager 3M Company
3m-image-lm 1550/udp#Image Storage license manager 3M Company

at least we know there are no all numeric service names in the
standard /etc/services file.

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Brian Somers]

> In message <199908022217.xaa02...@keep.lan.awfulhak.org> Brian Somers writes:
> : Yes, but do it the other way 'round - strtol first, if it's not all 
> : numeric, getservbyname().
> 
> I did it getservbyname first in case there were any legacy services
> that were all numbers.  Traditionally, this is hwo things were done
> with IP addresses, although a quickie survey shows it to be a mixed
> bag.  The biggest reason for not doing getservbyname first is that it
> will hang (long timeout) if the databsae behind it goes away.

Exactly - ditto for gethostbyname().  In the case of gethostbyname(), 
I believe that domain names can't have a number as the first 
character - I would have thought this idea should follow through with 
services.

I know I'd be pretty annoyed if I tried to do something like ``ssh -p 
1234 somewhere'' after configuring my interface in single-user modem 
with nis in /etc/host.conf and found that ssh was looking up 1234 in 
/etc/services.  Even if this is right, it's not intuitive.

> Warner

-- 
Brian 
     
Don't _EVER_ lose your sense of humour !  




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Brian Somers]

> In some email I received from Brian Somers, sie wrote:
> [.]
> > Yes, but do it the other way 'round - strtol first, if it's not all 
> > numeric, getservbyname().
> 
> No, the patch was correct.

Not in my book - see my other posting :]

-- 
Brian 
     
Don't _EVER_ lose your sense of humour !  




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message <[EMAIL PROTECTED]> Brian Somers writes:
: Exactly - ditto for gethostbyname().  In the case of gethostbyname(), 
: I believe that domain names can't have a number as the first 
: character - I would have thought this idea should follow through with 
: services.

No.  That is in error.  3com.com or 2112.com.  See RFC 1123 for the
loosening of the restriction.  You have to parse the whole string to
know if it is a valid IP address or not anyway.

: I know I'd be pretty annoyed if I tried to do something like ``ssh -p 
: 1234 somewhere'' after configuring my interface in single-user modem 
: with nis in /etc/host.conf and found that ssh was looking up 1234 in 
: /etc/services.  Even if this is right, it's not intuitive.

But inetd isn't involved here at all.  You do bring up a good point
here in argument by analogy.

However your rule for isdigit(arg[0]) breaks the following services:

3com-tsmux  106/tcp
3com-tsmux  106/udp
914c/g  211/tcp#Texas Instruments 914C/G Terminal
914c/g  211/udp#Texas Instruments 914C/G Terminal
9pfs564/tcp#plan 9 file service
9pfs564/udp#plan 9 file service
3l-l1   1511/tcp
3l-l1   1511/udp
3ds-lm  1538/tcp
3ds-lm  1538/udp
3m-image-lm 1550/tcp#Image Storage license manager 3M Company
3m-image-lm 1550/udp#Image Storage license manager 3M Company

at least we know there are no all numeric service names in the
standard /etc/services file.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Brian Somers]

> In some email I received from Brian Somers, sie wrote:
> [.]
> > Yes, but do it the other way 'round - strtol first, if it's not all 
> > numeric, getservbyname().
> 
> No, the patch was correct.

Not in my book - see my other posting :]

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !  <[EMAIL PROTECTED]>




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Brian Somers]

> In message <[EMAIL PROTECTED]> Brian Somers writes:
> : Yes, but do it the other way 'round - strtol first, if it's not all 
> : numeric, getservbyname().
> 
> I did it getservbyname first in case there were any legacy services
> that were all numbers.  Traditionally, this is hwo things were done
> with IP addresses, although a quickie survey shows it to be a mixed
> bag.  The biggest reason for not doing getservbyname first is that it
> will hang (long timeout) if the databsae behind it goes away.

Exactly - ditto for gethostbyname().  In the case of gethostbyname(), 
I believe that domain names can't have a number as the first 
character - I would have thought this idea should follow through with 
services.

I know I'd be pretty annoyed if I tried to do something like ``ssh -p 
1234 somewhere'' after configuring my interface in single-user modem 
with nis in /etc/host.conf and found that ssh was looking up 1234 in 
/etc/services.  Even if this is right, it's not intuitive.

> Warner

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !  <[EMAIL PROTECTED]>




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message <199908022217.xaa02...@keep.lan.awfulhak.org> Brian Somers writes:
: Yes, but do it the other way 'round - strtol first, if it's not all 
: numeric, getservbyname().

I did it getservbyname first in case there were any legacy services
that were all numbers.  Traditionally, this is hwo things were done
with IP addresses, although a quickie survey shows it to be a mixed
bag.  The biggest reason for not doing getservbyname first is that it
will hang (long timeout) if the databsae behind it goes away.

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[David Scheidt]

On Mon, 2 Aug 1999, Brian Somers wrote:


> Yes, but do it the other way 'round - strtol first, if it's not all 
> numeric, getservbyname().

Can't you have all numeric service names?  
>

David scheidt 




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message <[EMAIL PROTECTED]> Brian Somers writes:
: Yes, but do it the other way 'round - strtol first, if it's not all 
: numeric, getservbyname().

I did it getservbyname first in case there were any legacy services
that were all numbers.  Traditionally, this is hwo things were done
with IP addresses, although a quickie survey shows it to be a mixed
bag.  The biggest reason for not doing getservbyname first is that it
will hang (long timeout) if the databsae behind it goes away.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[David Scheidt]

On Mon, 2 Aug 1999, Brian Somers wrote:


> Yes, but do it the other way 'round - strtol first, if it's not all 
> numeric, getservbyname().

Can't you have all numeric service names?  
>

David scheidt 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Brian Somers]

[.]
> @@ -832,15 +833,21 @@
>   if (!sep->se_rpc) {
>   sp = getservbyname(sep->se_service, sep->se_proto);
>   if (sp == 0) {
> + if ((p = strtol(sep->se_service, 
> + (char **NULL), 10))) {
> + sep->se_ctrladdr.sin_port = htons(p);
> + goto numeric_override;
> + }
>   syslog(LOG_ERR, "%s/%s: unknown service",
>   sep->se_service, sep->se_proto);
>   sep->se_checked = 0;
>   continue;
>   }
>   if (sp->s_port != sep->se_ctrladdr.sin_port) {
> + sep->se_ctrladdr.sin_port = sp->s_port;
> +numeric_override:
>   sep->se_ctrladdr.sin_family = AF_INET;
>   sep->se_ctrladdr.sin_addr = bind_address;
> - sep->se_ctrladdr.sin_port = sp->s_port;
>   if (sep->se_fd >= 0)
>   close_sep(sep);
>   }
[.]

Yes, but do it the other way 'round - strtol first, if it's not all 
numeric, getservbyname().
-- 
Brian 
     
Don't _EVER_ lose your sense of humour !  




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Brian Somers]

[.]
> @@ -832,15 +833,21 @@
>   if (!sep->se_rpc) {
>   sp = getservbyname(sep->se_service, sep->se_proto);
>   if (sp == 0) {
> + if ((p = strtol(sep->se_service, 
> + (char **NULL), 10))) {
> + sep->se_ctrladdr.sin_port = htons(p);
> + goto numeric_override;
> + }
>   syslog(LOG_ERR, "%s/%s: unknown service",
>   sep->se_service, sep->se_proto);
>   sep->se_checked = 0;
>   continue;
>   }
>   if (sp->s_port != sep->se_ctrladdr.sin_port) {
> + sep->se_ctrladdr.sin_port = sp->s_port;
> +numeric_override:
>   sep->se_ctrladdr.sin_family = AF_INET;
>   sep->se_ctrladdr.sin_addr = bind_address;
> - sep->se_ctrladdr.sin_port = sp->s_port;
>   if (sep->se_fd >= 0)
>   close_sep(sep);
>   }
[.]

Yes, but do it the other way 'round - strtol first, if it's not all 
numeric, getservbyname().
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !  <[EMAIL PROTECTED]>




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Brian Somers]

dil...@apollo.backplane.com said:
> :The correct way to do this is to fix getservbyname() so it accepts
> :port numbers. : :DES :--  :Dag-Erling Smorgrav - d...@flood.ping.uio.no
> 
> 
> If we were to depend on this, it would break code compatibility with 
> other UNIXes for no good reason.   For example, someone porting inetd
> from FreeBSD to something else would not get a compatible result without
> undoing the 'fix'.
> 
> 'Fixing' getservbyname() is a really bad idea. 

I agree - unless all the BSDs agree, changing this sort of thing is 
just going to disfavour FreeBSD as a development platform.

I've been stung with things like pipe() for exactly the same reasons. 
IMHO, pipe() should *not* behave like socketpair() as it encourages 
FreeBSD developers to write bad code :-(

-- 
Brian 
     
Don't _EVER_ lose your sense of humour !  




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Brian Somers]

[EMAIL PROTECTED] said:
> :The correct way to do this is to fix getservbyname() so it accepts
> :port numbers. : :DES :--  :Dag-Erling Smorgrav - [EMAIL PROTECTED]
> 
> 
> If we were to depend on this, it would break code compatibility with 
> other UNIXes for no good reason.   For example, someone porting inetd
> from FreeBSD to something else would not get a compatible result without
> undoing the 'fix'.
> 
> 'Fixing' getservbyname() is a really bad idea. 

I agree - unless all the BSDs agree, changing this sort of thing is 
just going to disfavour FreeBSD as a development platform.

I've been stung with things like pipe() for exactly the same reasons. 
IMHO, pipe() should *not* behave like socketpair() as it encourages 
FreeBSD developers to write bad code :-(

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !  <[EMAIL PROTECTED]>




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Assar Westerlund]

Warner Losh  writes:
> Or getservbyname (which is really what you'd want to change).  I have
> patches to inetd that I've enclosed here.  They are gorss, but the
> code itself doesn't lend itself to non-gross patches w/o some rework,
> which I was too lazy to do this morning.

Or you might as well fix it for RPCs at the same time.

/assar

--- inetd.c.origMon Aug  2 22:35:28 1999
+++ inetd.c Mon Aug  2 22:41:52 1999
@@ -830,34 +830,50 @@
continue;
}
if (!sep->se_rpc) {
+   int port;
+
sp = getservbyname(sep->se_service, sep->se_proto);
if (sp == 0) {
-   syslog(LOG_ERR, "%s/%s: unknown service",
+   port = htons(strtol (sep->se_service,
+NULL, 0));
+   if (port == 0) {
+   syslog(LOG_ERR,
+  "%s/%s: unknown service",
sep->se_service, sep->se_proto);
sep->se_checked = 0;
continue;
}
-   if (sp->s_port != sep->se_ctrladdr.sin_port) {
+   } else
+   port = sp->s_port;
+   if (port != sep->se_ctrladdr.sin_port) {
sep->se_ctrladdr.sin_family = AF_INET;
sep->se_ctrladdr.sin_addr = bind_address;
-   sep->se_ctrladdr.sin_port = sp->s_port;
+   sep->se_ctrladdr.sin_port = port;
if (sep->se_fd >= 0)
close_sep(sep);
}
} else {
+   int rpc_number;
+
rpc = getrpcbyname(sep->se_service);
if (rpc == 0) {
-   syslog(LOG_ERR, "%s/%s unknown RPC service.",
+   rpc_number = strtol (sep->se_service,
+NULL, 0);
+   if (rpc_number == 0) {
+   syslog(LOG_ERR,
+  "%s/%s unknown RPC service.",
sep->se_service, sep->se_proto);
if (sep->se_fd != -1)
(void) close(sep->se_fd);
sep->se_fd = -1;
continue;
}
-   if (rpc->r_number != sep->se_rpc_prog) {
+   } else
+   rpc_number = sep->se_rpc_prog;
+   if (rpc_number != sep->se_rpc_prog) {
if (sep->se_rpc_prog)
unregisterrpc(sep);
-   sep->se_rpc_prog = rpc->r_number;
+   sep->se_rpc_prog = rpc_number;
if (sep->se_fd != -1)
(void) close(sep->se_fd);
sep->se_fd = -1;


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Assar Westerlund]

Warner Losh <[EMAIL PROTECTED]> writes:
> Or getservbyname (which is really what you'd want to change).  I have
> patches to inetd that I've enclosed here.  They are gorss, but the
> code itself doesn't lend itself to non-gross patches w/o some rework,
> which I was too lazy to do this morning.

Or you might as well fix it for RPCs at the same time.

/assar

--- inetd.c.origMon Aug  2 22:35:28 1999
+++ inetd.c Mon Aug  2 22:41:52 1999
@@ -830,34 +830,50 @@
continue;
}
if (!sep->se_rpc) {
+   int port;
+
sp = getservbyname(sep->se_service, sep->se_proto);
if (sp == 0) {
-   syslog(LOG_ERR, "%s/%s: unknown service",
+   port = htons(strtol (sep->se_service,
+NULL, 0));
+   if (port == 0) {
+   syslog(LOG_ERR,
+  "%s/%s: unknown service",
sep->se_service, sep->se_proto);
sep->se_checked = 0;
continue;
}
-   if (sp->s_port != sep->se_ctrladdr.sin_port) {
+   } else
+   port = sp->s_port;
+   if (port != sep->se_ctrladdr.sin_port) {
sep->se_ctrladdr.sin_family = AF_INET;
sep->se_ctrladdr.sin_addr = bind_address;
-   sep->se_ctrladdr.sin_port = sp->s_port;
+   sep->se_ctrladdr.sin_port = port;
if (sep->se_fd >= 0)
close_sep(sep);
}
} else {
+   int rpc_number;
+
rpc = getrpcbyname(sep->se_service);
if (rpc == 0) {
-   syslog(LOG_ERR, "%s/%s unknown RPC service.",
+   rpc_number = strtol (sep->se_service,
+NULL, 0);
+   if (rpc_number == 0) {
+   syslog(LOG_ERR,
+  "%s/%s unknown RPC service.",
sep->se_service, sep->se_proto);
if (sep->se_fd != -1)
(void) close(sep->se_fd);
sep->se_fd = -1;
continue;
}
-   if (rpc->r_number != sep->se_rpc_prog) {
+   } else
+   rpc_number = sep->se_rpc_prog;
+   if (rpc_number != sep->se_rpc_prog) {
if (sep->se_rpc_prog)
unregisterrpc(sep);
-   sep->se_rpc_prog = rpc->r_number;
+   sep->se_rpc_prog = rpc_number;
if (sep->se_fd != -1)
(void) close(sep->se_fd);
sep->se_fd = -1;


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message <199908021754.daa25...@avalon.reed.wattle.id.au> Darren Reed writes:
: Why not just use the changes NetBSD made to their inetd ~6 years ago ?

Didn't know about them?

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message  Bill 
Fumerola writes:
: I agree. The change should be made in inetd, not in getportbyname()

Or getservbyname (which is really what you'd want to change).  I have
patches to inetd that I've enclosed here.  They are gorss, but the
code itself doesn't lend itself to non-gross patches w/o some rework,
which I was too lazy to do this morning.

Warner

Index: inetd.c
===
RCS file: /home/imp/FreeBSD/CVS/src/usr.sbin/inetd/inetd.c,v
retrieving revision 1.70
diff -u -r1.70 inetd.c
--- inetd.c 1999/07/26 06:39:46 1.70
+++ inetd.c 1999/08/02 17:27:52
@@ -744,6 +744,7 @@
 {
struct servtab *sep, *new, **sepp;
long omask;
+   int p;
 
if (!setconfig()) {
syslog(LOG_ERR, "%s: %m", CONFIG);
@@ -832,15 +833,21 @@
if (!sep->se_rpc) {
sp = getservbyname(sep->se_service, sep->se_proto);
if (sp == 0) {
+   if ((p = strtol(sep->se_service, 
+   (char **NULL), 10))) {
+   sep->se_ctrladdr.sin_port = htons(p);
+   goto numeric_override;
+   }
syslog(LOG_ERR, "%s/%s: unknown service",
sep->se_service, sep->se_proto);
sep->se_checked = 0;
continue;
}
if (sp->s_port != sep->se_ctrladdr.sin_port) {
+   sep->se_ctrladdr.sin_port = sp->s_port;
+numeric_override:
sep->se_ctrladdr.sin_family = AF_INET;
sep->se_ctrladdr.sin_addr = bind_address;
-   sep->se_ctrladdr.sin_port = sp->s_port;
if (sep->se_fd >= 0)
close_sep(sep);
}


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Bill Fumerola]

On Mon, 2 Aug 1999, Warner Losh wrote:

> I don't think we should change getportbyname.  If the getportbyname
> fails, see if a strtol returns a number, and if so use that.  I don't
> see what is so hard about doing that.

I agree. The change should be made in inetd, not in getportbyname()

> If someone wants to run a service on a port that it wasn't desinged
> for, they can still do it today.  I don't see what the argument
> against this change could possibly be.  There is no evil here.

Changing getportbyname() would be, which is what was discussed before.

-- 
- bill fumerola - bi...@chc-chimes.com - BF1560 - computer horizons corp -
- ph:(800) 252-2421 - bfume...@computerhorizons.com - bi...@freebsd.org  -



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message  Bill 
Fumerola writes:
: Copying the telnet line and changing the first word to 'http' does wonders
: for being to access machines from inside a school district's firewall.

What if the service has no name?

: Choosing ports by number would be nice, however the same objections Matt
: had with changing our API ring some buzzers in my head too, however the
: evil side of me says "screw whoever is porting inetd, we like functionality.
: 
: The evil side normally wins.

I don't think we should change getportbyname.  If the getportbyname
fails, see if a strtol returns a number, and if so use that.  I don't
see what is so hard about doing that.

If someone wants to run a service on a port that it wasn't desinged
for, they can still do it today.  I don't see what the argument
against this change could possibly be.  There is no evil here.

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message <[EMAIL PROTECTED]> Darren Reed writes:
: Why not just use the changes NetBSD made to their inetd ~6 years ago ?

Didn't know about them?

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Bill Fumerola]

On Mon, 2 Aug 1999, Warner Losh wrote:

> I say that I don't care if it allows this.  In fact, I want to be able 
> to do things like that...

Copying the telnet line and changing the first word to 'http' does wonders
for being to access machines from inside a school district's firewall.

Choosing ports by number would be nice, however the same objections Matt
had with changing our API ring some buzzers in my head too, however the
evil side of me says "screw whoever is porting inetd, we like functionality.

The evil side normally wins.

-- 
- bill fumerola - bi...@chc-chimes.com - BF1560 - computer horizons corp -
- ph:(800) 252-2421 - bfume...@computerhorizons.com - bi...@freebsd.org  -



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message  Dag-Erling Smorgrav writes:
: Daniel Eischen  writes:
: > Dag-Erling Smorgrav wrote:
: > > The correct way to do this is to fix getservbyname() so it accepts
: > > port numbers.
: > Are you sure this is what you want?

I'm 100% positive that I want this.

: >  It may allow an application to
: > use a port number that would otherwise be invalid.

I think he's saying that you could run telnet on port 25, which is
reserved for mail.

I say that I don't care if it allows this.  In fact, I want to be able 
to do things like that...

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message  Dag-Erling Smorgrav writes:
: Allow me to re-quote the message I answered:
: 
: > I vote for allowing inetd.conf to specify a port number instead of a
: > service name...

I've said it before, and I'll say it again: This is an excellent idea!

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message <[EMAIL PROTECTED]> Bill 
Fumerola writes:
: I agree. The change should be made in inetd, not in getportbyname()

Or getservbyname (which is really what you'd want to change).  I have
patches to inetd that I've enclosed here.  They are gorss, but the
code itself doesn't lend itself to non-gross patches w/o some rework,
which I was too lazy to do this morning.

Warner

Index: inetd.c
===
RCS file: /home/imp/FreeBSD/CVS/src/usr.sbin/inetd/inetd.c,v
retrieving revision 1.70
diff -u -r1.70 inetd.c
--- inetd.c 1999/07/26 06:39:46 1.70
+++ inetd.c 1999/08/02 17:27:52
@@ -744,6 +744,7 @@
 {
struct servtab *sep, *new, **sepp;
long omask;
+   int p;
 
if (!setconfig()) {
syslog(LOG_ERR, "%s: %m", CONFIG);
@@ -832,15 +833,21 @@
if (!sep->se_rpc) {
sp = getservbyname(sep->se_service, sep->se_proto);
if (sp == 0) {
+   if ((p = strtol(sep->se_service, 
+   (char **NULL), 10))) {
+   sep->se_ctrladdr.sin_port = htons(p);
+   goto numeric_override;
+   }
syslog(LOG_ERR, "%s/%s: unknown service",
sep->se_service, sep->se_proto);
sep->se_checked = 0;
continue;
}
if (sp->s_port != sep->se_ctrladdr.sin_port) {
+   sep->se_ctrladdr.sin_port = sp->s_port;
+numeric_override:
sep->se_ctrladdr.sin_family = AF_INET;
sep->se_ctrladdr.sin_addr = bind_address;
-   sep->se_ctrladdr.sin_port = sp->s_port;
if (sep->se_fd >= 0)
close_sep(sep);
}


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Bill Fumerola]

On Mon, 2 Aug 1999, Warner Losh wrote:

> I don't think we should change getportbyname.  If the getportbyname
> fails, see if a strtol returns a number, and if so use that.  I don't
> see what is so hard about doing that.

I agree. The change should be made in inetd, not in getportbyname()

> If someone wants to run a service on a port that it wasn't desinged
> for, they can still do it today.  I don't see what the argument
> against this change could possibly be.  There is no evil here.

Changing getportbyname() would be, which is what was discussed before.

-- 
- bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp -
- ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED]  -



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message <[EMAIL PROTECTED]> Bill 
Fumerola writes:
: Copying the telnet line and changing the first word to 'http' does wonders
: for being to access machines from inside a school district's firewall.

What if the service has no name?

: Choosing ports by number would be nice, however the same objections Matt
: had with changing our API ring some buzzers in my head too, however the
: evil side of me says "screw whoever is porting inetd, we like functionality.
: 
: The evil side normally wins.

I don't think we should change getportbyname.  If the getportbyname
fails, see if a strtol returns a number, and if so use that.  I don't
see what is so hard about doing that.

If someone wants to run a service on a port that it wasn't desinged
for, they can still do it today.  I don't see what the argument
against this change could possibly be.  There is no evil here.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Bill Fumerola]

On Mon, 2 Aug 1999, Warner Losh wrote:

> I say that I don't care if it allows this.  In fact, I want to be able 
> to do things like that...

Copying the telnet line and changing the first word to 'http' does wonders
for being to access machines from inside a school district's firewall.

Choosing ports by number would be nice, however the same objections Matt
had with changing our API ring some buzzers in my head too, however the
evil side of me says "screw whoever is porting inetd, we like functionality.

The evil side normally wins.

-- 
- bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp -
- ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED]  -



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes:
: Daniel Eischen <[EMAIL PROTECTED]> writes:
: > Dag-Erling Smorgrav wrote:
: > > The correct way to do this is to fix getservbyname() so it accepts
: > > port numbers.
: > Are you sure this is what you want?

I'm 100% positive that I want this.

: >  It may allow an application to
: > use a port number that would otherwise be invalid.

I think he's saying that you could run telnet on port 25, which is
reserved for mail.

I say that I don't care if it allows this.  In fact, I want to be able 
to do things like that...

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes:
: Allow me to re-quote the message I answered:
: 
: > I vote for allowing inetd.conf to specify a port number instead of a
: > service name...

I've said it before, and I'll say it again: This is an excellent idea!

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Matthew Dillon]

:John-Mark Gurney  writes:
:> Sheldon Hearn scribbled this message on Aug 1:
:> > Would you need these entries if inetd let you specify port numbers
:> > instead of service names?
:> I vote for allowing inetd.conf to specify a port number instead of a
:> service name...  it should be very easy to make the modification, and
:> I'm willing to do all the work, assuming no one on -committers objects..
:
:The correct way to do this is to fix getservbyname() so it accepts
:port numbers.
:
:DES
:-- 
:Dag-Erling Smorgrav - d...@flood.ping.uio.no

If we were to depend on this, it would break code compatibility with 
other UNIXes for no good reason.   For example, someone porting inetd
from FreeBSD to something else would not get a compatible result without
undoing the 'fix'.

'Fixing' getservbyname() is a really bad idea.

-Matt
Matthew Dillon 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Matthew Dillon]

:John-Mark Gurney <[EMAIL PROTECTED]> writes:
:> Sheldon Hearn scribbled this message on Aug 1:
:> > Would you need these entries if inetd let you specify port numbers
:> > instead of service names?
:> I vote for allowing inetd.conf to specify a port number instead of a
:> service name...  it should be very easy to make the modification, and
:> I'm willing to do all the work, assuming no one on -committers objects..
:
:The correct way to do this is to fix getservbyname() so it accepts
:port numbers.
:
:DES
:-- 
:Dag-Erling Smorgrav - [EMAIL PROTECTED]

If we were to depend on this, it would break code compatibility with 
other UNIXes for no good reason.   For example, someone porting inetd
from FreeBSD to something else would not get a compatible result without
undoing the 'fix'.

'Fixing' getservbyname() is a really bad idea.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Dag-Erling Smorgrav]

Sheldon Hearn  writes:
> If we fix this in inetd, we get what we want. If we fix this in
> getservbyport() we may get something that we don't want, namely
> applications that relay on the existing behaviour of the function stop
> working as intended.

I don't see in what way an application could break if getservbyname()
suddenly accepted numeric port specifications. It won't ``stop working
as intended'', it'll keep on working as it always used to, plus a
little more. It'll also make it a darn sight easier to parse port
specifications e.g. from the command line.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On Mon, 02 Aug 1999 07:30:32 -0400, Daniel Eischen wrote:

> Are you also going to allow getservbyport to lookup names?

And how are you going to squish a name into an int? :-)

Ciao,
Sheldon.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Daniel Eischen]

Daniel Eischen wrote:
> Are you also going to allow getservbyport to lookup names?   

Stupid question.  This isn't possible since getservbyport takes
an int argument.

Dan Eischen
eisc...@vigrid.com


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Daniel Eischen]

Dag-Erling Smorgrav wrote:
> >  It may allow an application to
> > use a port number that would otherwise be invalid.
>
> Please elaborate.

I don't have any specific applications in mind :)  But suppose an
application (for whatever reason) only wants to allow selection of
certain service names.  A user could type in any port number that
was in /etc/services, and the application would use it.

Are you also going to allow getservbyport to lookup names?

Dan Eischen
eisc...@vigrid.com


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On 02 Aug 1999 13:27:44 +0200, Dag-Erling Smorgrav wrote:

> I don't see in what way an application could break if getservbyname()
> suddenly accepted numeric port specifications. It won't ``stop working
> as intended'', it'll keep on working as it always used to, plus a
> little more.

My application limits the port numbers it'll play with based on what's
in /etc/services, since getservbyname() implies this limitation.

Administrators rely on the fact that only root can play with
/etc/services so that this silly application can't play with ports that
aren't in that file.

No getservbyname() doesn't work the way it used to, and the
administrator is shot in the foot, even though he didn't pull the
trigger.

Ciao,
Sheldon.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On Sat, 31 Jul 1999 23:00:15 MST, Doug wrote:

> > Would you need these entries if inetd let you specify port numbers
> > instead of service names?
>
>   Errr... while that may be of value to someone, it has nothing to
> do with the issue Ben and I were discussing.

Yes yes. I'm not trying to contribute to the conversation you're having.
I'm trying to get your opinion on an issue that came up during your
conversation. :-)

Ciao,
Sheldon.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Dag-Erling Smorgrav]

Daniel Eischen  writes:
> Dag-Erling Smorgrav wrote:
> > The correct way to do this is to fix getservbyname() so it accepts
> > port numbers.
> Are you sure this is what you want?

Yes.

>  It may allow an application to
> use a port number that would otherwise be invalid.

Please elaborate.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On 02 Aug 1999 13:19:01 +0200, Dag-Erling Smorgrav wrote:

> > Would this not still require modifications to /etc/services for services
> > not already mentioned in that file?
> 
> Allow me to re-quote the message I answered:
> 
> > I vote for allowing inetd.conf to specify a port number instead of a
> > service name...

I think that's exactly what Daniel's getting at.

If we fix this in inetd, we get what we want. If we fix this in
getservbyport() we may get something that we don't want, namely
applications that relay on the existing behaviour of the function stop
working as intended.

Ciao,
Sheldon.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Dag-Erling Smorgrav]

Sheldon Hearn  writes:
> On 02 Aug 1999 13:05:17 +0200, Dag-Erling Smorgrav wrote:
> > The correct way to do this is to fix getservbyname() so it accepts
> > port numbers.
> Would this not still require modifications to /etc/services for services
> not already mentioned in that file?

Allow me to re-quote the message I answered:

> I vote for allowing inetd.conf to specify a port number instead of a
> service name...

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Daniel Eischen]

Dag-Erling Smorgrav wrote:
> John-Mark Gurney  writes:
> > Sheldon Hearn scribbled this message on Aug 1:
> > > Would you need these entries if inetd let you specify port numbers
> > > instead of service names?
> > I vote for allowing inetd.conf to specify a port number instead of a
> > service name...  it should be very easy to make the modification, and
> > I'm willing to do all the work, assuming no one on -committers objects..
> 
> The correct way to do this is to fix getservbyname() so it accepts
> port numbers.

Are you sure this is what you want?  It may allow an application to
use a port number that would otherwise be invalid.

Dan Eischen
eisc...@vigrid.com


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On 02 Aug 1999 13:05:17 +0200, Dag-Erling Smorgrav wrote:

> The correct way to do this is to fix getservbyname() so it accepts
> port numbers.

Would this not still require modifications to /etc/services for services
not already mentioned in that file?

Ciao,
Sheldon.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Dag-Erling Smorgrav]

Sheldon Hearn <[EMAIL PROTECTED]> writes:
> If we fix this in inetd, we get what we want. If we fix this in
> getservbyport() we may get something that we don't want, namely
> applications that relay on the existing behaviour of the function stop
> working as intended.

I don't see in what way an application could break if getservbyname()
suddenly accepted numeric port specifications. It won't ``stop working
as intended'', it'll keep on working as it always used to, plus a
little more. It'll also make it a darn sight easier to parse port
specifications e.g. from the command line.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Dag-Erling Smorgrav]

John-Mark Gurney  writes:
> Sheldon Hearn scribbled this message on Aug 1:
> > Would you need these entries if inetd let you specify port numbers
> > instead of service names?
> I vote for allowing inetd.conf to specify a port number instead of a
> service name...  it should be very easy to make the modification, and
> I'm willing to do all the work, assuming no one on -committers objects..

The correct way to do this is to fix getservbyname() so it accepts
port numbers.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On Mon, 02 Aug 1999 07:30:32 -0400, Daniel Eischen wrote:

> Are you also going to allow getservbyport to lookup names?

And how are you going to squish a name into an int? :-)

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Daniel Eischen]

Daniel Eischen wrote:
> Are you also going to allow getservbyport to lookup names?   

Stupid question.  This isn't possible since getservbyport takes
an int argument.

Dan Eischen
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Daniel Eischen]

Dag-Erling Smorgrav wrote:
> >  It may allow an application to
> > use a port number that would otherwise be invalid.
>
> Please elaborate.

I don't have any specific applications in mind :)  But suppose an
application (for whatever reason) only wants to allow selection of
certain service names.  A user could type in any port number that
was in /etc/services, and the application would use it.

Are you also going to allow getservbyport to lookup names?

Dan Eischen
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On 02 Aug 1999 13:27:44 +0200, Dag-Erling Smorgrav wrote:

> I don't see in what way an application could break if getservbyname()
> suddenly accepted numeric port specifications. It won't ``stop working
> as intended'', it'll keep on working as it always used to, plus a
> little more.

My application limits the port numbers it'll play with based on what's
in /etc/services, since getservbyname() implies this limitation.

Administrators rely on the fact that only root can play with
/etc/services so that this silly application can't play with ports that
aren't in that file.

No getservbyname() doesn't work the way it used to, and the
administrator is shot in the foot, even though he didn't pull the
trigger.

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On Sat, 31 Jul 1999 23:00:15 MST, Doug wrote:

> > Would you need these entries if inetd let you specify port numbers
> > instead of service names?
>
>   Errr... while that may be of value to someone, it has nothing to
> do with the issue Ben and I were discussing.

Yes yes. I'm not trying to contribute to the conversation you're having.
I'm trying to get your opinion on an issue that came up during your
conversation. :-)

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Dag-Erling Smorgrav]

Daniel Eischen <[EMAIL PROTECTED]> writes:
> Dag-Erling Smorgrav wrote:
> > The correct way to do this is to fix getservbyname() so it accepts
> > port numbers.
> Are you sure this is what you want?

Yes.

>  It may allow an application to
> use a port number that would otherwise be invalid.

Please elaborate.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On 02 Aug 1999 13:19:01 +0200, Dag-Erling Smorgrav wrote:

> > Would this not still require modifications to /etc/services for services
> > not already mentioned in that file?
> 
> Allow me to re-quote the message I answered:
> 
> > I vote for allowing inetd.conf to specify a port number instead of a
> > service name...

I think that's exactly what Daniel's getting at.

If we fix this in inetd, we get what we want. If we fix this in
getservbyport() we may get something that we don't want, namely
applications that relay on the existing behaviour of the function stop
working as intended.

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Dag-Erling Smorgrav]

Sheldon Hearn <[EMAIL PROTECTED]> writes:
> On 02 Aug 1999 13:05:17 +0200, Dag-Erling Smorgrav wrote:
> > The correct way to do this is to fix getservbyname() so it accepts
> > port numbers.
> Would this not still require modifications to /etc/services for services
> not already mentioned in that file?

Allow me to re-quote the message I answered:

> I vote for allowing inetd.conf to specify a port number instead of a
> service name...

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Daniel Eischen]

Dag-Erling Smorgrav wrote:
> John-Mark Gurney <[EMAIL PROTECTED]> writes:
> > Sheldon Hearn scribbled this message on Aug 1:
> > > Would you need these entries if inetd let you specify port numbers
> > > instead of service names?
> > I vote for allowing inetd.conf to specify a port number instead of a
> > service name...  it should be very easy to make the modification, and
> > I'm willing to do all the work, assuming no one on -committers objects..
> 
> The correct way to do this is to fix getservbyname() so it accepts
> port numbers.

Are you sure this is what you want?  It may allow an application to
use a port number that would otherwise be invalid.

Dan Eischen
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On 02 Aug 1999 13:05:17 +0200, Dag-Erling Smorgrav wrote:

> The correct way to do this is to fix getservbyname() so it accepts
> port numbers.

Would this not still require modifications to /etc/services for services
not already mentioned in that file?

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Dag-Erling Smorgrav]

John-Mark Gurney <[EMAIL PROTECTED]> writes:
> Sheldon Hearn scribbled this message on Aug 1:
> > Would you need these entries if inetd let you specify port numbers
> > instead of service names?
> I vote for allowing inetd.conf to specify a port number instead of a
> service name...  it should be very easy to make the modification, and
> I'm willing to do all the work, assuming no one on -committers objects..

The correct way to do this is to fix getservbyname() so it accepts
port numbers.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message <19990731161854.11...@hydrogen.fircrest.net> John-Mark Gurney writes:
: I vote for allowing inetd.conf to specify a port number instead of a
: service name...  it should be very easy to make the modification, and
: I'm willing to do all the work, assuming no one on -committers objects..

I'd love to be able to do this.  I have a firewall-like machine that I
run services on several different that have no real names...  I'm
hacking /etc/services now, which is just wrong...

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message <[EMAIL PROTECTED]> John-Mark Gurney writes:
: I vote for allowing inetd.conf to specify a port number instead of a
: service name...  it should be very easy to make the modification, and
: I'm willing to do all the work, assuming no one on -committers objects..

I'd love to be able to do this.  I have a firewall-like machine that I
run services on several different that have no real names...  I'm
hacking /etc/services now, which is just wrong...

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Jon Hamilton]

In message <37a3e944.7f28e...@gorean.org>, Doug wrote:
} Jon Hamilton wrote:
} 
} > No.  ipfw deals with /etc/services only at startup time (any other behavior
}  on
} > its part would be ridiculous).
} 
}   That's not entirely true, there are other situations (like adding a rul
} e,
} etc.) but your point is well taken. And no, I can't provide specific
} examples, my point is really much simpler than that. 
}  
} > I think you're  overestimating the cost by a considerable amount.  I'm
} > not saying that the cost is zero, but I am saying that it's close enough
} > that the value of having the information *right there* outweighs the cost.
} 
}   Anyone interested in the information will stay interested long enough t
} o
} look it up in a man page. Even if the cost to the system is very very
} small, I think that adding it to the file is silly when it could just as
} easily be added to a man page. 

It's not "just as easy" for the person looking for the information; it
doesn't *get* any easier than having it right there alongside the place
you're going to use it.  Just because in principle someone can go look
up the information somewhere else, doesn't mean that it's not easier and
more friendly to [also?] have the information right there in the file.

}   Of course, there are other benefits to having it in a man page too. The
} primary one being that changes/updates to the comments don't require a
} change to the file, and would be picked up automatically during a make
} world. 

That is true, but then again this data doesn't change that often.

-- 
   Jon Hamilton  
   hamil...@pobox.com



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Doug]

Jon Hamilton wrote:

> No.  ipfw deals with /etc/services only at startup time (any other behavior on
> its part would be ridiculous).

That's not entirely true, there are other situations (like adding a 
rule,
etc.) but your point is well taken. And no, I can't provide specific
examples, my point is really much simpler than that. 
 
> I think you're  overestimating the cost by a considerable amount.  I'm
> not saying that the cost is zero, but I am saying that it's close enough
> that the value of having the information *right there* outweighs the cost.

Anyone interested in the information will stay interested long enough to
look it up in a man page. Even if the cost to the system is very very
small, I think that adding it to the file is silly when it could just as
easily be added to a man page. 

Of course, there are other benefits to having it in a man page too. The
primary one being that changes/updates to the comments don't require a
change to the file, and would be picked up automatically during a make
world. 

Now you'll have to excuse me while I go sharpen my lance...

Doug


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Jon Hamilton]

In message <37a3e203.de0fe...@gorean.org>, Doug wrote:
} Sheldon Hearn wrote:
} > 
} > On Fri, 30 Jul 1999 15:05:14 MST, Doug wrote:
} > 
} > >   I still haven't heard anyone answer the two key (IMO) questions.
} > 
} > Your questions are easier answered in reverse order:
} > 
} > > and how do you justify the additional cost to parse the file for every
} > > single system call that uses it?
} > 
} > The information is part of the comments within the file. The cost is in
} > disk space, and it's cheaper than fleabites.
} 
}   Nowhere did I mention disk space. I agree that if that were the only is
} sue
} I wouldn't be raising the objection. 
} 
} > > Why is it better to have this in the file than in a man page,
} > 
} > Since it costs nothing to have it in /etc/services, why not leave it
} > there along with the information with which it's associated? The
} > alternative is to have a manpage that contains most of the information
} > in /etc/services!
} 
}   And why is that bad? Since when is redundancy in the documentation a
} problem? Like you said, disk is cheap. 
}  
} > > My only concern is that putting it IN the file has more costs than
} > > benefits.
} > 
} > What am I missing here, that I don't see a cost? What software scans the
} > lines in /etc/services beyond the comment delimiter, other than null
} > terminator searches?
} 
}   So, how many comments are you going to add? Let's say the total parsing
} cost to the system for all of your additions is X. X is probably a pretty
} small number, I'm not arguing that point at all. Now multiply X times every
} packet on a highly loaded server, because that's how many times ipfw is
} going to need to parse the file (roughly). 

No.  ipfw deals with /etc/services only at startup time (any other behavior on 
its part would be ridiculous).

}   My point is simply that the information is valuable, but it belongs in 
} a
} man page. There is no reason to add a good deal of non-functional
} information to a file that is used by so many parts of the system. 

I think you're  overestimating the cost by a considerable amount.  I'm 
not saying that the cost is zero, but I am saying that it's close enough 
that the value of having the information *right there* outweighs the cost.
Can you demonstrate a realistic scenario in which multiplying the volume
of comments in /etc/services by, say, 10x results in a perceptible 
performance hit?

-- 
   Jon Hamilton  
   hamil...@pobox.com



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Doug]

Sheldon Hearn wrote:
> 
> On Fri, 30 Jul 1999 15:10:18 MST, Doug wrote:
> 
> > On some of the machines I administer I have some custom entries for
> > /etc/services that make more sense than the defaults, especially for
> > the ports > 1023.
> 
> Would you need these entries if inetd let you specify port numbers
> instead of service names?

Errr... while that may be of value to someone, it has nothing to do with
the issue Ben and I were discussing. 

Doug


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Doug]

Sheldon Hearn wrote:
> 
> On Fri, 30 Jul 1999 15:05:14 MST, Doug wrote:
> 
> >   I still haven't heard anyone answer the two key (IMO) questions.
> 
> Your questions are easier answered in reverse order:
> 
> > and how do you justify the additional cost to parse the file for every
> > single system call that uses it?
> 
> The information is part of the comments within the file. The cost is in
> disk space, and it's cheaper than fleabites.

Nowhere did I mention disk space. I agree that if that were the only 
issue
I wouldn't be raising the objection. 

> > Why is it better to have this in the file than in a man page,
> 
> Since it costs nothing to have it in /etc/services, why not leave it
> there along with the information with which it's associated? The
> alternative is to have a manpage that contains most of the information
> in /etc/services!

And why is that bad? Since when is redundancy in the documentation a
problem? Like you said, disk is cheap. 
 
> > My only concern is that putting it IN the file has more costs than
> > benefits.
> 
> What am I missing here, that I don't see a cost? What software scans the
> lines in /etc/services beyond the comment delimiter, other than null
> terminator searches?

So, how many comments are you going to add? Let's say the total parsing
cost to the system for all of your additions is X. X is probably a pretty
small number, I'm not arguing that point at all. Now multiply X times every
packet on a highly loaded server, because that's how many times ipfw is
going to need to parse the file (roughly). 

My point is simply that the information is valuable, but it belongs in a
man page. There is no reason to add a good deal of non-functional
information to a file that is used by so many parts of the system. 

Doug


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Jon Hamilton]

In message <[EMAIL PROTECTED]>, Doug wrote:
} Jon Hamilton wrote:
} 
} > No.  ipfw deals with /etc/services only at startup time (any other behavior
}  on
} > its part would be ridiculous).
} 
}   That's not entirely true, there are other situations (like adding a rul
} e,
} etc.) but your point is well taken. And no, I can't provide specific
} examples, my point is really much simpler than that. 
}  
} > I think you're  overestimating the cost by a considerable amount.  I'm
} > not saying that the cost is zero, but I am saying that it's close enough
} > that the value of having the information *right there* outweighs the cost.
} 
}   Anyone interested in the information will stay interested long enough t
} o
} look it up in a man page. Even if the cost to the system is very very
} small, I think that adding it to the file is silly when it could just as
} easily be added to a man page. 

It's not "just as easy" for the person looking for the information; it
doesn't *get* any easier than having it right there alongside the place
you're going to use it.  Just because in principle someone can go look
up the information somewhere else, doesn't mean that it's not easier and
more friendly to [also?] have the information right there in the file.

}   Of course, there are other benefits to having it in a man page too. The
} primary one being that changes/updates to the comments don't require a
} change to the file, and would be picked up automatically during a make
} world. 

That is true, but then again this data doesn't change that often.

-- 
   Jon Hamilton  
   [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Doug]

Jon Hamilton wrote:

> No.  ipfw deals with /etc/services only at startup time (any other behavior on
> its part would be ridiculous).

That's not entirely true, there are other situations (like adding a rule,
etc.) but your point is well taken. And no, I can't provide specific
examples, my point is really much simpler than that. 
 
> I think you're  overestimating the cost by a considerable amount.  I'm
> not saying that the cost is zero, but I am saying that it's close enough
> that the value of having the information *right there* outweighs the cost.

Anyone interested in the information will stay interested long enough to
look it up in a man page. Even if the cost to the system is very very
small, I think that adding it to the file is silly when it could just as
easily be added to a man page. 

Of course, there are other benefits to having it in a man page too. The
primary one being that changes/updates to the comments don't require a
change to the file, and would be picked up automatically during a make
world. 

Now you'll have to excuse me while I go sharpen my lance...

Doug


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Jon Hamilton]

In message <[EMAIL PROTECTED]>, Doug wrote:
} Sheldon Hearn wrote:
} > 
} > On Fri, 30 Jul 1999 15:05:14 MST, Doug wrote:
} > 
} > >   I still haven't heard anyone answer the two key (IMO) questions.
} > 
} > Your questions are easier answered in reverse order:
} > 
} > > and how do you justify the additional cost to parse the file for every
} > > single system call that uses it?
} > 
} > The information is part of the comments within the file. The cost is in
} > disk space, and it's cheaper than fleabites.
} 
}   Nowhere did I mention disk space. I agree that if that were the only is
} sue
} I wouldn't be raising the objection. 
} 
} > > Why is it better to have this in the file than in a man page,
} > 
} > Since it costs nothing to have it in /etc/services, why not leave it
} > there along with the information with which it's associated? The
} > alternative is to have a manpage that contains most of the information
} > in /etc/services!
} 
}   And why is that bad? Since when is redundancy in the documentation a
} problem? Like you said, disk is cheap. 
}  
} > > My only concern is that putting it IN the file has more costs than
} > > benefits.
} > 
} > What am I missing here, that I don't see a cost? What software scans the
} > lines in /etc/services beyond the comment delimiter, other than null
} > terminator searches?
} 
}   So, how many comments are you going to add? Let's say the total parsing
} cost to the system for all of your additions is X. X is probably a pretty
} small number, I'm not arguing that point at all. Now multiply X times every
} packet on a highly loaded server, because that's how many times ipfw is
} going to need to parse the file (roughly). 

No.  ipfw deals with /etc/services only at startup time (any other behavior on 
its part would be ridiculous).

}   My point is simply that the information is valuable, but it belongs in 
} a
} man page. There is no reason to add a good deal of non-functional
} information to a file that is used by so many parts of the system. 

I think you're  overestimating the cost by a considerable amount.  I'm 
not saying that the cost is zero, but I am saying that it's close enough 
that the value of having the information *right there* outweighs the cost.
Can you demonstrate a realistic scenario in which multiplying the volume
of comments in /etc/services by, say, 10x results in a perceptible 
performance hit?

-- 
   Jon Hamilton  
   [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Doug]

Sheldon Hearn wrote:
> 
> On Fri, 30 Jul 1999 15:10:18 MST, Doug wrote:
> 
> > On some of the machines I administer I have some custom entries for
> > /etc/services that make more sense than the defaults, especially for
> > the ports > 1023.
> 
> Would you need these entries if inetd let you specify port numbers
> instead of service names?

Errr... while that may be of value to someone, it has nothing to do with
the issue Ben and I were discussing. 

Doug


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Doug]

Sheldon Hearn wrote:
> 
> On Fri, 30 Jul 1999 15:05:14 MST, Doug wrote:
> 
> >   I still haven't heard anyone answer the two key (IMO) questions.
> 
> Your questions are easier answered in reverse order:
> 
> > and how do you justify the additional cost to parse the file for every
> > single system call that uses it?
> 
> The information is part of the comments within the file. The cost is in
> disk space, and it's cheaper than fleabites.

Nowhere did I mention disk space. I agree that if that were the only issue
I wouldn't be raising the objection. 

> > Why is it better to have this in the file than in a man page,
> 
> Since it costs nothing to have it in /etc/services, why not leave it
> there along with the information with which it's associated? The
> alternative is to have a manpage that contains most of the information
> in /etc/services!

And why is that bad? Since when is redundancy in the documentation a
problem? Like you said, disk is cheap. 
 
> > My only concern is that putting it IN the file has more costs than
> > benefits.
> 
> What am I missing here, that I don't see a cost? What software scans the
> lines in /etc/services beyond the comment delimiter, other than null
> terminator searches?

So, how many comments are you going to add? Let's say the total parsing
cost to the system for all of your additions is X. X is probably a pretty
small number, I'm not arguing that point at all. Now multiply X times every
packet on a highly loaded server, because that's how many times ipfw is
going to need to parse the file (roughly). 

My point is simply that the information is valuable, but it belongs in a
man page. There is no reason to add a good deal of non-functional
information to a file that is used by so many parts of the system. 

Doug


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[John-Mark Gurney]

Sheldon Hearn scribbled this message on Aug 1:
> Would you need these entries if inetd let you specify port numbers
> instead of service names?

I vote for allowing inetd.conf to specify a port number instead of a
service name...  it should be very easy to make the modification, and
I'm willing to do all the work, assuming no one on -committers objects..

-- 
  John-Mark Gurney  Voice: +1 541 684 8449
  Cu Networking   P.O. Box 5693, 97405

  "The soul contains in itself the event that shall presently befall it.
  The event is only the actualizing of its thought." -- Ralph Waldo Emerson


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[John-Mark Gurney]

Sheldon Hearn scribbled this message on Aug 1:
> Would you need these entries if inetd let you specify port numbers
> instead of service names?

I vote for allowing inetd.conf to specify a port number instead of a
service name...  it should be very easy to make the modification, and
I'm willing to do all the work, assuming no one on -committers objects..

-- 
  John-Mark Gurney  Voice: +1 541 684 8449
  Cu Networking   P.O. Box 5693, 97405

  "The soul contains in itself the event that shall presently befall it.
  The event is only the actualizing of its thought." -- Ralph Waldo Emerson


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On Fri, 30 Jul 1999 15:10:18 MST, Doug wrote:

> On some of the machines I administer I have some custom entries for
> /etc/services that make more sense than the defaults, especially for
> the ports > 1023.

Would you need these entries if inetd let you specify port numbers
instead of service names?

That behaviour is a function of laziness, rather than principle.  If I'm
correct in my suspicion that most people only meddle with /etc/services
to appease inetd's harvest of sown laziness, then the effort required to
change the current behaviour will be worthwhile.

Ciao,
Sheldon.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On Fri, 30 Jul 1999 15:10:18 MST, Doug wrote:

> On some of the machines I administer I have some custom entries for
> /etc/services that make more sense than the defaults, especially for
> the ports > 1023.

Would you need these entries if inetd let you specify port numbers
instead of service names?

That behaviour is a function of laziness, rather than principle.  If I'm
correct in my suspicion that most people only meddle with /etc/services
to appease inetd's harvest of sown laziness, then the effort required to
change the current behaviour will be worthwhile.

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On Fri, 30 Jul 1999 15:05:14 MST, Doug wrote:

>   I still haven't heard anyone answer the two key (IMO) questions.

Your questions are easier answered in reverse order:

> and how do you justify the additional cost to parse the file for every
> single system call that uses it?

The information is part of the comments within the file. The cost is in
disk space, and it's cheaper than fleabites.

> Why is it better to have this in the file than in a man page,

Since it costs nothing to have it in /etc/services, why not leave it
there along with the information with which it's associated? The
alternative is to have a manpage that contains most of the information
in /etc/services!

> My only concern is that putting it IN the file has more costs than
> benefits.

What am I missing here, that I don't see a cost? What software scans the
lines in /etc/services beyond the comment delimiter, other than null
terminator searches?

So far, I've had some great advice on this issue (although I think it's
time the thread took a long walk off a short pier), so I definitely have
my ears open. I'm just having trouble either understanding or believing
what I'm hearing. :-)

Ciao,
Sheldon.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On Fri, 30 Jul 1999 15:05:14 MST, Doug wrote:

>   I still haven't heard anyone answer the two key (IMO) questions.

Your questions are easier answered in reverse order:

> and how do you justify the additional cost to parse the file for every
> single system call that uses it?

The information is part of the comments within the file. The cost is in
disk space, and it's cheaper than fleabites.

> Why is it better to have this in the file than in a man page,

Since it costs nothing to have it in /etc/services, why not leave it
there along with the information with which it's associated? The
alternative is to have a manpage that contains most of the information
in /etc/services!

> My only concern is that putting it IN the file has more costs than
> benefits.

What am I missing here, that I don't see a cost? What software scans the
lines in /etc/services beyond the comment delimiter, other than null
terminator searches?

So far, I've had some great advice on this issue (although I think it's
time the thread took a long walk off a short pier), so I definitely have
my ears open. I'm just having trouble either understanding or believing
what I'm hearing. :-)

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Ben Rosengart]

On Fri, 30 Jul 1999, Doug wrote:

>   The -n option to trafshow disables number->name translation for
> both addresses and ports, although that might be more than what is wanted.
> I do know what you mean though. On some of the machines I administer I
> have some custom entries for /etc/services that make more sense than the
> defaults, especially for the ports > 1023.

Yeah, it's not that I don't want to see the service names, it's just
that I want to see the accurate ones and not the inaccurate ones.  As
you implied, that often means the ones below port 1024 and not the
others.

--
 Ben

UNIX Systems Engineer, Skunk Group
StarMedia Network, Inc.



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Doug]

On Thu, 29 Jul 1999, Ben Rosengart wrote:

> On Thu, 29 Jul 1999, Josef Karthauser wrote:
> 
> > Ok - but it's a bit misleading having both values in /etc/services..
> > 
> > Shouldn't be:
> > http 80/tcpwww www-http #World Wide Web HTTP
> > http 80/udpwww www-http #World Wide Web HTTP
> > 
> > Should be:
> > http 80/tcpwww www-http #World Wide Web HTTP
> > http 80/udp #[not used]
> > 
> > Don't you think?  At least that way you don't have to read all of the
> > rfcs to construct a firewall ;).
> 
> And the output of netstat (trafshow, etc.) would be considerably easier to
> read.

The -n option to trafshow disables number->name translation for
both addresses and ports, although that might be more than what is wanted.
I do know what you mean though. On some of the machines I administer I
have some custom entries for /etc/services that make more sense than the
defaults, especially for the ports > 1023.

Doug
-- 
On account of being a democracy and run by the people, we are the only
nation in the world that has to keep a government four years, no matter
what it does.
-- Will Rogers



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Doug]

On Wed, 28 Jul 1999, Matthew Dillon wrote:

> :> Sheldon Hearn  writes:
> :> > I plan to mention in the comments for each service in /etc/services, the
> :> > latest RFC describing the service.
> :> 
> :> Good idea.
> :
> : H... I'm not sure what this gets us. Wouldn't it be better to
> :place this kind of information in the man page that you suggest below? As
> :often as /etc/services gets read, do we really want to bloat it with
> :non-functional information?
> :...
> :Doug
> 
> I kinda like the idea of putting the RFC numbers in comments in 
> /etc/services.  It makes the comments more meaningful.

I still haven't heard anyone answer the two key (IMO) questions.
Why is it better to have this in the file than in a man page, and how do
you justify the additional cost to parse the file for every single system
call that uses it? Please note that I _do_ think that the information is
valuable. My only concern is that putting it IN the file has more costs
than benefits. 

> It would be nice if we DBM'd /etc/services.  

Well that would definitely solve the problem of the "cost" of
comments that I mention above, and it could also be handy in the sense
that you could build an error-checker into the dbm'ing process. However
this raises additional questions, like how to deal with the situation
where the file is updated but the db is not. Thinking in mergemaster
terms, I already have to special case master.passwd for this reason, and
probably should special case login.conf too (just made myself a note). 

Doug
-- 
On account of being a democracy and run by the people, we are the only
nation in the world that has to keep a government four years, no matter
what it does.
-- Will Rogers



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Ben Rosengart]

On Fri, 30 Jul 1999, Doug wrote:

>   The -n option to trafshow disables number->name translation for
> both addresses and ports, although that might be more than what is wanted.
> I do know what you mean though. On some of the machines I administer I
> have some custom entries for /etc/services that make more sense than the
> defaults, especially for the ports > 1023.

Yeah, it's not that I don't want to see the service names, it's just
that I want to see the accurate ones and not the inaccurate ones.  As
you implied, that often means the ones below port 1024 and not the
others.

--
 Ben

UNIX Systems Engineer, Skunk Group
StarMedia Network, Inc.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Doug]

On Thu, 29 Jul 1999, Ben Rosengart wrote:

> On Thu, 29 Jul 1999, Josef Karthauser wrote:
> 
> > Ok - but it's a bit misleading having both values in /etc/services..
> > 
> > Shouldn't be:
> > http 80/tcpwww www-http #World Wide Web HTTP
> > http 80/udpwww www-http #World Wide Web HTTP
> > 
> > Should be:
> > http 80/tcpwww www-http #World Wide Web HTTP
> > http 80/udp #[not used]
> > 
> > Don't you think?  At least that way you don't have to read all of the
> > rfcs to construct a firewall ;).
> 
> And the output of netstat (trafshow, etc.) would be considerably easier to
> read.

The -n option to trafshow disables number->name translation for
both addresses and ports, although that might be more than what is wanted.
I do know what you mean though. On some of the machines I administer I
have some custom entries for /etc/services that make more sense than the
defaults, especially for the ports > 1023.

Doug
-- 
On account of being a democracy and run by the people, we are the only
nation in the world that has to keep a government four years, no matter
what it does.
-- Will Rogers



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Doug]

On Wed, 28 Jul 1999, Matthew Dillon wrote:

> :> Sheldon Hearn <[EMAIL PROTECTED]> writes:
> :> > I plan to mention in the comments for each service in /etc/services, the
> :> > latest RFC describing the service.
> :> 
> :> Good idea.
> :
> : H... I'm not sure what this gets us. Wouldn't it be better to
> :place this kind of information in the man page that you suggest below? As
> :often as /etc/services gets read, do we really want to bloat it with
> :non-functional information?
> :...
> :Doug
> 
> I kinda like the idea of putting the RFC numbers in comments in 
> /etc/services.  It makes the comments more meaningful.

I still haven't heard anyone answer the two key (IMO) questions.
Why is it better to have this in the file than in a man page, and how do
you justify the additional cost to parse the file for every single system
call that uses it? Please note that I _do_ think that the information is
valuable. My only concern is that putting it IN the file has more costs
than benefits. 

> It would be nice if we DBM'd /etc/services.  

Well that would definitely solve the problem of the "cost" of
comments that I mention above, and it could also be handy in the sense
that you could build an error-checker into the dbm'ing process. However
this raises additional questions, like how to deal with the situation
where the file is updated but the db is not. Thinking in mergemaster
terms, I already have to special case master.passwd for this reason, and
probably should special case login.conf too (just made myself a note). 

Doug
-- 
On account of being a democracy and run by the people, we are the only
nation in the world that has to keep a government four years, no matter
what it does.
-- Will Rogers



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Ben Rosengart]

On Thu, 29 Jul 1999, Josef Karthauser wrote:

> Ok - but it's a bit misleading having both values in /etc/services..
> 
> Shouldn't be:
> http 80/tcpwww www-http #World Wide Web HTTP
> http 80/udpwww www-http #World Wide Web HTTP
> 
> Should be:
> http 80/tcpwww www-http #World Wide Web HTTP
> http 80/udp   #[not used]
> 
> Don't you think?  At least that way you don't have to read all of the
> rfcs to construct a firewall ;).

And the output of netstat (trafshow, etc.) would be considerably easier to
read.

--
 Ben

UNIX Systems Engineer, Skunk Group
StarMedia Network, Inc.



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Ben Rosengart]

On Thu, 29 Jul 1999, Josef Karthauser wrote:

> Ok - but it's a bit misleading having both values in /etc/services..
> 
> Shouldn't be:
> http 80/tcpwww www-http #World Wide Web HTTP
> http 80/udpwww www-http #World Wide Web HTTP
> 
> Should be:
> http 80/tcpwww www-http #World Wide Web HTTP
> http 80/udp   #[not used]
> 
> Don't you think?  At least that way you don't have to read all of the
> rfcs to construct a firewall ;).

And the output of netstat (trafshow, etc.) would be considerably easier to
read.

--
 Ben

UNIX Systems Engineer, Skunk Group
StarMedia Network, Inc.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Doug]

Josef Karthauser wrote:

> Ok - but it's a bit misleading having both values in /etc/services..
> 
> Shouldn't be:
> http 80/tcpwww www-http #World Wide Web HTTP
> http 80/udpwww www-http #World Wide Web HTTP
> 
> Should be:
> http 80/tcpwww www-http #World Wide Web HTTP
> http 80/udp #[not used]
> 
> Don't you think?  At least that way you don't have to read all of the
> rfcs to construct a firewall ;).

You should probably add them both anyway, but that's beside the point. 
I'm
not sure if adding comments like that would be worth it, however I tend to
think that it is better to just leave it as is since that way if something
changes in the future, we're already set. Also, "not used" might lead
someone to believe that they could use that UDP port for their own little
project. I suggested that we add the link to the IANA page way back when,
but there are still some people that believe that our services list
contains all the information they need. 

Doug


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Josef Karthauser]

On Thu, Jul 29, 1999 at 12:11:39PM -0700, Doug wrote:
> Dominic Mitchell wrote:
> > 
> > On Thu, Jul 29, 1999 at 09:04:20AM +0100, Josef Karthauser wrote:
> > > A question that always baffled me (I'm fairly easy to baffle) is why we've
> > > got some numbers defined as both udp and tcp when the service type is only
> > > one or the other. Does anyone know?
> > 
> > Probably because the IANA specifies them that way.  I think that they
> > try to keep both UDP and TCP ports the same, "just in case".  There
> > might be a better explanation in rfc1700 (assigned numbers)
> 
>   Nope, that is the official reason. Cheesy-poofs for you. :)

Ok - but it's a bit misleading having both values in /etc/services..

Shouldn't be:
http 80/tcpwww www-http #World Wide Web HTTP
http 80/udpwww www-http #World Wide Web HTTP

Should be:
http 80/tcpwww www-http #World Wide Web HTTP
http 80/udp #[not used]

Don't you think?  At least that way you don't have to read all of the
rfcs to construct a firewall ;).

Joe
-- 
Josef KarthauserFreeBSD: How many times have you booted today?
Technical Manager   Viagra for your server (http://www.uk.freebsd.org)
Pavilion Internet plc.  [...@pavilion.net, j...@uk.freebsd.org, j...@tao.org.uk]


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Doug]

Josef Karthauser wrote:

> Ok - but it's a bit misleading having both values in /etc/services..
> 
> Shouldn't be:
> http 80/tcpwww www-http #World Wide Web HTTP
> http 80/udpwww www-http #World Wide Web HTTP
> 
> Should be:
> http 80/tcpwww www-http #World Wide Web HTTP
> http 80/udp #[not used]
> 
> Don't you think?  At least that way you don't have to read all of the
> rfcs to construct a firewall ;).

You should probably add them both anyway, but that's beside the point. I'm
not sure if adding comments like that would be worth it, however I tend to
think that it is better to just leave it as is since that way if something
changes in the future, we're already set. Also, "not used" might lead
someone to believe that they could use that UDP port for their own little
project. I suggested that we add the link to the IANA page way back when,
but there are still some people that believe that our services list
contains all the information they need. 

Doug


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Doug]

Dominic Mitchell wrote:
> 
> On Thu, Jul 29, 1999 at 09:04:20AM +0100, Josef Karthauser wrote:
> > A question that always baffled me (I'm fairly easy to baffle) is why we've
> > got some numbers defined as both udp and tcp when the service type is only
> > one or the other. Does anyone know?
> 
> Probably because the IANA specifies them that way.  I think that they
> try to keep both UDP and TCP ports the same, "just in case".  There
> might be a better explanation in rfc1700 (assigned numbers)

Nope, that is the official reason. Cheesy-poofs for you. :)

Doug


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Josef Karthauser]

On Thu, Jul 29, 1999 at 12:11:39PM -0700, Doug wrote:
> Dominic Mitchell wrote:
> > 
> > On Thu, Jul 29, 1999 at 09:04:20AM +0100, Josef Karthauser wrote:
> > > A question that always baffled me (I'm fairly easy to baffle) is why we've
> > > got some numbers defined as both udp and tcp when the service type is only
> > > one or the other. Does anyone know?
> > 
> > Probably because the IANA specifies them that way.  I think that they
> > try to keep both UDP and TCP ports the same, "just in case".  There
> > might be a better explanation in rfc1700 (assigned numbers)
> 
>   Nope, that is the official reason. Cheesy-poofs for you. :)

Ok - but it's a bit misleading having both values in /etc/services..

Shouldn't be:
http 80/tcpwww www-http #World Wide Web HTTP
http 80/udpwww www-http #World Wide Web HTTP

Should be:
http 80/tcpwww www-http #World Wide Web HTTP
http 80/udp #[not used]

Don't you think?  At least that way you don't have to read all of the
rfcs to construct a firewall ;).

Joe
-- 
Josef KarthauserFreeBSD: How many times have you booted today?
Technical Manager   Viagra for your server (http://www.uk.freebsd.org)
Pavilion Internet plc.  [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Doug]

Dominic Mitchell wrote:
> 
> On Thu, Jul 29, 1999 at 09:04:20AM +0100, Josef Karthauser wrote:
> > A question that always baffled me (I'm fairly easy to baffle) is why we've
> > got some numbers defined as both udp and tcp when the service type is only
> > one or the other. Does anyone know?
> 
> Probably because the IANA specifies them that way.  I think that they
> try to keep both UDP and TCP ports the same, "just in case".  There
> might be a better explanation in rfc1700 (assigned numbers)

Nope, that is the official reason. Cheesy-poofs for you. :)

Doug


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Dominic Mitchell]

On Thu, Jul 29, 1999 at 09:04:20AM +0100, Josef Karthauser wrote:
> A question that always baffled me (I'm fairly easy to baffle) is why we've
> got some numbers defined as both udp and tcp when the service type is only
> one or the other. Does anyone know?

Probably because the IANA specifies them that way.  I think that they
try to keep both UDP and TCP ports the same, "just in case".  There
might be a better explanation in rfc1700 (assigned numbers), or whatever
it's latest edition is.

-- 
Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator

In Mountain View did Larry Wall
Sedately launch a quiet plea:
That DOS, the ancient system, shall
On boxes pleasureless to all
Run Perl though lack they C.
-- 
**
This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they   
are addressed. If you have received this email in error please notify 
the system manager.

This footnote also confirms that this email message has been swept by 
MIMEsweeper for the presence of computer viruses.
**


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On Thu, 29 Jul 1999 09:04:20 +0100, Josef Karthauser wrote:

> A question that always baffled me (I'm fairly easy to baffle) is why
> we've got some numbers defined as both udp and tcp when the service
> type is only one or the other. Does anyone know?

Probably because this question isn't accompanied by a list of offenders.
:-)

By the way, I originally said I'd have this done in a week. I can only
imagine how many of the die-hards giggled in the background, since it
involves quite a bit of reading. And then there are all the useful
suggestions I've received.

Let's leave this alone until I have diffs to show y'all?

Ciao,
Sheldon.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Dominic Mitchell]

On Thu, Jul 29, 1999 at 09:04:20AM +0100, Josef Karthauser wrote:
> A question that always baffled me (I'm fairly easy to baffle) is why we've
> got some numbers defined as both udp and tcp when the service type is only
> one or the other. Does anyone know?

Probably because the IANA specifies them that way.  I think that they
try to keep both UDP and TCP ports the same, "just in case".  There
might be a better explanation in rfc1700 (assigned numbers), or whatever
it's latest edition is.

-- 
Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator

In Mountain View did Larry Wall
Sedately launch a quiet plea:
That DOS, the ancient system, shall
On boxes pleasureless to all
Run Perl though lack they C.
-- 
**
This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they   
are addressed. If you have received this email in error please notify 
the system manager.

This footnote also confirms that this email message has been swept by 
MIMEsweeper for the presence of computer viruses.
**


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On Thu, 29 Jul 1999 09:04:20 +0100, Josef Karthauser wrote:

> A question that always baffled me (I'm fairly easy to baffle) is why
> we've got some numbers defined as both udp and tcp when the service
> type is only one or the other. Does anyone know?

Probably because this question isn't accompanied by a list of offenders.
:-)

By the way, I originally said I'd have this done in a week. I can only
imagine how many of the die-hards giggled in the background, since it
involves quite a bit of reading. And then there are all the useful
suggestions I've received.

Let's leave this alone until I have diffs to show y'all?

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Josef Karthauser]

On Wed, Jul 28, 1999 at 05:59:29PM -0700, Doug wrote:
> On 26 Jul 1999, Dag-Erling Smorgrav wrote:
> 
>   It would also be nice if someone would take another look at
> bringing our /etc/services file more up to date with IANA
> (http://www.isi.edu/in-notes/iana/assignments/port-numbers). I believe
> someone has a PR open on this... :) David O'Brien and I were working on it
> for a while, but we both got busy working on other things. I had a pretty
> good set of scripts going to produce a workable file in services format
> from the IANA list, but what I should really do is write one perl script
> to do it. I fear however that the chance of the file being updated on that
> kind of scale would be very small (it always meets a lot of resistance) so
> I'm not sure it would be worth it. Ideas? Comments?
> 

A question that always baffled me (I'm fairly easy to baffle) is why we've
got some numbers defined as both udp and tcp when the service type is only
one or the other. Does anyone know?

Joe
-- 
Josef KarthauserFreeBSD: How many times have you booted today?
Technical Manager   Viagra for your server (http://www.uk.freebsd.org)
Pavilion Internet plc.  [...@pavilion.net, j...@uk.freebsd.org, j...@tao.org.uk]


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Josef Karthauser]

On Wed, Jul 28, 1999 at 05:59:29PM -0700, Doug wrote:
> On 26 Jul 1999, Dag-Erling Smorgrav wrote:
> 
>   It would also be nice if someone would take another look at
> bringing our /etc/services file more up to date with IANA
> (http://www.isi.edu/in-notes/iana/assignments/port-numbers). I believe
> someone has a PR open on this... :) David O'Brien and I were working on it
> for a while, but we both got busy working on other things. I had a pretty
> good set of scripts going to produce a workable file in services format
> from the IANA list, but what I should really do is write one perl script
> to do it. I fear however that the chance of the file being updated on that
> kind of scale would be very small (it always meets a lot of resistance) so
> I'm not sure it would be worth it. Ideas? Comments?
> 

A question that always baffled me (I'm fairly easy to baffle) is why we've
got some numbers defined as both udp and tcp when the service type is only
one or the other. Does anyone know?

Joe
-- 
Josef KarthauserFreeBSD: How many times have you booted today?
Technical Manager   Viagra for your server (http://www.uk.freebsd.org)
Pavilion Internet plc.  [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Matthew Dillon]

:> Sheldon Hearn  writes:
:> > I plan to mention in the comments for each service in /etc/services, the
:> > latest RFC describing the service.
:> 
:> Good idea.
:
:   H... I'm not sure what this gets us. Wouldn't it be better to
:place this kind of information in the man page that you suggest below? As
:often as /etc/services gets read, do we really want to bloat it with
:non-functional information?
:...
:Doug

I kinda like the idea of putting the RFC numbers in comments in 
/etc/services.  It makes the comments more meaningful.

:   If you really want to improve /etc/services, the first commit
:should be to delete all the extraneous whitespace at the end of the lines.
:
:23$ grep -c ' $' /etc/services
:173
:
:25$ grep -c '^I$' /etc/services
:97 
:...

It would be nice if we DBM'd /etc/services.  /etc/services is 61KB+ now,
I think DBMing it in a manner similar to how some of the other system 
files which are DBM'd would be worthwhile.

-Matt
Matthew Dillon 




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Doug]

On 26 Jul 1999, Dag-Erling Smorgrav wrote:

> Sheldon Hearn  writes:
> > I plan to mention in the comments for each service in /etc/services, the
> > latest RFC describing the service.
> 
> Good idea.

H... I'm not sure what this gets us. Wouldn't it be better to
place this kind of information in the man page that you suggest below? As
often as /etc/services gets read, do we really want to bloat it with
non-functional information?

> Don't. Instead, put it in a separate rfc(7) man page which you refer
> to in the services(5) man page. 

Good suggestions all the way around. I'd also like to throw in
this link, which is the best RFC repository I've seen on the basis of
speed, reliability, and cross-indexing:
http://www.cis.ohio-state.edu/hypertext/information/rfc.html.

If you really want to improve /etc/services, the first commit
should be to delete all the extraneous whitespace at the end of the lines.

23$ grep -c ' $' /etc/services
173

25$ grep -c '^I$' /etc/services
97 

Next it would be nice if we added entries for things in our system
that don't have them. (Hint: what's listening on ports 1022 and 1023?)
Then, someone either needs to fix getserv*() so that they accept port
ranges like 6000-6063/tcp (much preferred) or roll out those port numbers
in /etc/services (yuck). 

It would also be nice if someone would take another look at
bringing our /etc/services file more up to date with IANA
(http://www.isi.edu/in-notes/iana/assignments/port-numbers). I believe
someone has a PR open on this... :) David O'Brien and I were working on it
for a while, but we both got busy working on other things. I had a pretty
good set of scripts going to produce a workable file in services format
from the IANA list, but what I should really do is write one perl script
to do it. I fear however that the chance of the file being updated on that
kind of scale would be very small (it always meets a lot of resistance) so
I'm not sure it would be worth it. Ideas? Comments?

Finally I want to urge a lot of caution to anyone who tampers with
the file. I learned from painful experience that very small errors can
lead to big problems in very unexpected ways. For instance, my ipfw
firewall went totally nutso at one point because I had some comments in
/etc/services in the wrong format back when I was playing around with it.
This is not something to be tampered with lightly.

Doug
-- 
On account of being a democracy and run by the people, we are the only
nation in the world that has to keep a government four years, no matter
what it does.
-- Will Rogers



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Matthew Dillon]

:> Sheldon Hearn <[EMAIL PROTECTED]> writes:
:> > I plan to mention in the comments for each service in /etc/services, the
:> > latest RFC describing the service.
:> 
:> Good idea.
:
:   H... I'm not sure what this gets us. Wouldn't it be better to
:place this kind of information in the man page that you suggest below? As
:often as /etc/services gets read, do we really want to bloat it with
:non-functional information?
:...
:Doug

I kinda like the idea of putting the RFC numbers in comments in 
/etc/services.  It makes the comments more meaningful.

:   If you really want to improve /etc/services, the first commit
:should be to delete all the extraneous whitespace at the end of the lines.
:
:23$ grep -c ' $' /etc/services
:173
:
:25$ grep -c '^I$' /etc/services
:97 
:...

It would be nice if we DBM'd /etc/services.  /etc/services is 61KB+ now,
I think DBMing it in a manner similar to how some of the other system 
files which are DBM'd would be worthwhile.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Mentioning RFC numbers in /etc/services

[Doug]

On 26 Jul 1999, Dag-Erling Smorgrav wrote:

> Sheldon Hearn <[EMAIL PROTECTED]> writes:
> > I plan to mention in the comments for each service in /etc/services, the
> > latest RFC describing the service.
> 
> Good idea.

H... I'm not sure what this gets us. Wouldn't it be better to
place this kind of information in the man page that you suggest below? As
often as /etc/services gets read, do we really want to bloat it with
non-functional information?

> Don't. Instead, put it in a separate rfc(7) man page which you refer
> to in the services(5) man page. 

Good suggestions all the way around. I'd also like to throw in
this link, which is the best RFC repository I've seen on the basis of
speed, reliability, and cross-indexing:
http://www.cis.ohio-state.edu/hypertext/information/rfc.html.

If you really want to improve /etc/services, the first commit
should be to delete all the extraneous whitespace at the end of the lines.

23$ grep -c ' $' /etc/services
173

25$ grep -c '^I$' /etc/services
97 

Next it would be nice if we added entries for things in our system
that don't have them. (Hint: what's listening on ports 1022 and 1023?)
Then, someone either needs to fix getserv*() so that they accept port
ranges like 6000-6063/tcp (much preferred) or roll out those port numbers
in /etc/services (yuck). 

It would also be nice if someone would take another look at
bringing our /etc/services file more up to date with IANA
(http://www.isi.edu/in-notes/iana/assignments/port-numbers). I believe
someone has a PR open on this... :) David O'Brien and I were working on it
for a while, but we both got busy working on other things. I had a pretty
good set of scripts going to produce a workable file in services format
from the IANA list, but what I should really do is write one perl script
to do it. I fear however that the chance of the file being updated on that
kind of scale would be very small (it always meets a lot of resistance) so
I'm not sure it would be worth it. Ideas? Comments?

Finally I want to urge a lot of caution to anyone who tampers with
the file. I learned from painful experience that very small errors can
lead to big problems in very unexpected ways. For instance, my ipfw
firewall went totally nutso at one point because I had some comments in
/etc/services in the wrong format back when I was playing around with it.
This is not something to be tampered with lightly.

Doug
-- 
On account of being a democracy and run by the people, we are the only
nation in the world that has to keep a government four years, no matter
what it does.
-- Will Rogers



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message