From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Thu, 2 Jan 2003 04:47:02 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 1 ************************************************** Wednesday 01 January 2003 Number 1 ************************************************** Subjects for today 1 shadow-4.0.3 passwords : Ted Sikora 2 shadow-4.0.3 passwords : Ted Sikora 3 Re: shadow-4.0.3 passwords : Ted Sikora 4 Re: shadow-4.0.3 passwords : Ted Sikora 5 Re: shadow-4.0.3 passwords : John Poltorak 6 Re: shadow-4.0.3 passwords : John Poltorak 7 Re: PASSWD handling : Nicholas Sheppard 8 Re: PASSWD handling : Nicholas Sheppard 9 DHCP : John Poltorak 10 DHCP : John Poltorak 11 Re: PASSWD handling : Lyn St George" 12 Re: PASSWD handling : Lyn St George" 13 Re: PASSWD handling : John Poltorak 14 Re: PASSWD handling : John Poltorak 15 Re: GCC 3.0.3 : Jeff Robinson 16 Re: GCC 3.0.3 : Jeff Robinson 17 Re: bootpd : John Poltorak 18 Re: bootpd : John Poltorak 19 GCC 3.0.3 : Ted Sikora 20 GCC 3.0.3 : Ted Sikora 21 nmap : John Poltorak 22 nmap : John Poltorak 23 INETD & BOOTPD : John Poltorak 24 INETD & BOOTPD : John Poltorak 25 Re: GCC 3.0.3 : xyzyx" 26 Re: GCC 3.0.3 : xyzyx" 27 Re: IMDB ApplyDiff 2.5 : xyzyx" 28 Re: IMDB ApplyDiff 2.5 : xyzyx" 29 Re: PASSWD handling : John Poltorak 30 Re: PASSWD handling : John Poltorak 31 Re: nmap : Adrian Gschwend" 32 Re: nmap : Adrian Gschwend" 33 Re: PASSWD handling : Holger Veit 34 Re: PASSWD handling : Holger Veit 35 Re: shadow-4.0.3 passwords : Thomas Hoffmann 36 Re: shadow-4.0.3 passwords : Thomas Hoffmann 37 Re: GCC 3.0.3 : Ted Sikora 38 Re: GCC 3.0.3 : Ted Sikora **= Email 1 ==========================** Date: Thu, 02 Jan 2003 00:16:07 -0500 From: Ted Sikora Subject: shadow-4.0.3 passwords This is a multi-part message in MIME format. --------------020104080709060102020005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I made some headway building the shadow(useradd, passwd, etc.) package for OS/2. After copying the posix/2-alpha3 /includes to my emx/includes it was like a different beast. Configured like most unices and started building nicely. It stopped in succession at these 8 problems. I managed to fudge my way through it all then finally stopping after building the libs. If we can clean up these 8 areas I'm sure it will build. -- Ted Sikora tsikora at ntplx.net --------------020104080709060102020005 Content-Type: text/plain; name="parse.error" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="parse.error" ** FIRST ERROR ** --------------------------- depmode=gcc /bin/sh ../depcomp \ /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -O2 -Wall -c -o log.lo `test -f log.c || echo './'`log.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -O2 -Wall -c log.c -Wp,-MD,.deps/ log.TPlo -o log.o log.c:93: parse error make.exe[2]: *** [log.lo] Error 1 make.exe[2]: Leaving directory `/tmp/libmisc' make.exe[1]: *** [all-recursive] Error 1 make.exe[1]: Leaving directory `/tmp' make: *** [all] Error 2 1) ------------------------------------------------- log.c:93 #if HAVE_LL_HOST strncpy(newlog.ll_host, host, sizeof newlog.ll_host); ------------------------------------------------- 2) ------------------------------------------------- rlogin.c termio.c_oflag |= OPOST|ONLCR; ------------------------------------------------- 3) --------------------------------------------------- #else /* !SVR4 */ void setutmp(const char *name, const char *line) { struct utmp utmp; int fd; int found = 0; --------------------------------------------------- 4) --------------------------------------------------- utmp.c if ((fd = open(_UTMP_FILE, O_RDWR)) < 0) return; ---------------------------------------------------- 5) ---------------------------------------------------- commonio.c #ifdef HAVE_FCHOWN if (fchown(fileno(fp), sb->st_uid, sb->st_gid)) goto fail; ----------------------------------------------------- 6) ----------------------------------------------------- groupio.c #ifdef HAVE_FCHOWN if (fchown(fileno(fp), sb->st_uid, sb->st_gid)) goto fail; ----------------------------------------------------- 7) ----------------------------------------------------- sgetgrent.c grent.gr_passwd = grpfields[1]; ----------------------------------------------------- 8) ----------------------------------------------------- utent.c if ((utmp_fd = open (_UTMP_FILE, O_RDWR)) == -1) ----------------------------------------------------- *** FINAL OUTCOME *** libs built ------------------------- depmode=gcc /bin/sh ../depcomp \ gcc -D_HAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I. -I. -I.. -I.. -I../li b -I../libmisc -O2 -Wall -c `test -f groups.c || echo './'`groups.c /bin/sh ../libtool --mode=link gcc -O2 -Wall -s -o groups.exe groups.o ../lib misc/libmisc.la ../lib/libshadow.la -lsocket mkdir .libs gcc -O2 -Wall -s -o groups.exe groups.o ../libmisc/.libs/misc.a ../lib/.libs/sh adow.a -lcrypt D:/tmp/libmisc/.libs/misc.a -lsocket groups.o: Undefined symbol _setgrent referenced from text segment groups.o: Undefined symbol _getgrent referenced from text segment make.exe[2]: *** [groups.exe] Error 1 make.exe[2]: Leaving directory `/tmp/src' make.exe[1]: *** [all-recursive] Error 1 make.exe[1]: Leaving directory `/tmp' make: *** [all] Error 2 **= Email 2 ==========================** Date: Thu, 02 Jan 2003 00:16:07 -0500 From: Ted Sikora Subject: shadow-4.0.3 passwords This is a multi-part message in MIME format. --------------020104080709060102020005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I made some headway building the shadow(useradd, passwd, etc.) package for OS/2. After copying the posix/2-alpha3 /includes to my emx/includes it was like a different beast. Configured like most unices and started building nicely. It stopped in succession at these 8 problems. I managed to fudge my way through it all then finally stopping after building the libs. If we can clean up these 8 areas I'm sure it will build. -- Ted Sikora tsikora at ntplx.net --------------020104080709060102020005 Content-Type: text/plain; name="parse.error" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="parse.error" ** FIRST ERROR ** --------------------------- depmode=gcc /bin/sh ../depcomp \ /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -O2 -Wall -c -o log.lo `test -f log.c || echo './'`log.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -O2 -Wall -c log.c -Wp,-MD,.deps/ log.TPlo -o log.o log.c:93: parse error make.exe[2]: *** [log.lo] Error 1 make.exe[2]: Leaving directory `/tmp/libmisc' make.exe[1]: *** [all-recursive] Error 1 make.exe[1]: Leaving directory `/tmp' make: *** [all] Error 2 1) ------------------------------------------------- log.c:93 #if HAVE_LL_HOST strncpy(newlog.ll_host, host, sizeof newlog.ll_host); ------------------------------------------------- 2) ------------------------------------------------- rlogin.c termio.c_oflag |= OPOST|ONLCR; ------------------------------------------------- 3) --------------------------------------------------- #else /* !SVR4 */ void setutmp(const char *name, const char *line) { struct utmp utmp; int fd; int found = 0; --------------------------------------------------- 4) --------------------------------------------------- utmp.c if ((fd = open(_UTMP_FILE, O_RDWR)) < 0) return; ---------------------------------------------------- 5) ---------------------------------------------------- commonio.c #ifdef HAVE_FCHOWN if (fchown(fileno(fp), sb->st_uid, sb->st_gid)) goto fail; ----------------------------------------------------- 6) ----------------------------------------------------- groupio.c #ifdef HAVE_FCHOWN if (fchown(fileno(fp), sb->st_uid, sb->st_gid)) goto fail; ----------------------------------------------------- 7) ----------------------------------------------------- sgetgrent.c grent.gr_passwd = grpfields[1]; ----------------------------------------------------- 8) ----------------------------------------------------- utent.c if ((utmp_fd = open (_UTMP_FILE, O_RDWR)) == -1) ----------------------------------------------------- *** FINAL OUTCOME *** libs built ------------------------- depmode=gcc /bin/sh ../depcomp \ gcc -D_HAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I. -I. -I.. -I.. -I../li b -I../libmisc -O2 -Wall -c `test -f groups.c || echo './'`groups.c /bin/sh ../libtool --mode=link gcc -O2 -Wall -s -o groups.exe groups.o ../lib misc/libmisc.la ../lib/libshadow.la -lsocket mkdir .libs gcc -O2 -Wall -s -o groups.exe groups.o ../libmisc/.libs/misc.a ../lib/.libs/sh adow.a -lcrypt D:/tmp/libmisc/.libs/misc.a -lsocket groups.o: Undefined symbol _setgrent referenced from text segment groups.o: Undefined symbol _getgrent referenced from text segment make.exe[2]: *** [groups.exe] Error 1 make.exe[2]: Leaving directory `/tmp/src' make.exe[1]: *** [all-recursive] Error 1 make.exe[1]: Leaving directory `/tmp' make: *** [all] Error 2 **= Email 3 ==========================** Date: Thu, 02 Jan 2003 00:39:52 -0500 From: Ted Sikora Subject: Re: shadow-4.0.3 passwords This is a multi-part message in MIME format. --------------060701020905000605000602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ted Sikora wrote: > I made some headway building the shadow(useradd, passwd, etc.) package > for OS/2. After copying the posix/2-alpha3 /includes to my emx/includes > it was like a different beast. Configured like most unices and started > building nicely. It stopped in succession at these 8 problems. I managed > to fudge my way through it all then finally stopping after building the > libs. If we can clean up these 8 areas I'm sure it will build. > > -- > Ted Sikora > tsikora at ntplx.net > Actually it's just 'gr_passwd' that needs to be modified in these 2 files. -- Ted Sikora tsikora at ntplx.net --------------060701020905000605000602 Content-Type: text/plain; name="sgetgrent.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sgetgrent.c" /* * Copyright 1990 - 1994, Julianne Frances Haugh * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. Neither the name of Julianne F. Haugh nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY JULIE HAUGH AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL JULIE HAUGH OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ #include #include "rcsid.h" RCSID("$Id: sgetgrent.c,v 1.4 1998/04/02 21:51:45 marekm Exp $") #include #include #include "defines.h" #define NFIELDS 4 /* * list - turn a comma-separated string into an array of (char *)'s * * list() converts the comma-separated list of member names into * an array of character pointers. * * WARNING: I profiled this once with and without strchr() calls * and found that using a register variable and an explicit loop * works best. For large /etc/group files, this is a major win. * * FINALLY added dynamic allocation. Still need to fix sgetsgent(). * --marekm */ static char ** list(char *s) { static char **members = 0; static int size = 0; /* max members + 1 */ int i; char **rbuf; i = 0; for (;;) { /* check if there is room for another pointer (to a group member name, or terminating NULL). */ if (i >= size) { size = i + 100; /* at least: i + 1 */ if (members) { rbuf = realloc(members, size * sizeof(char *)); } else { /* for old (before ANSI C) implementations of realloc() that don't handle NULL properly */ rbuf = malloc(size * sizeof(char *)); } if (!rbuf) { if (members) free(members); members = 0; size = 0; return (char **) 0; } members = rbuf; } if (!s || s[0] == '\0') break; members[i++] = s; while (*s && *s != ',') s++; if (*s) *s++ = '\0'; } members[i] = (char *) 0; return members; } struct group * sgetgrent(const char *buf) { static char *grpbuf = 0; static size_t size = 0; static char *grpfields[NFIELDS]; static struct group grent; int i; char *cp; if (strlen(buf) + 1 > size) { /* no need to use realloc() here - just free it and allocate a larger block */ if (grpbuf) free(grpbuf); size = strlen(buf) + 1000; /* at least: strlen(buf) + 1 */ grpbuf = malloc(size); if (!grpbuf) { size = 0; return 0; } } strcpy(grpbuf, buf); if ((cp = strrchr(grpbuf, '\n'))) *cp = '\0'; for (cp = grpbuf, i = 0; i < NFIELDS && cp; i++) { grpfields[i] = cp; if ((cp = strchr(cp, ':'))) *cp++ = 0; } if (i < (NFIELDS-1) || *grpfields[2] == '\0') return 0; grent.gr_name = grpfields[0]; grent.gr_passwd = grpfields[1]; grent.gr_gid = atoi(grpfields[2]); grent.gr_mem = list(grpfields[3]); if (!grent.gr_mem) return (struct group *) 0; /* out of memory */ return &grent; } --------------060701020905000605000602 Content-Type: text/plain; name="groupio.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="groupio.c" #include #include "rcsid.h" RCSID("$Id: groupio.c,v 1.10 2001/08/14 21:10:36 malekith Exp $") #include "prototypes.h" #include "defines.h" #include "commonio.h" #include "groupio.h" extern int putgrent(const struct group *, FILE *); extern struct group *sgetgrent(const char *); struct group * __gr_dup(const struct group *grent) { struct group *gr; int i; if (!(gr = (struct group *) malloc(sizeof *gr))) return NULL; *gr = *grent; if (!(gr->gr_name = strdup(grent->gr_name))) return NULL; if (!(gr->gr_passwd = strdup(grent->gr_passwd))) return NULL; for (i = 0; grent->gr_mem[i]; i++) ; gr->gr_mem = (char **) malloc((i + 1) * sizeof(char *)); if (!gr->gr_mem) return NULL; for (i = 0; grent->gr_mem[i]; i++) { gr->gr_mem[i] = strdup(grent->gr_mem[i]); if (!gr->gr_mem[i]) return NULL; } gr->gr_mem[i] = NULL; return gr; } static void * group_dup(const void *ent) { const struct group *gr = ent; return __gr_dup(gr); } static void group_free(void *ent) { struct group *gr = ent; free(gr->gr_name); free(gr->gr_passwd); while(*(gr->gr_mem)) { free(*(gr->gr_mem)); gr->gr_mem++; } free(gr); } static const char * group_getname(const void *ent) { const struct group *gr = ent; return gr->gr_name; } static void * group_parse(const char *line) { return (void *) sgetgrent(line); } static int group_put(const void *ent, FILE *file) { const struct group *gr = ent; return (putgrent(gr, file) == -1) ? -1 : 0; } static struct commonio_ops group_ops = { group_dup, group_free, group_getname, group_parse, group_put, fgetsx, fputsx }; static struct commonio_db group_db = { GROUP_FILE, /* filename */ &group_ops, /* ops */ NULL, /* fp */ NULL, /* head */ NULL, /* tail */ NULL, /* cursor */ 0, /* changed */ 0, /* isopen */ 0, /* locked */ 0 /* readonly */ }; int gr_name(const char *filename) { return commonio_setname(&group_db, filename); } int gr_lock(void) { return commonio_lock(&group_db); } int gr_open(int mode) { return commonio_open(&group_db, mode); } const struct group * gr_locate(const char *name) { return commonio_locate(&group_db, name); } int gr_update(const struct group *gr) { return commonio_update(&group_db, (const void *) gr); } int gr_remove(const char *name) { return commonio_remove(&group_db, name); } int gr_rewind(void) { return commonio_rewind(&group_db); } const struct group * gr_next(void) { return commonio_next(&group_db); } int gr_close(void) { return commonio_close(&group_db); } int gr_unlock(void) { return commonio_unlock(&group_db); } void __gr_set_changed(void) { group_db.changed = 1; } struct commonio_entry * __gr_get_head(void) { return group_db.head; } struct commonio_db * __gr_get_db(void) { return &group_db; } void __gr_del_entry(const struct commonio_entry *ent) { commonio_del_entry(&group_db, ent); } static int gr_cmp(const void *p1, const void *p2) { gid_t u1, u2; if ((*(struct commonio_entry**)p1)->eptr == NULL) return 1; if ((*(struct commonio_entry**)p2)->eptr == NULL) return -1; u1 = ((struct group *)(*(struct commonio_entry**)p1)->eptr)->gr_gid; u2 = ((struct group *)(*(struct commonio_entry**)p2)->eptr)->gr_gid; if (u1 < u2) return -1; else if (u1 > u2) return 1; else return 0; } /* Sort entries by gid */ int gr_sort() { return commonio_sort(&group_db, gr_cmp); } --------------060701020905000605000602-- **= Email 4 ==========================** Date: Thu, 02 Jan 2003 00:39:52 -0500 From: Ted Sikora Subject: Re: shadow-4.0.3 passwords This is a multi-part message in MIME format. --------------060701020905000605000602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ted Sikora wrote: > I made some headway building the shadow(useradd, passwd, etc.) package > for OS/2. After copying the posix/2-alpha3 /includes to my emx/includes > it was like a different beast. Configured like most unices and started > building nicely. It stopped in succession at these 8 problems. I managed > to fudge my way through it all then finally stopping after building the > libs. If we can clean up these 8 areas I'm sure it will build. > > -- > Ted Sikora > tsikora at ntplx.net > Actually it's just 'gr_passwd' that needs to be modified in these 2 files. -- Ted Sikora tsikora at ntplx.net --------------060701020905000605000602 Content-Type: text/plain; name="sgetgrent.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sgetgrent.c" /* * Copyright 1990 - 1994, Julianne Frances Haugh * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. Neither the name of Julianne F. Haugh nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY JULIE HAUGH AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL JULIE HAUGH OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ #include #include "rcsid.h" RCSID("$Id: sgetgrent.c,v 1.4 1998/04/02 21:51:45 marekm Exp $") #include #include #include "defines.h" #define NFIELDS 4 /* * list - turn a comma-separated string into an array of (char *)'s * * list() converts the comma-separated list of member names into * an array of character pointers. * * WARNING: I profiled this once with and without strchr() calls * and found that using a register variable and an explicit loop * works best. For large /etc/group files, this is a major win. * * FINALLY added dynamic allocation. Still need to fix sgetsgent(). * --marekm */ static char ** list(char *s) { static char **members = 0; static int size = 0; /* max members + 1 */ int i; char **rbuf; i = 0; for (;;) { /* check if there is room for another pointer (to a group member name, or terminating NULL). */ if (i >= size) { size = i + 100; /* at least: i + 1 */ if (members) { rbuf = realloc(members, size * sizeof(char *)); } else { /* for old (before ANSI C) implementations of realloc() that don't handle NULL properly */ rbuf = malloc(size * sizeof(char *)); } if (!rbuf) { if (members) free(members); members = 0; size = 0; return (char **) 0; } members = rbuf; } if (!s || s[0] == '\0') break; members[i++] = s; while (*s && *s != ',') s++; if (*s) *s++ = '\0'; } members[i] = (char *) 0; return members; } struct group * sgetgrent(const char *buf) { static char *grpbuf = 0; static size_t size = 0; static char *grpfields[NFIELDS]; static struct group grent; int i; char *cp; if (strlen(buf) + 1 > size) { /* no need to use realloc() here - just free it and allocate a larger block */ if (grpbuf) free(grpbuf); size = strlen(buf) + 1000; /* at least: strlen(buf) + 1 */ grpbuf = malloc(size); if (!grpbuf) { size = 0; return 0; } } strcpy(grpbuf, buf); if ((cp = strrchr(grpbuf, '\n'))) *cp = '\0'; for (cp = grpbuf, i = 0; i < NFIELDS && cp; i++) { grpfields[i] = cp; if ((cp = strchr(cp, ':'))) *cp++ = 0; } if (i < (NFIELDS-1) || *grpfields[2] == '\0') return 0; grent.gr_name = grpfields[0]; grent.gr_passwd = grpfields[1]; grent.gr_gid = atoi(grpfields[2]); grent.gr_mem = list(grpfields[3]); if (!grent.gr_mem) return (struct group *) 0; /* out of memory */ return &grent; } --------------060701020905000605000602 Content-Type: text/plain; name="groupio.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="groupio.c" #include #include "rcsid.h" RCSID("$Id: groupio.c,v 1.10 2001/08/14 21:10:36 malekith Exp $") #include "prototypes.h" #include "defines.h" #include "commonio.h" #include "groupio.h" extern int putgrent(const struct group *, FILE *); extern struct group *sgetgrent(const char *); struct group * __gr_dup(const struct group *grent) { struct group *gr; int i; if (!(gr = (struct group *) malloc(sizeof *gr))) return NULL; *gr = *grent; if (!(gr->gr_name = strdup(grent->gr_name))) return NULL; if (!(gr->gr_passwd = strdup(grent->gr_passwd))) return NULL; for (i = 0; grent->gr_mem[i]; i++) ; gr->gr_mem = (char **) malloc((i + 1) * sizeof(char *)); if (!gr->gr_mem) return NULL; for (i = 0; grent->gr_mem[i]; i++) { gr->gr_mem[i] = strdup(grent->gr_mem[i]); if (!gr->gr_mem[i]) return NULL; } gr->gr_mem[i] = NULL; return gr; } static void * group_dup(const void *ent) { const struct group *gr = ent; return __gr_dup(gr); } static void group_free(void *ent) { struct group *gr = ent; free(gr->gr_name); free(gr->gr_passwd); while(*(gr->gr_mem)) { free(*(gr->gr_mem)); gr->gr_mem++; } free(gr); } static const char * group_getname(const void *ent) { const struct group *gr = ent; return gr->gr_name; } static void * group_parse(const char *line) { return (void *) sgetgrent(line); } static int group_put(const void *ent, FILE *file) { const struct group *gr = ent; return (putgrent(gr, file) == -1) ? -1 : 0; } static struct commonio_ops group_ops = { group_dup, group_free, group_getname, group_parse, group_put, fgetsx, fputsx }; static struct commonio_db group_db = { GROUP_FILE, /* filename */ &group_ops, /* ops */ NULL, /* fp */ NULL, /* head */ NULL, /* tail */ NULL, /* cursor */ 0, /* changed */ 0, /* isopen */ 0, /* locked */ 0 /* readonly */ }; int gr_name(const char *filename) { return commonio_setname(&group_db, filename); } int gr_lock(void) { return commonio_lock(&group_db); } int gr_open(int mode) { return commonio_open(&group_db, mode); } const struct group * gr_locate(const char *name) { return commonio_locate(&group_db, name); } int gr_update(const struct group *gr) { return commonio_update(&group_db, (const void *) gr); } int gr_remove(const char *name) { return commonio_remove(&group_db, name); } int gr_rewind(void) { return commonio_rewind(&group_db); } const struct group * gr_next(void) { return commonio_next(&group_db); } int gr_close(void) { return commonio_close(&group_db); } int gr_unlock(void) { return commonio_unlock(&group_db); } void __gr_set_changed(void) { group_db.changed = 1; } struct commonio_entry * __gr_get_head(void) { return group_db.head; } struct commonio_db * __gr_get_db(void) { return &group_db; } void __gr_del_entry(const struct commonio_entry *ent) { commonio_del_entry(&group_db, ent); } static int gr_cmp(const void *p1, const void *p2) { gid_t u1, u2; if ((*(struct commonio_entry**)p1)->eptr == NULL) return 1; if ((*(struct commonio_entry**)p2)->eptr == NULL) return -1; u1 = ((struct group *)(*(struct commonio_entry**)p1)->eptr)->gr_gid; u2 = ((struct group *)(*(struct commonio_entry**)p2)->eptr)->gr_gid; if (u1 < u2) return -1; else if (u1 > u2) return 1; else return 0; } /* Sort entries by gid */ int gr_sort() { return commonio_sort(&group_db, gr_cmp); } --------------060701020905000605000602-- **= Email 5 ==========================** Date: Thu, 2 Jan 2003 10:00:04 +0000 From: John Poltorak Subject: Re: shadow-4.0.3 passwords On Thu, Jan 02, 2003 at 12:16:07AM -0500, Ted Sikora wrote: > I made some headway building the shadow(useradd, passwd, etc.) package > for OS/2. After copying the posix/2-alpha3 /includes to my emx/includes > it was like a different beast. I'd like to incorporate the Posix/2 headers into a standard build environment. Does anyone know if the file on Hobbes has the latest version of the headers, or has more work been done on them since the upload to Hobbes? > -- > Ted Sikora > tsikora at ntplx.net -- John **= Email 6 ==========================** Date: Thu, 2 Jan 2003 10:00:04 +0000 From: John Poltorak Subject: Re: shadow-4.0.3 passwords On Thu, Jan 02, 2003 at 12:16:07AM -0500, Ted Sikora wrote: > I made some headway building the shadow(useradd, passwd, etc.) package > for OS/2. After copying the posix/2-alpha3 /includes to my emx/includes > it was like a different beast. I'd like to incorporate the Posix/2 headers into a standard build environment. Does anyone know if the file on Hobbes has the latest version of the headers, or has more work been done on them since the upload to Hobbes? > -- > Ted Sikora > tsikora at ntplx.net -- John **= Email 7 ==========================** Date: Thu, 2 Jan 2003 10:15:35 +1100 (EST) From: Nicholas Sheppard Subject: Re: PASSWD handling On Wed, 1 Jan 2003, Jeff Robinson wrote: > What may be an interesting exercise is well would be to check what > Cygwin( http://www.cygwin.com/ ) has done with their programs to access > password files, just to see if they have come up with a solution that > can be directly adapted. The Cygwin stuff would presumably run into > some of the same problems we have, such as drive letters so might offer > an implementation to look at. The passwd file in my Cygwin installation does not have drive letters in it; all files in Cygwin are assumed to be beneath some Cygwin root directory which is invisible to applications. I believe UnixOS/2 has a similar notion with UNIXROOT or some such thing? To access files outside the Cygwin hierarchy, Cygwin has special directories /cygdrive/c, /cygdrive/d, etc. that map to the usual Windows drive letters, similar to the solution suggested by Holger. For the sake of a passwd file, I would be happy to use the /cygdrive solution. It eliminates the need for special characters and it seems to work fine under Cygwin. But I'm not sure about the implicit root directory stuff because I want my applications to behave as an OS/2 user would expect them to. Nicholas S. **= Email 8 ==========================** Date: Thu, 2 Jan 2003 10:15:35 +1100 (EST) From: Nicholas Sheppard Subject: Re: PASSWD handling On Wed, 1 Jan 2003, Jeff Robinson wrote: > What may be an interesting exercise is well would be to check what > Cygwin( http://www.cygwin.com/ ) has done with their programs to access > password files, just to see if they have come up with a solution that > can be directly adapted. The Cygwin stuff would presumably run into > some of the same problems we have, such as drive letters so might offer > an implementation to look at. The passwd file in my Cygwin installation does not have drive letters in it; all files in Cygwin are assumed to be beneath some Cygwin root directory which is invisible to applications. I believe UnixOS/2 has a similar notion with UNIXROOT or some such thing? To access files outside the Cygwin hierarchy, Cygwin has special directories /cygdrive/c, /cygdrive/d, etc. that map to the usual Windows drive letters, similar to the solution suggested by Holger. For the sake of a passwd file, I would be happy to use the /cygdrive solution. It eliminates the need for special characters and it seems to work fine under Cygwin. But I'm not sure about the implicit root directory stuff because I want my applications to behave as an OS/2 user would expect them to. Nicholas S. **= Email 9 ==========================** Date: Thu, 2 Jan 2003 11:15:21 +0000 From: John Poltorak Subject: DHCP According to ISC, DHCP should be easily made to work on POSIX-compliant OS's as well as non-POSIX systems like Windows and MacOS. I guess that must include OS/2 in there :-)... Just how POSIX-compliant is OS/2? Has anyone tried to build the latest DHCP? I don't want to be dependent on IBM for apps like this in future. -- John **= Email 10 ==========================** Date: Thu, 2 Jan 2003 11:15:21 +0000 From: John Poltorak Subject: DHCP According to ISC, DHCP should be easily made to work on POSIX-compliant OS's as well as non-POSIX systems like Windows and MacOS. I guess that must include OS/2 in there :-)... Just how POSIX-compliant is OS/2? Has anyone tried to build the latest DHCP? I don't want to be dependent on IBM for apps like this in future. -- John **= Email 11 ==========================** Date: Thu, 02 Jan 2003 11:45:11 +0000 From: "Lyn St George" Subject: Re: PASSWD handling On Wed, 01 Jan 2003 18:57:55 -0500, Ted Sikora wrote: >Yup! I don't define a drive letter anymore in builds. --with-path=/zope >or --with-python=/apps/python/python.exe Everything seems to run >smoother too. I build with bash then try to run solely with cmd or make >wrappers for #!/bin/sh scripts in the bin. Without the letter defined >you can put it on any drive. I see some ports like Perl for instance has >the drive o: defined as an env variable because it was built on o:\ It's true that you may run it on any drive, but, at least with Perl and its at INC system, you cannot call it from a drive other than the one it's running on. So there is still a problem ... - Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 12 ==========================** Date: Thu, 02 Jan 2003 11:45:11 +0000 From: "Lyn St George" Subject: Re: PASSWD handling On Wed, 01 Jan 2003 18:57:55 -0500, Ted Sikora wrote: >Yup! I don't define a drive letter anymore in builds. --with-path=/zope >or --with-python=/apps/python/python.exe Everything seems to run >smoother too. I build with bash then try to run solely with cmd or make >wrappers for #!/bin/sh scripts in the bin. Without the letter defined >you can put it on any drive. I see some ports like Perl for instance has >the drive o: defined as an env variable because it was built on o:\ It's true that you may run it on any drive, but, at least with Perl and its at INC system, you cannot call it from a drive other than the one it's running on. So there is still a problem ... - Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 13 ==========================** Date: Thu, 2 Jan 2003 12:21:37 +0000 From: John Poltorak Subject: Re: PASSWD handling On Wed, Jan 01, 2003 at 06:57:55PM -0500, Ted Sikora wrote: > Nicholas Sheppard wrote: > > On Wed, 1 Jan 2003, Jeff Robinson wrote: > > > > > >>What may be an interesting exercise is well would be to check what > >>Cygwin( http://www.cygwin.com/ ) has done with their programs to access > >>password files, just to see if they have come up with a solution that > >>can be directly adapted. The Cygwin stuff would presumably run into > >>some of the same problems we have, such as drive letters so might offer > >>an implementation to look at. > > > > > > The passwd file in my Cygwin installation does not have drive letters in > > it; all files in Cygwin are assumed to be beneath some Cygwin root > > directory which is invisible to applications. I believe UnixOS/2 has a > > similar notion with UNIXROOT or some such thing? > > Yup! I don't define a drive letter anymore in builds. --with-path=/zope > or --with-python=/apps/python/python.exe Everything seems to run > smoother too. I build with bash then try to run solely with cmd or make > wrappers for #!/bin/sh scripts in the bin. Without the letter defined > you can put it on any drive. I see some ports like Perl for instance has > the drive o: defined as an env variable because it was built on o:\ Many Unix programs have hard coded paths in them and if you run such a program where the path does not have a drive letter and you are on the wrong drive, you are likely to have a problem. This is one of the reason we often need to define so many variables on OS/2 whereas they are not needed on Unix. > -- > Ted Sikora > tsikora at ntplx.net -- John **= Email 14 ==========================** Date: Thu, 2 Jan 2003 12:21:37 +0000 From: John Poltorak Subject: Re: PASSWD handling On Wed, Jan 01, 2003 at 06:57:55PM -0500, Ted Sikora wrote: > Nicholas Sheppard wrote: > > On Wed, 1 Jan 2003, Jeff Robinson wrote: > > > > > >>What may be an interesting exercise is well would be to check what > >>Cygwin( http://www.cygwin.com/ ) has done with their programs to access > >>password files, just to see if they have come up with a solution that > >>can be directly adapted. The Cygwin stuff would presumably run into > >>some of the same problems we have, such as drive letters so might offer > >>an implementation to look at. > > > > > > The passwd file in my Cygwin installation does not have drive letters in > > it; all files in Cygwin are assumed to be beneath some Cygwin root > > directory which is invisible to applications. I believe UnixOS/2 has a > > similar notion with UNIXROOT or some such thing? > > Yup! I don't define a drive letter anymore in builds. --with-path=/zope > or --with-python=/apps/python/python.exe Everything seems to run > smoother too. I build with bash then try to run solely with cmd or make > wrappers for #!/bin/sh scripts in the bin. Without the letter defined > you can put it on any drive. I see some ports like Perl for instance has > the drive o: defined as an env variable because it was built on o:\ Many Unix programs have hard coded paths in them and if you run such a program where the path does not have a drive letter and you are on the wrong drive, you are likely to have a problem. This is one of the reason we often need to define so many variables on OS/2 whereas they are not needed on Unix. > -- > Ted Sikora > tsikora at ntplx.net -- John **= Email 15 ==========================** Date: Thu, 02 Jan 2003 17:10:05 -0600 From: Jeff Robinson Subject: Re: GCC 3.0.3 Ted Sikora wrote: > Anyone using it? I tried running it with the newgcc.cmd. Configure can't > find gcc with it. Are there any env setup README's for gcc 3.0.3 anywhere? > > -- > Ted Sikora > tsikora at ntplx.net > > This article on OS/2 eZine comes in very handy: GCC 3.0.2 - Installation, Usage and Tips ( http://www.os2ezine.com/20011216/page_4.html ). I've been using gcc 3.0.3 on-and-off for a while now, and I believe that it has been successfully used to compile Mozilla to run under EMX, too. Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 16 ==========================** Date: Thu, 02 Jan 2003 17:10:05 -0600 From: Jeff Robinson Subject: Re: GCC 3.0.3 Ted Sikora wrote: > Anyone using it? I tried running it with the newgcc.cmd. Configure can't > find gcc with it. Are there any env setup README's for gcc 3.0.3 anywhere? > > -- > Ted Sikora > tsikora at ntplx.net > > This article on OS/2 eZine comes in very handy: GCC 3.0.2 - Installation, Usage and Tips ( http://www.os2ezine.com/20011216/page_4.html ). I've been using gcc 3.0.3 on-and-off for a while now, and I believe that it has been successfully used to compile Mozilla to run under EMX, too. Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 17 ==========================** Date: Thu, 2 Jan 2003 17:28:46 +0000 From: John Poltorak Subject: Re: bootpd On Tue, Dec 31, 2002 at 05:32:16PM +0000, John Poltorak wrote: > > > What is the latest version of bootpd and where does it come from? In case anyone is interested bootpd has not been maintained since 1995 and the most recent release can be found here:- ftp://ftp.ntplx.net/pub/networking/bootp/bootp-DD2.4.3.tar.gz Is there any simple way to convert the supplied Makefile into one which would work correctly on OS/2? I realise that there is an OS/2 port of this from KUR, I was just interested in trying to build and install it without making unnecessary changes. -- John **= Email 18 ==========================** Date: Thu, 2 Jan 2003 17:28:46 +0000 From: John Poltorak Subject: Re: bootpd On Tue, Dec 31, 2002 at 05:32:16PM +0000, John Poltorak wrote: > > > What is the latest version of bootpd and where does it come from? In case anyone is interested bootpd has not been maintained since 1995 and the most recent release can be found here:- ftp://ftp.ntplx.net/pub/networking/bootp/bootp-DD2.4.3.tar.gz Is there any simple way to convert the supplied Makefile into one which would work correctly on OS/2? I realise that there is an OS/2 port of this from KUR, I was just interested in trying to build and install it without making unnecessary changes. -- John **= Email 19 ==========================** Date: Thu, 02 Jan 2003 18:09:49 -0500 From: Ted Sikora Subject: GCC 3.0.3 Anyone using it? I tried running it with the newgcc.cmd. Configure can't find gcc with it. Are there any env setup README's for gcc 3.0.3 anywhere? -- Ted Sikora tsikora at ntplx.net **= Email 20 ==========================** Date: Thu, 02 Jan 2003 18:09:49 -0500 From: Ted Sikora Subject: GCC 3.0.3 Anyone using it? I tried running it with the newgcc.cmd. Configure can't find gcc with it. Are there any env setup README's for gcc 3.0.3 anywhere? -- Ted Sikora tsikora at ntplx.net **= Email 21 ==========================** Date: Thu, 2 Jan 2003 18:38:01 +0000 From: John Poltorak Subject: nmap Has anyone attempted to port nmap to OS/2? -- John **= Email 22 ==========================** Date: Thu, 2 Jan 2003 18:38:01 +0000 From: John Poltorak Subject: nmap Has anyone attempted to port nmap to OS/2? -- John **= Email 23 ==========================** Date: Thu, 2 Jan 2003 19:11:27 +0000 From: John Poltorak Subject: INETD & BOOTPD Ifanyone is familiar with how INETD launches other servers could you check BOOTPD for OS/2:- ? http://hobbes.nmsu.edu/pub/os2/util/network/tcpip/bootpd.zip This is described as a 'quick and dirty' port and no mention is made about its ability to run from INETD, and if it can, how it can pick up a socket. I'm trying to convert from hard coded IP addresses on my own network to getting them from a server at bootup which means I need to run BOOTPD, and I would prefer to run it from INETD if possible. -- John **= Email 24 ==========================** Date: Thu, 2 Jan 2003 19:11:27 +0000 From: John Poltorak Subject: INETD & BOOTPD Ifanyone is familiar with how INETD launches other servers could you check BOOTPD for OS/2:- ? http://hobbes.nmsu.edu/pub/os2/util/network/tcpip/bootpd.zip This is described as a 'quick and dirty' port and no mention is made about its ability to run from INETD, and if it can, how it can pick up a socket. I'm trying to convert from hard coded IP addresses on my own network to getting them from a server at bootup which means I need to run BOOTPD, and I would prefer to run it from INETD if possible. -- John **= Email 25 ==========================** Date: Thu, 02 Jan 2003 19:29:55 -0600 (CST) From: "xyzyx" Subject: Re: GCC 3.0.3 On Thu, 02 Jan 2003 18:09:49 -0500, Ted Sikora wrote: >Anyone using it? I tried running it with the newgcc.cmd. Configure can't >find gcc with it. Are there any env setup README's for gcc 3.0.3 anywhere? I've been using it (outside of the UnixOS2 project) for quite some time (since it was uploaded :) Be sure to read the readme of course, other than that I've modified newgcc.cmd to the point of including this much in the environment setting section: set EMX_PATH=d:/emx/ set LD=d:/emx/bin.new/ld.exe set temp=/tmp/ set tmp=/tmp/ set WORK_SHELL=%COMSPEC% set EMXSHELL=sh set MKDIR=d:/emx/bin/mkdir.exe -p set LDFLAGS=-Zexe set PATH=%EMX_PATH%bin.new;%EMX_PATH%bin;%PATH% that seems to get the job done for me. I am unable to do any compiling that involves LINK386, the slashes/backslashes get lost so it errors out. I don't know if it's the fault of my setup (probably) or gcc 3.0.3 (doubtful). (Any ideas on this would be appreciated) Thanks, Paul **= Email 26 ==========================** Date: Thu, 02 Jan 2003 19:29:55 -0600 (CST) From: "xyzyx" Subject: Re: GCC 3.0.3 On Thu, 02 Jan 2003 18:09:49 -0500, Ted Sikora wrote: >Anyone using it? I tried running it with the newgcc.cmd. Configure can't >find gcc with it. Are there any env setup README's for gcc 3.0.3 anywhere? I've been using it (outside of the UnixOS2 project) for quite some time (since it was uploaded :) Be sure to read the readme of course, other than that I've modified newgcc.cmd to the point of including this much in the environment setting section: set EMX_PATH=d:/emx/ set LD=d:/emx/bin.new/ld.exe set temp=/tmp/ set tmp=/tmp/ set WORK_SHELL=%COMSPEC% set EMXSHELL=sh set MKDIR=d:/emx/bin/mkdir.exe -p set LDFLAGS=-Zexe set PATH=%EMX_PATH%bin.new;%EMX_PATH%bin;%PATH% that seems to get the job done for me. I am unable to do any compiling that involves LINK386, the slashes/backslashes get lost so it errors out. I don't know if it's the fault of my setup (probably) or gcc 3.0.3 (doubtful). (Any ideas on this would be appreciated) Thanks, Paul **= Email 27 ==========================** Date: Thu, 02 Jan 2003 19:40:12 -0600 (CST) From: "xyzyx" Subject: Re: IMDB ApplyDiff 2.5 On Fri, 03 Jan 2003 01:27:10 +0100 (CET), Christian Hennecke wrote: >Has anybody tried to compile ApplyDiff 2.5 for the Internet Movie >Database offline interface? No, but... >There seems to be some problem with the Makefile syntax. Using >GNU make 3.79.2a1 from inside the latest pdksh results in: (snip) I just d/l'ed the archive, it seems that if you comment out the lines about "packer" in the Makefile, and uncomment the matching packer #defines at the top of ApplyDiff.c it compiles perfectly. Whether or not it works, you can tell us :) I've got no idea what to do with it. Regards, Paul **= Email 28 ==========================** Date: Thu, 02 Jan 2003 19:40:12 -0600 (CST) From: "xyzyx" Subject: Re: IMDB ApplyDiff 2.5 On Fri, 03 Jan 2003 01:27:10 +0100 (CET), Christian Hennecke wrote: >Has anybody tried to compile ApplyDiff 2.5 for the Internet Movie >Database offline interface? No, but... >There seems to be some problem with the Makefile syntax. Using >GNU make 3.79.2a1 from inside the latest pdksh results in: (snip) I just d/l'ed the archive, it seems that if you comment out the lines about "packer" in the Makefile, and uncomment the matching packer #defines at the top of ApplyDiff.c it compiles perfectly. Whether or not it works, you can tell us :) I've got no idea what to do with it. Regards, Paul **= Email 29 ==========================** Date: Thu, 2 Jan 2003 20:33:39 +0000 From: John Poltorak Subject: Re: PASSWD handling On Thu, Jan 02, 2003 at 09:02:45PM +0100, Holger Veit wrote: > On Thu, Jan 02, 2003 at 12:21:37PM +0000, John Poltorak wrote: > [...] > > Many Unix programs have hard coded paths in them and if you run such a > > program where the path does not have a drive letter and you are on the > > wrong drive, you are likely to have a problem. This is one of the reason > > we often need to define so many variables on OS/2 whereas they are not > > needed on Unix. > > The reason for this is a lack of semantics un (Unix)OS/2 concerning > the meaning of the prefix '/'. If '/' would get redirected to > some "/drivec" (which gets mapped to "c:\") then the various obscure > environment settings were void. I.e. it again revolves around the > hen/egg-problem: make UNIXROOT working. > > Hardcoded paths in Unix are not the defect in the system, multiple > independent root file systems (this is what drive letters are) are. I think we accept that it is problem that OS/2 has, and until there is some mechanism to redirect '/' to the correct place, drive letters are a reality that we have to deal with. Until the correct solution comes along, my intention is to build apps using a prefix of c:/usr which I know will work on my system. At the same time, I'd like to provide build scripts which will allow others to rebuild the same apps and tailor them to their own environment without too much difficulty. However, that will not resolve the immediate problem of using drive letters in PASSWD. As far as PASSWD access goes, I think we need two solutions; a strategic one which we can put in place in the longer term when the best solution has evolved and all other components are available. But we also need a 'quick and dirty' solution which can be put together in maybe a week or so which can serve as a standard for all current apps which require passwd access. Hopefully when the long term solution is available it will be able to slot in fairly transparently by a single change to the passwd handler and no apps will need to be changed... > Holger > > -- > Please update your tables to my new e-mail address: > holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) > -- John **= Email 30 ==========================** Date: Thu, 2 Jan 2003 20:33:39 +0000 From: John Poltorak Subject: Re: PASSWD handling On Thu, Jan 02, 2003 at 09:02:45PM +0100, Holger Veit wrote: > On Thu, Jan 02, 2003 at 12:21:37PM +0000, John Poltorak wrote: > [...] > > Many Unix programs have hard coded paths in them and if you run such a > > program where the path does not have a drive letter and you are on the > > wrong drive, you are likely to have a problem. This is one of the reason > > we often need to define so many variables on OS/2 whereas they are not > > needed on Unix. > > The reason for this is a lack of semantics un (Unix)OS/2 concerning > the meaning of the prefix '/'. If '/' would get redirected to > some "/drivec" (which gets mapped to "c:\") then the various obscure > environment settings were void. I.e. it again revolves around the > hen/egg-problem: make UNIXROOT working. > > Hardcoded paths in Unix are not the defect in the system, multiple > independent root file systems (this is what drive letters are) are. I think we accept that it is problem that OS/2 has, and until there is some mechanism to redirect '/' to the correct place, drive letters are a reality that we have to deal with. Until the correct solution comes along, my intention is to build apps using a prefix of c:/usr which I know will work on my system. At the same time, I'd like to provide build scripts which will allow others to rebuild the same apps and tailor them to their own environment without too much difficulty. However, that will not resolve the immediate problem of using drive letters in PASSWD. As far as PASSWD access goes, I think we need two solutions; a strategic one which we can put in place in the longer term when the best solution has evolved and all other components are available. But we also need a 'quick and dirty' solution which can be put together in maybe a week or so which can serve as a standard for all current apps which require passwd access. Hopefully when the long term solution is available it will be able to slot in fairly transparently by a single change to the passwd handler and no apps will need to be changed... > Holger > > -- > Please update your tables to my new e-mail address: > holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) > -- John **= Email 31 ==========================** Date: Thu, 02 Jan 2003 20:56:40 +0100 (CET) From: "Adrian Gschwend" Subject: Re: nmap On Thu, 2 Jan 2003 18:38:01 +0000, John Poltorak wrote: >Has anyone attempted to port nmap to OS/2? We had that some month ago :-) Brian Smith did a port of it some time ago, however I was not able to get it to work properly on my system. His work is available here: ftp://ftp.netlabs.org/pub/misc/nmap-2.54beta30-os2.zip cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 32 ==========================** Date: Thu, 02 Jan 2003 20:56:40 +0100 (CET) From: "Adrian Gschwend" Subject: Re: nmap On Thu, 2 Jan 2003 18:38:01 +0000, John Poltorak wrote: >Has anyone attempted to port nmap to OS/2? We had that some month ago :-) Brian Smith did a port of it some time ago, however I was not able to get it to work properly on my system. His work is available here: ftp://ftp.netlabs.org/pub/misc/nmap-2.54beta30-os2.zip cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 33 ==========================** Date: Thu, 2 Jan 2003 21:02:45 +0100 From: Holger Veit Subject: Re: PASSWD handling On Thu, Jan 02, 2003 at 12:21:37PM +0000, John Poltorak wrote: [...] > Many Unix programs have hard coded paths in them and if you run such a > program where the path does not have a drive letter and you are on the > wrong drive, you are likely to have a problem. This is one of the reason > we often need to define so many variables on OS/2 whereas they are not > needed on Unix. The reason for this is a lack of semantics un (Unix)OS/2 concerning the meaning of the prefix '/'. If '/' would get redirected to some "/drivec" (which gets mapped to "c:\") then the various obscure environment settings were void. I.e. it again revolves around the hen/egg-problem: make UNIXROOT working. Hardcoded paths in Unix are not the defect in the system, multiple independent root file systems (this is what drive letters are) are. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 34 ==========================** Date: Thu, 2 Jan 2003 21:02:45 +0100 From: Holger Veit Subject: Re: PASSWD handling On Thu, Jan 02, 2003 at 12:21:37PM +0000, John Poltorak wrote: [...] > Many Unix programs have hard coded paths in them and if you run such a > program where the path does not have a drive letter and you are on the > wrong drive, you are likely to have a problem. This is one of the reason > we often need to define so many variables on OS/2 whereas they are not > needed on Unix. The reason for this is a lack of semantics un (Unix)OS/2 concerning the meaning of the prefix '/'. If '/' would get redirected to some "/drivec" (which gets mapped to "c:\") then the various obscure environment settings were void. I.e. it again revolves around the hen/egg-problem: make UNIXROOT working. Hardcoded paths in Unix are not the defect in the system, multiple independent root file systems (this is what drive letters are) are. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 35 ==========================** Date: Thu, 02 Jan 2003 23:46:36 +0100 From: Thomas Hoffmann Subject: Re: shadow-4.0.3 passwords There is an entry for Posix/2 on sourceforge which should be the "definitive source". But posix/2 is kind of abandonware, the discussion list is dead for a long time now. If you want to include posix/2 stuff into a standard build environment, then you should provide the headers AND the lib(s). And this interferes with the mythical EMU project ... Maybe Holger can comment on this. In my opinion it would be a step forward to provide extended functionality similar to posix/2 in a standardized fashion. Andreas Buening did some work into this direction too with libunixos2 (sp?), maybe it's time to focus on one solution. John Poltorak wrote: > On Thu, Jan 02, 2003 at 12:16:07AM -0500, Ted Sikora wrote: > >>I made some headway building the shadow(useradd, passwd, etc.) package >>for OS/2. After copying the posix/2-alpha3 /includes to my emx/includes >>it was like a different beast. > > > I'd like to incorporate the Posix/2 headers into a standard build > environment. Does anyone know if the file on Hobbes has the latest version > of the headers, or has more work been done on them since the upload to > Hobbes? > > >>-- >>Ted Sikora >>tsikora at ntplx.net > > > **= Email 36 ==========================** Date: Thu, 02 Jan 2003 23:46:36 +0100 From: Thomas Hoffmann Subject: Re: shadow-4.0.3 passwords There is an entry for Posix/2 on sourceforge which should be the "definitive source". But posix/2 is kind of abandonware, the discussion list is dead for a long time now. If you want to include posix/2 stuff into a standard build environment, then you should provide the headers AND the lib(s). And this interferes with the mythical EMU project ... Maybe Holger can comment on this. In my opinion it would be a step forward to provide extended functionality similar to posix/2 in a standardized fashion. Andreas Buening did some work into this direction too with libunixos2 (sp?), maybe it's time to focus on one solution. John Poltorak wrote: > On Thu, Jan 02, 2003 at 12:16:07AM -0500, Ted Sikora wrote: > >>I made some headway building the shadow(useradd, passwd, etc.) package >>for OS/2. After copying the posix/2-alpha3 /includes to my emx/includes >>it was like a different beast. > > > I'd like to incorporate the Posix/2 headers into a standard build > environment. Does anyone know if the file on Hobbes has the latest version > of the headers, or has more work been done on them since the upload to > Hobbes? > > >>-- >>Ted Sikora >>tsikora at ntplx.net > > > **= Email 37 ==========================** Date: Thu, 02 Jan 2003 23:56:01 -0500 From: Ted Sikora Subject: Re: GCC 3.0.3 Franz Bakan wrote: > On Thu, 02 Jan 2003 18:09:49 -0500, Ted Sikora wrote: > > >>Anyone using it? I tried running it with the newgcc.cmd. Configure can't >>find gcc with it. Are there any env setup README's for gcc 3.0.3 anywhere? > > > Did you edit newgcc.cmd to fit your needs? > > You eventually have to delete 'set C_INCLUDE_PATH=...' from config.sys > > The rest is well documented in the readme coming with gcc 3.0.3. > > At least it works here (also 'newgcc-approach'). I sometimes use > it for configure if 2.8.1-gcc reports it would not be able to create executables. > Got it working .. works well too. Rebuilt Zope and Mailman with it. Inching closer with shadow-4.0.3 too. utmp.h in emx was wrong. The canonical names were missing an underscore in the defines. Again all the libs built it's now just a gr_passwd issue. We need to find a workaround for it. -- Ted Sikora tsikora at ntplx.net **= Email 38 ==========================** Date: Thu, 02 Jan 2003 23:56:01 -0500 From: Ted Sikora Subject: Re: GCC 3.0.3 Franz Bakan wrote: > On Thu, 02 Jan 2003 18:09:49 -0500, Ted Sikora wrote: > > >>Anyone using it? I tried running it with the newgcc.cmd. Configure can't >>find gcc with it. Are there any env setup README's for gcc 3.0.3 anywhere? > > > Did you edit newgcc.cmd to fit your needs? > > You eventually have to delete 'set C_INCLUDE_PATH=...' from config.sys > > The rest is well documented in the readme coming with gcc 3.0.3. > > At least it works here (also 'newgcc-approach'). I sometimes use > it for configure if 2.8.1-gcc reports it would not be able to create executables. > Got it working .. works well too. Rebuilt Zope and Mailman with it. Inching closer with shadow-4.0.3 too. utmp.h in emx was wrong. The canonical names were missing an underscore in the defines. Again all the libs built it's now just a gr_passwd issue. We need to find a workaround for it. -- Ted Sikora tsikora at ntplx.net