From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Fri, 3 Jan 2003 04:47:08 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 2 ************************************************** Thursday 02 January 2003 Number 2 ************************************************** Subjects for today 1 Re: GCC 3.0.3 : Franz Bakan" 2 Re: GCC 3.0.3 : Franz Bakan" 3 IMDB ApplyDiff 2.5 : Christian Hennecke" 4 IMDB ApplyDiff 2.5 : Christian Hennecke" 5 New! Zope 2.6.1b1 : Ted Sikora 6 New! Zope 2.6.1b1 : Ted Sikora 7 headers : Ted Sikora 8 headers : Ted Sikora 9 Re: IMDB ApplyDiff 2.5 : xyzyx" 10 Re: IMDB ApplyDiff 2.5 : xyzyx" 11 Re: PASSWD handling : Nicholas Sheppard 12 Re: PASSWD handling : Nicholas Sheppard 13 Re: shadow-4.0.3 passwords : John Poltorak 14 Re: shadow-4.0.3 passwords : John Poltorak 15 Re: headers : Ted Sikora 16 Re: headers : Ted Sikora 17 Re: headers : John Poltorak 18 Re: headers : John Poltorak 19 Re: IMDB ApplyDiff 2.5 : Christian Hennecke" 20 Re: IMDB ApplyDiff 2.5 : Christian Hennecke" 21 Re: Webmin : Ted Sikora 22 Re: Webmin : Ted Sikora 23 Re: IMDB ApplyDiff 2.5 : Christian Hennecke" 24 Re: IMDB ApplyDiff 2.5 : Christian Hennecke" 25 Webmin : John Poltorak 26 Webmin : John Poltorak 27 Re: Webmin : John Poltorak 28 Re: Webmin : John Poltorak 29 Re: PASSWD handling : Holger Veit 30 Re: PASSWD handling : Holger Veit 31 Re: Webmin : Lyn St George" 32 Re: Webmin : Lyn St George" **= Email 1 ==========================** Date: Fri, 03 Jan 2003 00:17:56 +0100 (CET) From: "Franz Bakan" 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? 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. Franz **= Email 2 ==========================** Date: Fri, 03 Jan 2003 00:17:56 +0100 (CET) From: "Franz Bakan" 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? 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. Franz **= Email 3 ==========================** Date: Fri, 03 Jan 2003 01:27:10 +0100 (CET) From: "Christian Hennecke" Subject: IMDB ApplyDiff 2.5 Has anybody tried to compile ApplyDiff 2.5 for the Internet Movie Database offline interface (ftp://ftp.fu-berlin.de//pub/misc/movies/database/diffs/ApplyDiffs-2.5.t ar.gz)? There seems to be some problem with the Makefile syntax. Using GNU make 3.79.2a1 from inside the latest pdksh results in: [1]/ApplyDiffs: make gcc -DSYS_UNIX -O2 -c -DIMDB_GZIP -DIMDBV_FILE_PACKER_NAME="\"/usr/bin/gzip.exe\ "" -DIMDBV_FILE_PACKER_EXT="\".gz\"" -DIMDBV_FILE_PACKER_PACK="\"-1\"" -DIMDBV_ FILE_PACKER_UNPACK="\"-d\"" -o ApplyDiffs.o -c ApplyDiffs.c ApplyDiffs.c:0: unterminated string or character constant ApplyDiffs.c:0: possible real start of unterminated constant ApplyDiffs.c:0: unterminated string or character constant ApplyDiffs.c:0: possible real start of unterminated constant ApplyDiffs.c: In function `main': ApplyDiffs.c:1801: `IMDBV_FILE_PACKER_EXT' undeclared (first use in this functio n) ApplyDiffs.c:1801: (Each undeclared identifier is reported only once ApplyDiffs.c:1801: for each function it appears in.) ApplyDiffs.c:1891: `IMDBV_FILE_PACKER_NAME' undeclared (first use in this functi on) ApplyDiffs.c:1891: parse error before string constant ApplyDiffs.c:1936: parse error before string constant make: *** [ApplyDiffs.o] Error 1 Any help would be really appreciated, since the author of the Alternative Movie Database for OS/2 stopped maintaining the package and the included ApplyDiff 2.3 does not work with the weekly diffs after November 2001 or so. And the complete database is several 100MB... Christian Hennecke **= Email 4 ==========================** Date: Fri, 03 Jan 2003 01:27:10 +0100 (CET) From: "Christian Hennecke" Subject: IMDB ApplyDiff 2.5 Has anybody tried to compile ApplyDiff 2.5 for the Internet Movie Database offline interface (ftp://ftp.fu-berlin.de//pub/misc/movies/database/diffs/ApplyDiffs-2.5.t ar.gz)? There seems to be some problem with the Makefile syntax. Using GNU make 3.79.2a1 from inside the latest pdksh results in: [1]/ApplyDiffs: make gcc -DSYS_UNIX -O2 -c -DIMDB_GZIP -DIMDBV_FILE_PACKER_NAME="\"/usr/bin/gzip.exe\ "" -DIMDBV_FILE_PACKER_EXT="\".gz\"" -DIMDBV_FILE_PACKER_PACK="\"-1\"" -DIMDBV_ FILE_PACKER_UNPACK="\"-d\"" -o ApplyDiffs.o -c ApplyDiffs.c ApplyDiffs.c:0: unterminated string or character constant ApplyDiffs.c:0: possible real start of unterminated constant ApplyDiffs.c:0: unterminated string or character constant ApplyDiffs.c:0: possible real start of unterminated constant ApplyDiffs.c: In function `main': ApplyDiffs.c:1801: `IMDBV_FILE_PACKER_EXT' undeclared (first use in this functio n) ApplyDiffs.c:1801: (Each undeclared identifier is reported only once ApplyDiffs.c:1801: for each function it appears in.) ApplyDiffs.c:1891: `IMDBV_FILE_PACKER_NAME' undeclared (first use in this functi on) ApplyDiffs.c:1891: parse error before string constant ApplyDiffs.c:1936: parse error before string constant make: *** [ApplyDiffs.o] Error 1 Any help would be really appreciated, since the author of the Alternative Movie Database for OS/2 stopped maintaining the package and the included ApplyDiff 2.3 does not work with the weekly diffs after November 2001 or so. And the complete database is several 100MB... Christian Hennecke **= Email 5 ==========================** Date: Fri, 03 Jan 2003 09:18:45 -0500 From: Ted Sikora Subject: New! Zope 2.6.1b1 New Zope 2.6.1b1 binary at: ftp://os2ports.com/pub/os2/unix/internet/Zope/Zope261b1-os2emx-030103.zip -- Ted Sikora tsikora at ntplx.net **= Email 6 ==========================** Date: Fri, 03 Jan 2003 09:18:45 -0500 From: Ted Sikora Subject: New! Zope 2.6.1b1 New Zope 2.6.1b1 binary at: ftp://os2ports.com/pub/os2/unix/internet/Zope/Zope261b1-os2emx-030103.zip -- Ted Sikora tsikora at ntplx.net **= Email 7 ==========================** Date: Fri, 03 Jan 2003 09:21:45 -0500 From: Ted Sikora Subject: headers You can't just copy all the headers from posix/2 to emx. It started causing major headaches. Types.h and others cause problems. I just added the missing ones for now like syslog.h and utmp.h -- Ted Sikora tsikora at ntplx.net **= Email 8 ==========================** Date: Fri, 03 Jan 2003 09:21:45 -0500 From: Ted Sikora Subject: headers You can't just copy all the headers from posix/2 to emx. It started causing major headaches. Types.h and others cause problems. I just added the missing ones for now like syslog.h and utmp.h -- Ted Sikora tsikora at ntplx.net **= Email 9 ==========================** Date: Fri, 03 Jan 2003 09:25:27 -0600 (CST) From: "xyzyx" Subject: Re: IMDB ApplyDiff 2.5 On Fri, 03 Jan 2003 15:40:50 +0100 (CET), Christian Hennecke wrote: >Can you tell me what exactly the statements were that you used? And the >version of make? I commented every line before "#### GCC - LINUX ####" in the Makefile (and added -Zexe to the LDFLAGS...) the uncommented section in ApplyDiffs.c is: /* 2.3 Packer & options -> Makefile */ #define IMDB_GZIP #define IMDBV_FILE_PACKER_NAME "gzip" #define IMDBV_FILE_PACKER_EXT ".gz" #define IMDBV_FILE_PACKER_PACK "-4" #define IMDBV_FILE_PACKER_UNPACK "-d" It compiled with no errors or warnings under GCC 3.0.3 and also with the default GCC 2.x from EMX. Using GNU Make version 3.79.1 I've zipped up the compiled binaries & modified sources and will send them to you in a private email! Thanks, Paul **= Email 10 ==========================** Date: Fri, 03 Jan 2003 09:25:27 -0600 (CST) From: "xyzyx" Subject: Re: IMDB ApplyDiff 2.5 On Fri, 03 Jan 2003 15:40:50 +0100 (CET), Christian Hennecke wrote: >Can you tell me what exactly the statements were that you used? And the >version of make? I commented every line before "#### GCC - LINUX ####" in the Makefile (and added -Zexe to the LDFLAGS...) the uncommented section in ApplyDiffs.c is: /* 2.3 Packer & options -> Makefile */ #define IMDB_GZIP #define IMDBV_FILE_PACKER_NAME "gzip" #define IMDBV_FILE_PACKER_EXT ".gz" #define IMDBV_FILE_PACKER_PACK "-4" #define IMDBV_FILE_PACKER_UNPACK "-d" It compiled with no errors or warnings under GCC 3.0.3 and also with the default GCC 2.x from EMX. Using GNU Make version 3.79.1 I've zipped up the compiled binaries & modified sources and will send them to you in a private email! Thanks, Paul **= Email 11 ==========================** Date: Fri, 3 Jan 2003 09:40:53 +1100 (EST) From: Nicholas Sheppard Subject: Re: PASSWD handling On Thu, 2 Jan 2003, John Poltorak wrote: > > 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. I'm sure this has been said before but I'll say it again jut in case. I don't believe that drive letters are a "problem that OS/2 has" -- it's the way things are done in OS/2 (and others) and it's no more or less correct than the way things are done in Unix or anywhere else. You can argue about the pros and cons of different file systems, but drive letters are a reality that any usable (in my opinion) OS/2 application has to deal with, even if some applications want to make believe that / is somewhere other than the root of the current drive, or want to use /drive/c constructions. At least some Cygwin applications don't understand Windows-style paths, which makes them virtually unusable in a normal Windows environment. I don't want my OS/2 applications to go down the same path. > 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. Suppose I take the passwd code out of Pine for the next release (4.52 is currently in pre-release testing) and make it into a PASSWD.LIB, since I'm going to need to fix os2user.exe, anyway. The file format will be the same as the current one, except that drive letters will be represented by /dev/c, /dev/d, etc. instead of the current $ solution. It would be simple to make the reading routines able to parse the old $ and ; conventions and convert them, but new entries will be written in the new format. We can provide two getpwent() functions, one that returns an OS/2-style path and one that returns a Unix-style path, something like the getcwd() functions in EMX. Then developers can use #define to select which one they prefer. Nicholas S. **= Email 12 ==========================** Date: Fri, 3 Jan 2003 09:40:53 +1100 (EST) From: Nicholas Sheppard Subject: Re: PASSWD handling On Thu, 2 Jan 2003, John Poltorak wrote: > > 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. I'm sure this has been said before but I'll say it again jut in case. I don't believe that drive letters are a "problem that OS/2 has" -- it's the way things are done in OS/2 (and others) and it's no more or less correct than the way things are done in Unix or anywhere else. You can argue about the pros and cons of different file systems, but drive letters are a reality that any usable (in my opinion) OS/2 application has to deal with, even if some applications want to make believe that / is somewhere other than the root of the current drive, or want to use /drive/c constructions. At least some Cygwin applications don't understand Windows-style paths, which makes them virtually unusable in a normal Windows environment. I don't want my OS/2 applications to go down the same path. > 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. Suppose I take the passwd code out of Pine for the next release (4.52 is currently in pre-release testing) and make it into a PASSWD.LIB, since I'm going to need to fix os2user.exe, anyway. The file format will be the same as the current one, except that drive letters will be represented by /dev/c, /dev/d, etc. instead of the current $ solution. It would be simple to make the reading routines able to parse the old $ and ; conventions and convert them, but new entries will be written in the new format. We can provide two getpwent() functions, one that returns an OS/2-style path and one that returns a Unix-style path, something like the getcwd() functions in EMX. Then developers can use #define to select which one they prefer. Nicholas S. **= Email 13 ==========================** Date: Fri, 3 Jan 2003 10:48:14 +0000 From: John Poltorak Subject: Re: shadow-4.0.3 passwords On Thu, Jan 02, 2003 at 11:46:36PM +0100, Thomas Hoffmann wrote: > 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). Is there a simple way to build the libs? I'm not really sure what libs Posix/2 provides. Is there a list anywhere? > And this interferes with the mythical EMU project ... I don't think this is neessarily the case. Why not use what we can from Posix/2 within UnixOS/2, and replace it if/when LIBEMU comes along? > 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. Yes, there is a danger of fragmentation because Posix/2, libemu and libunixos2 all seem to have a large degree of overlap. I would prefer to incorporate as much as possible from Posix/2 into UnixOS/2 and then see what is missing. As I understand it we are basically talking about the contents of /usr/include and /usr/lib. Is that correct? > 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? -- John **= Email 14 ==========================** Date: Fri, 3 Jan 2003 10:48:14 +0000 From: John Poltorak Subject: Re: shadow-4.0.3 passwords On Thu, Jan 02, 2003 at 11:46:36PM +0100, Thomas Hoffmann wrote: > 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). Is there a simple way to build the libs? I'm not really sure what libs Posix/2 provides. Is there a list anywhere? > And this interferes with the mythical EMU project ... I don't think this is neessarily the case. Why not use what we can from Posix/2 within UnixOS/2, and replace it if/when LIBEMU comes along? > 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. Yes, there is a danger of fragmentation because Posix/2, libemu and libunixos2 all seem to have a large degree of overlap. I would prefer to incorporate as much as possible from Posix/2 into UnixOS/2 and then see what is missing. As I understand it we are basically talking about the contents of /usr/include and /usr/lib. Is that correct? > 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? -- John **= Email 15 ==========================** Date: Fri, 03 Jan 2003 11:20:28 -0500 From: Ted Sikora Subject: Re: headers John Poltorak wrote: > > On Fri, Jan 03, 2003 at 09:21:45AM -0500, Ted Sikora wrote: > > You can't just copy all the headers from posix/2 to emx. It started > > causing major headaches. Types.h and others cause problems. I just added > > the missing ones for now like syslog.h and utmp.h > > I would suggest copying the posix/2 headers to /usr/include and leaving > the emx headers in /emx/include and then setting:- > > C_INCLUDE_PATH=/usr/include;/emx/include > Good idea. I'll see if it makes a difference. -- Ted **= Email 16 ==========================** Date: Fri, 03 Jan 2003 11:20:28 -0500 From: Ted Sikora Subject: Re: headers John Poltorak wrote: > > On Fri, Jan 03, 2003 at 09:21:45AM -0500, Ted Sikora wrote: > > You can't just copy all the headers from posix/2 to emx. It started > > causing major headaches. Types.h and others cause problems. I just added > > the missing ones for now like syslog.h and utmp.h > > I would suggest copying the posix/2 headers to /usr/include and leaving > the emx headers in /emx/include and then setting:- > > C_INCLUDE_PATH=/usr/include;/emx/include > Good idea. I'll see if it makes a difference. -- Ted **= Email 17 ==========================** Date: Fri, 3 Jan 2003 14:25:21 +0000 From: John Poltorak Subject: Re: headers On Fri, Jan 03, 2003 at 09:21:45AM -0500, Ted Sikora wrote: > You can't just copy all the headers from posix/2 to emx. It started > causing major headaches. Types.h and others cause problems. I just added > the missing ones for now like syslog.h and utmp.h I would suggest copying the posix/2 headers to /usr/include and leaving the emx headers in /emx/include and then setting:- C_INCLUDE_PATH=/usr/include;/emx/include > -- > Ted Sikora > tsikora at ntplx.net -- John **= Email 18 ==========================** Date: Fri, 3 Jan 2003 14:25:21 +0000 From: John Poltorak Subject: Re: headers On Fri, Jan 03, 2003 at 09:21:45AM -0500, Ted Sikora wrote: > You can't just copy all the headers from posix/2 to emx. It started > causing major headaches. Types.h and others cause problems. I just added > the missing ones for now like syslog.h and utmp.h I would suggest copying the posix/2 headers to /usr/include and leaving the emx headers in /emx/include and then setting:- C_INCLUDE_PATH=/usr/include;/emx/include > -- > Ted Sikora > tsikora at ntplx.net -- John **= Email 19 ==========================** Date: Fri, 03 Jan 2003 15:40:50 +0100 (CET) From: "Christian Hennecke" Subject: Re: IMDB ApplyDiff 2.5 On Thu, 02 Jan 2003 19:40:12 -0600 (CST), xyzyx wrote: >>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. If I do that I get: ApplyDiffs.c: In function `main': ApplyDiffs.c:1801: parse error before '.' token ApplyDiffs.c:1881: parse error before '.' token ApplyDiffs.c:1891: parse error before '/' token ApplyDiffs.c:1936: parse error before '/' token make: *** [ApplyDiffs.o] Error 1 Can you tell me what exactly the statements were that you used? And the version of make? As for what the program does: Basically it's a faster diff that does not produce large temporary files and also does CRC checking. This is used to update the files that contain the information for the Internet Movie Database. The whole database is some 100MBs large and updated once a week. If you had to download the complete database each time, that wouldn't be much fun, so they provide diffs which are to be applied with this tool. In case you don't know what the IMDB is: It's a database that contains information about pretty much every movie ever released in the last decades. The info covers actors, directors, plot, running times, rating, etc. etc. There is also much actor-related information with short biographies, a list of all the movies they've ever played in etc. Of course you can also view all that on their web site, but the offline interface is faster, doesn't display any advertisements and you don't have to pay your ISP. Christian Hennecke **= Email 20 ==========================** Date: Fri, 03 Jan 2003 15:40:50 +0100 (CET) From: "Christian Hennecke" Subject: Re: IMDB ApplyDiff 2.5 On Thu, 02 Jan 2003 19:40:12 -0600 (CST), xyzyx wrote: >>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. If I do that I get: ApplyDiffs.c: In function `main': ApplyDiffs.c:1801: parse error before '.' token ApplyDiffs.c:1881: parse error before '.' token ApplyDiffs.c:1891: parse error before '/' token ApplyDiffs.c:1936: parse error before '/' token make: *** [ApplyDiffs.o] Error 1 Can you tell me what exactly the statements were that you used? And the version of make? As for what the program does: Basically it's a faster diff that does not produce large temporary files and also does CRC checking. This is used to update the files that contain the information for the Internet Movie Database. The whole database is some 100MBs large and updated once a week. If you had to download the complete database each time, that wouldn't be much fun, so they provide diffs which are to be applied with this tool. In case you don't know what the IMDB is: It's a database that contains information about pretty much every movie ever released in the last decades. The info covers actors, directors, plot, running times, rating, etc. etc. There is also much actor-related information with short biographies, a list of all the movies they've ever played in etc. Of course you can also view all that on their web site, but the offline interface is faster, doesn't display any advertisements and you don't have to pay your ISP. Christian Hennecke **= Email 21 ==========================** Date: Fri, 03 Jan 2003 16:59:42 -0500 From: Ted Sikora Subject: Re: Webmin I've set up several on servers for customers. It works ok but I still feel funny about giving root access via the web. Ever since it appeared in Linux Journal everyone wanted it. It uses SSL for security. I still think SSH is a better route in Unix anyways. John Poltorak wrote: > Does anyone know much about Webmin? More specifically will it work on > OS/2? > >>From http://www.webmin.com :- > > > Introduction to Webmin > > What is Webmin? > > Webmin is a web-based interface for system administration for Unix. > Using any browser that supports tables and forms (and Java for the > File Manager module), you can setup user accounts, Apache, DNS, file > sharing and so on. > > Webmin consists of a simple web server, and a number of CGI programs > which directly update system files like /etc/inetd.conf and > /etc/passwd. The web server and all CGI programs are written in Perl > version 5, and use no non-standard Perl modules. > > > > This sounds like something I would like to use. > > -- -- Ted Sikora tsikora at ntplx.net **= Email 22 ==========================** Date: Fri, 03 Jan 2003 16:59:42 -0500 From: Ted Sikora Subject: Re: Webmin I've set up several on servers for customers. It works ok but I still feel funny about giving root access via the web. Ever since it appeared in Linux Journal everyone wanted it. It uses SSL for security. I still think SSH is a better route in Unix anyways. John Poltorak wrote: > Does anyone know much about Webmin? More specifically will it work on > OS/2? > >>From http://www.webmin.com :- > > > Introduction to Webmin > > What is Webmin? > > Webmin is a web-based interface for system administration for Unix. > Using any browser that supports tables and forms (and Java for the > File Manager module), you can setup user accounts, Apache, DNS, file > sharing and so on. > > Webmin consists of a simple web server, and a number of CGI programs > which directly update system files like /etc/inetd.conf and > /etc/passwd. The web server and all CGI programs are written in Perl > version 5, and use no non-standard Perl modules. > > > > This sounds like something I would like to use. > > -- -- Ted Sikora tsikora at ntplx.net **= Email 23 ==========================** Date: Fri, 03 Jan 2003 17:06:44 +0100 (CET) From: "Christian Hennecke" Subject: Re: IMDB ApplyDiff 2.5 On Fri, 03 Jan 2003 09:25:27 -0600 (CST), xyzyx wrote: >>Can you tell me what exactly the statements were that you used? And the >>version of make? > >I commented every line before "#### GCC - LINUX ####" in the Makefile >(and added -Zexe to the LDFLAGS...) > >the uncommented section in ApplyDiffs.c is: > >/* 2.3 Packer & options -> Makefile */ >#define IMDB_GZIP >#define IMDBV_FILE_PACKER_NAME "gzip" >#define IMDBV_FILE_PACKER_EXT ".gz" >#define IMDBV_FILE_PACKER_PACK "-4" >#define IMDBV_FILE_PACKER_UNPACK "-d" Oh well, I didn't get it that you were talking about ApplyDiffs.c. >I've zipped up the compiled binaries & modified sources and will send >them to you in a private email! Thanks a lot. I'm going to send this to the tool's maintainer. Christian Hennecke **= Email 24 ==========================** Date: Fri, 03 Jan 2003 17:06:44 +0100 (CET) From: "Christian Hennecke" Subject: Re: IMDB ApplyDiff 2.5 On Fri, 03 Jan 2003 09:25:27 -0600 (CST), xyzyx wrote: >>Can you tell me what exactly the statements were that you used? And the >>version of make? > >I commented every line before "#### GCC - LINUX ####" in the Makefile >(and added -Zexe to the LDFLAGS...) > >the uncommented section in ApplyDiffs.c is: > >/* 2.3 Packer & options -> Makefile */ >#define IMDB_GZIP >#define IMDBV_FILE_PACKER_NAME "gzip" >#define IMDBV_FILE_PACKER_EXT ".gz" >#define IMDBV_FILE_PACKER_PACK "-4" >#define IMDBV_FILE_PACKER_UNPACK "-d" Oh well, I didn't get it that you were talking about ApplyDiffs.c. >I've zipped up the compiled binaries & modified sources and will send >them to you in a private email! Thanks a lot. I'm going to send this to the tool's maintainer. Christian Hennecke **= Email 25 ==========================** Date: Fri, 3 Jan 2003 21:29:04 +0000 From: John Poltorak Subject: Webmin Does anyone know much about Webmin? More specifically will it work on OS/2? From http://www.webmin.com :- Introduction to Webmin What is Webmin? Webmin is a web-based interface for system administration for Unix. Using any browser that supports tables and forms (and Java for the File Manager module), you can setup user accounts, Apache, DNS, file sharing and so on. Webmin consists of a simple web server, and a number of CGI programs which directly update system files like /etc/inetd.conf and /etc/passwd. The web server and all CGI programs are written in Perl version 5, and use no non-standard Perl modules. This sounds like something I would like to use. -- John **= Email 26 ==========================** Date: Fri, 3 Jan 2003 21:29:04 +0000 From: John Poltorak Subject: Webmin Does anyone know much about Webmin? More specifically will it work on OS/2? From http://www.webmin.com :- Introduction to Webmin What is Webmin? Webmin is a web-based interface for system administration for Unix. Using any browser that supports tables and forms (and Java for the File Manager module), you can setup user accounts, Apache, DNS, file sharing and so on. Webmin consists of a simple web server, and a number of CGI programs which directly update system files like /etc/inetd.conf and /etc/passwd. The web server and all CGI programs are written in Perl version 5, and use no non-standard Perl modules. This sounds like something I would like to use. -- John **= Email 27 ==========================** Date: Fri, 3 Jan 2003 21:53:39 +0000 From: John Poltorak Subject: Re: Webmin On Fri, Jan 03, 2003 at 04:59:42PM -0500, Ted Sikora wrote: > I've set up several on servers for customers. It works ok but I still > feel funny about giving root access via the web. Ever since it appeared > in Linux Journal everyone wanted it. It uses SSL for security. I still > think SSH is a better route in Unix anyways. But will it work on OS/2? > John Poltorak wrote: > > Does anyone know much about Webmin? More specifically will it work on > > OS/2? > > > >>From http://www.webmin.com :- > > > > > > Introduction to Webmin > > > > What is Webmin? > > > > Webmin is a web-based interface for system administration for Unix. > > Using any browser that supports tables and forms (and Java for the > > File Manager module), you can setup user accounts, Apache, DNS, file > > sharing and so on. > > > > Webmin consists of a simple web server, and a number of CGI programs > > which directly update system files like /etc/inetd.conf and > > /etc/passwd. The web server and all CGI programs are written in Perl > > version 5, and use no non-standard Perl modules. > > > > > > > > This sounds like something I would like to use. -- John **= Email 28 ==========================** Date: Fri, 3 Jan 2003 21:53:39 +0000 From: John Poltorak Subject: Re: Webmin On Fri, Jan 03, 2003 at 04:59:42PM -0500, Ted Sikora wrote: > I've set up several on servers for customers. It works ok but I still > feel funny about giving root access via the web. Ever since it appeared > in Linux Journal everyone wanted it. It uses SSL for security. I still > think SSH is a better route in Unix anyways. But will it work on OS/2? > John Poltorak wrote: > > Does anyone know much about Webmin? More specifically will it work on > > OS/2? > > > >>From http://www.webmin.com :- > > > > > > Introduction to Webmin > > > > What is Webmin? > > > > Webmin is a web-based interface for system administration for Unix. > > Using any browser that supports tables and forms (and Java for the > > File Manager module), you can setup user accounts, Apache, DNS, file > > sharing and so on. > > > > Webmin consists of a simple web server, and a number of CGI programs > > which directly update system files like /etc/inetd.conf and > > /etc/passwd. The web server and all CGI programs are written in Perl > > version 5, and use no non-standard Perl modules. > > > > > > > > This sounds like something I would like to use. -- John **= Email 29 ==========================** Date: Fri, 3 Jan 2003 21:56:27 +0100 From: Holger Veit Subject: Re: PASSWD handling On Fri, Jan 03, 2003 at 09:40:53AM +1100, Nicholas Sheppard wrote: > On Thu, 2 Jan 2003, John Poltorak wrote: > > > > 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. > > I'm sure this has been said before but I'll say it again jut in case. > > I don't believe that drive letters are a "problem that OS/2 has" -- it's > the way things are done in OS/2 (and others) and it's no more or less > correct than the way things are done in Unix or anywhere else. You can Oh, history of operating systems *has* shown that drive letters, or rather the more general mechanism of named file storage compartments (remember PDP-11/VAX based systems like RSX, RT11, RSTS, VMS, or even AmigaOS - you are not restricted to single letter - this is an annoying CP/Mism which unfortunately survived longer than reasonalbe people hoped), *are* an anachronism which resulted from the limited space of single disk devices. Nowadays, one would immediately implement a RAID-based (or alike) system where the available disks are somehow concatenated to give the impression of a single large disk space. Even for separation of users (leave alone separation of applications (PATH/LIBPATH with their size limit are even worse anachronisms) there is no reason to keep different disks named by different drive letters (again VMS: one might allow aliases for several compartments, and even apply disk quotas if necessary) but the thing that is to be avoided generally is the "disk full" error - users should never ever need to know about limited disk resources (particularly not in a world of >100GB disks being common practice). People have still enough to think about a single system of folders and files, they shouldn't need to become librarians to file certain documents in different shelves in different buildings (to stress the library analogy). > argue about the pros and cons of different file systems, but drive > letters are a reality that any usable (in my opinion) OS/2 application > has to deal with, even if some applications want to make believe that / > is somewhere other than the root of the current drive, or want to use > /drive/c constructions. You already have TVFS today to lump all physical devices onto a single device. But instead people still want to keep the traditional way of thinking in outdated categories. OS/2 will happily work on a single "root file system" (a.k.a. "drive") provided it is large enough. Face it that the natural thing is a single cabinet of folders (the cabinet being reasonably large), not multiple size-limited cabinets that will once in a while burst when overloaded. > At least some Cygwin applications don't understand Windows-style paths, > which makes them virtually unusable in a normal Windows environment. I > don't want my OS/2 applications to go down the same path. Cygwin is an example of things that are possible, not a paradigm to follow. > > 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. > > Suppose I take the passwd code out of Pine for the next release (4.52 is > currently in pre-release testing) and make it into a PASSWD.LIB, since > I'm going to need to fix os2user.exe, anyway. > > The file format will be the same as the current one, except that drive > letters will be represented by /dev/c, /dev/d, etc. instead of the > current $ solution. It would be simple to make the reading routines able > to parse the old $ and ; conventions and convert them, but new entries > will be written in the new format. > > We can provide two getpwent() functions, one that returns an OS/2-style > path and one that returns a Unix-style path, something like the getcwd() > functions in EMX. Then developers can use #define to select which one > they prefer. Bad idea. There is one and only one function named getpwent() in POSIX which is supposed to return a root based file name. Rather make the system tolerant of root-based names. This means: - the unix functions should accept both conventions (fopen,open,stat, etc.) although they usually, for a port, will normally never see any drive letter at all. This is possible in the runtime layer like in EMXLIBC*.DLL - regular Unix ports will never need to call Dos* directly when done right. - the OS/2 APIs will already get canonicalized through DosCanonicalize() which is prepended to each standard file name API (like DosOpen) in the thunking layer of DOSCALL1.DLL (in the SES APIs you will exclusively see canonicalized names) - however this mapping is wrong with regard to UnixOS/2 - it needs to be fixed in the SES system. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 30 ==========================** Date: Fri, 3 Jan 2003 21:56:27 +0100 From: Holger Veit Subject: Re: PASSWD handling On Fri, Jan 03, 2003 at 09:40:53AM +1100, Nicholas Sheppard wrote: > On Thu, 2 Jan 2003, John Poltorak wrote: > > > > 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. > > I'm sure this has been said before but I'll say it again jut in case. > > I don't believe that drive letters are a "problem that OS/2 has" -- it's > the way things are done in OS/2 (and others) and it's no more or less > correct than the way things are done in Unix or anywhere else. You can Oh, history of operating systems *has* shown that drive letters, or rather the more general mechanism of named file storage compartments (remember PDP-11/VAX based systems like RSX, RT11, RSTS, VMS, or even AmigaOS - you are not restricted to single letter - this is an annoying CP/Mism which unfortunately survived longer than reasonalbe people hoped), *are* an anachronism which resulted from the limited space of single disk devices. Nowadays, one would immediately implement a RAID-based (or alike) system where the available disks are somehow concatenated to give the impression of a single large disk space. Even for separation of users (leave alone separation of applications (PATH/LIBPATH with their size limit are even worse anachronisms) there is no reason to keep different disks named by different drive letters (again VMS: one might allow aliases for several compartments, and even apply disk quotas if necessary) but the thing that is to be avoided generally is the "disk full" error - users should never ever need to know about limited disk resources (particularly not in a world of >100GB disks being common practice). People have still enough to think about a single system of folders and files, they shouldn't need to become librarians to file certain documents in different shelves in different buildings (to stress the library analogy). > argue about the pros and cons of different file systems, but drive > letters are a reality that any usable (in my opinion) OS/2 application > has to deal with, even if some applications want to make believe that / > is somewhere other than the root of the current drive, or want to use > /drive/c constructions. You already have TVFS today to lump all physical devices onto a single device. But instead people still want to keep the traditional way of thinking in outdated categories. OS/2 will happily work on a single "root file system" (a.k.a. "drive") provided it is large enough. Face it that the natural thing is a single cabinet of folders (the cabinet being reasonably large), not multiple size-limited cabinets that will once in a while burst when overloaded. > At least some Cygwin applications don't understand Windows-style paths, > which makes them virtually unusable in a normal Windows environment. I > don't want my OS/2 applications to go down the same path. Cygwin is an example of things that are possible, not a paradigm to follow. > > 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. > > Suppose I take the passwd code out of Pine for the next release (4.52 is > currently in pre-release testing) and make it into a PASSWD.LIB, since > I'm going to need to fix os2user.exe, anyway. > > The file format will be the same as the current one, except that drive > letters will be represented by /dev/c, /dev/d, etc. instead of the > current $ solution. It would be simple to make the reading routines able > to parse the old $ and ; conventions and convert them, but new entries > will be written in the new format. > > We can provide two getpwent() functions, one that returns an OS/2-style > path and one that returns a Unix-style path, something like the getcwd() > functions in EMX. Then developers can use #define to select which one > they prefer. Bad idea. There is one and only one function named getpwent() in POSIX which is supposed to return a root based file name. Rather make the system tolerant of root-based names. This means: - the unix functions should accept both conventions (fopen,open,stat, etc.) although they usually, for a port, will normally never see any drive letter at all. This is possible in the runtime layer like in EMXLIBC*.DLL - regular Unix ports will never need to call Dos* directly when done right. - the OS/2 APIs will already get canonicalized through DosCanonicalize() which is prepended to each standard file name API (like DosOpen) in the thunking layer of DOSCALL1.DLL (in the SES APIs you will exclusively see canonicalized names) - however this mapping is wrong with regard to UnixOS/2 - it needs to be fixed in the SES system. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 31 ==========================** Date: Fri, 03 Jan 2003 22:18:59 +0000 From: "Lyn St George" Subject: Re: Webmin On Fri, 3 Jan 2003 21:53:39 +0000, John Poltorak wrote: >On Fri, Jan 03, 2003 at 04:59:42PM -0500, Ted Sikora wrote: >> I've set up several on servers for customers. It works ok but I still >> feel funny about giving root access via the web. Ever since it appeared >> in Linux Journal everyone wanted it. It uses SSL for security. I still >> think SSH is a better route in Unix anyways. > >But will it work on OS/2? Yes, it works well here on this Warp4 fp12 box, with perl 5.8.0. It's actually an excellent example of a control panel, continually developed and with a wide range of modules. Because it's perl you can write your own modules, and it's possible to save yourself a huge amount of time and hassle in your daily work (depending on what that is of course ... ) by using it. Think of it as a simple browser front end to automated scripts, it beats the socks off running them by hand with all those typos .. On Unix you can choose what privileges to let the user run it as, and get some quite fine control over PgSQL users for example. Just grab it and try it out. - Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 32 ==========================** Date: Fri, 03 Jan 2003 22:18:59 +0000 From: "Lyn St George" Subject: Re: Webmin On Fri, 3 Jan 2003 21:53:39 +0000, John Poltorak wrote: >On Fri, Jan 03, 2003 at 04:59:42PM -0500, Ted Sikora wrote: >> I've set up several on servers for customers. It works ok but I still >> feel funny about giving root access via the web. Ever since it appeared >> in Linux Journal everyone wanted it. It uses SSL for security. I still >> think SSH is a better route in Unix anyways. > >But will it work on OS/2? Yes, it works well here on this Warp4 fp12 box, with perl 5.8.0. It's actually an excellent example of a control panel, continually developed and with a wide range of modules. Because it's perl you can write your own modules, and it's possible to save yourself a huge amount of time and hassle in your daily work (depending on what that is of course ... ) by using it. Think of it as a simple browser front end to automated scripts, it beats the socks off running them by hand with all those typos .. On Unix you can choose what privileges to let the user run it as, and get some quite fine control over PgSQL users for example. Just grab it and try it out. - Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +----------------------------------------------------------------------------------