From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Mon, 14 Apr 2003 14:03:16 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 98 ************************************************** Sunday 13 April 2003 Number 98 ************************************************** Subjects for today 1 Re: Deleting \socket\syslog : John Poltorak 2 SPOP : John Poltorak 3 Re: eFDS-1.TXT : Steve Wendt 4 eFDS-1.TXT : Nicky Morrow 5 Re: eFDS-1.TXT : Steve Wendt" 6 Re: eFDS-1.TXT : Nicky Morrow 7 Re: Newbie : Andreas Buening **= Email 1 ==========================** Date: Mon, 14 Apr 2003 10:48:38 +0100 From: John Poltorak Subject: Re: Deleting \socket\syslog On Sun, Apr 13, 2003 at 10:10:57AM -0800, Dave and Natalie wrote: > On Sat, 12 Apr 2003 11:56:24 +0100, John Poltorak wrote: > > > > >Can anyone suggest how I would go about deleting \socket\syslog ? > > > > > >I think this was created by SYSLOGD, but has remained after I killed the > >program, and now I can't restart it. > > I have a program here that does that. It doesn't work here. It requires a socket number, but \socket\syslog does not have a number... > Upload Information Template for Hobbes.nmsu.edu > =============================================== > > Archive Filename: soclose > Short Description: soclose - Socket closer > Long Description: soclose - Socket closer > Lets you close any socket given its socket > descriptor ID, obtained with the NETSTAT -s > command. Useful for ending some kinds of PM > programs or for freeing up active side sockets > stuck in the CLOSE_WAIT state. -- John **= Email 2 ==========================** Date: Mon, 14 Apr 2003 11:49:03 +0100 From: John Poltorak Subject: SPOP Has anyone come across SPOP? It's a local delivery agent used by Sendmail for users who only have a POP account. It's supposed to be available from:- http://www.ics.uci.edu/~mh/ -- John **= Email 3 ==========================** Date: Mon, 14 Apr 2003 17:47:43 -0700 (PDT) From: Steve Wendt Subject: Re: eFDS-1.TXT On Mon, 14 Apr 2003, Nicky Morrow wrote: > - If something is stupid, tell me why it is stupid and what the proper > solution is. \var\log .log files (no subdirectories allowed) \var\temp temporary files (no subdirectories allowed) You can't very well place this "no subdirectories allowed" restriction on variable data. Sometimes it makes perfect sense to use a subdirectory. **= Email 4 ==========================** Date: Mon, 14 Apr 2003 19:42:21 -0300 From: Nicky Morrow Subject: eFDS-1.TXT This is a multi-part message in MIME format. --------------070505030606040104050900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andreas Buening wrote: >> We are trying to set some standards >>for folks to follow in order to ease system administration. >> >> > >This sounds like a great idea. > I think it is a good idea also...some would argue it is long overdue. > > > >>Anyway, if anyone here is interested in seeing the document in its >>current form please let me know and I'll email a copy to you. >> >> > >Please, could you post this on this list, if it isn't a nn MB file? > Yes, eFDS-1.TXT attached. It is actually a very small document at this point. You'll notice from the date that it hasn't had any work for 4 months. That is primarily due to the tremedous push that was required to get eCS v1.1 out the door. Now that eCS v1.1 is off to manufacturing it would be great if we could add anything that needs to be added to this document (corrections also) so that we can get to the point that it is publically releasable. Many items in this document are already included in v1.1 and if we don't get a document on the street explaining what is going on we are going to end up retyping a lot of explanations . There are 4 main themes behind what is in this document to this point: - We need a simplified file and directory structure that is well documented. There have been a lot of ways to do many things on OS/2 over the years...some good, some bad. But we've had very limited guidance as to the right way and wrong way. - We need to ease the burden on sysadmins, users and developers as far as the organization of the structure goes. This document seeks to impose a very strict structure that if followed could have a very profound effect. - We would like to ease the future addition of multiuser capability...it is coming. - We would like to make life easier for those interested in porting *nix software to the platform. Anyone here know anyone that fits this description? What I expect from your reviews? - If something is stupid, tell me why it is stupid and what the proper solution is. - If something is good, tell me so. - If you see the need to add things, tell me what to add and why. Final note: eCS v1.1 creates and uses many directories that are very familiar to the *nix community: \home, \var and more...no, I'm not kidding. Cheers, Nick > > >Bye, >Andreas > > > --------------070505030606040104050900 Content-Type: text/plain; name="eFDS-1.TXT" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="eFDS-1.TXT" 2002 Dec 07 eCS File and Directory Standard (eFDS)-- Version 1 draft ftp.ecomstation.com/edg/docsTeam/eFDS/eFDS-1.TXT Edited by Nick Morrow Approved by Serenity Systems on 2003 Xxx XX SUMMARY This standard consists of a set of requirements and guidelines for file and directory placement under the eCS operating system. The guidelines are intended to support interoperability of applications, system administration tools, development tools, and REXX or batch scripts as well as greater uniformity of documentation. This standard is similar in some respects to the Linux file and directory standard, however, the Linux file and directory standard is very complex which makes it difficult and frustrating to use. On the other hand, this standard is written with simplicity and ease of use in mind. 1. Introduction 1.1 Purpose This standard enables o Software to predict the location of installed files and directories, and o Users to predict the location of installed files and directories. We do this by o Specifying guiding principles for each area of the filesystem, o Specifying the files and directories that are required, o Enumerating exceptions to the principles, and o Enumerating specific cases where there has been historical conflict. The document is used by o Independent software suppliers to create applications which are eFDS compliant, o OS creators to maintain eFDS compliance, and o Users to understand and maintain the eFDS compliance of a system. 1.2 Conventions Components that vary are represented by a description of the contents enclosed in "<" and ">" characters. Optional components are enclosed in "[" and "]" characters and may be combined with the "<" and ">" convention. Variable substrings of directory names and filenames are indicated by "*". 2. The Filesystem It is possible to define two independent categories of files: shareable vs unshareable and variable vs static. There is a simple and easily understandable logic to understanding the reason for defining these categories: Why are we separating directories into shareable and nonshareable? Primarily for ease of administration. If a system administrator has to hunt all over the place when setting permissions for directories which need to be lan accessable then a lot of time is wasted and the effort is more pron to errors. Why are we separating directories into variable and static? We need to take into consideration which directories should be read-only and which should be read-write. Static directories should be read only except to the system administrator while variable directories should be read-write for more users than the system administrator. Shareable data is that which can be shared between several different hosts; unshareable is that which is specific to a particular host. Static data includes binaries, libraries, documentation, and anything that does not change without system administrator intervention; variable data is anything else that does change without system administrator intervention. BEGIN RATIONALE The distinction between shareable and unshareable data is needed for several reasons: o In a networked environment (i.e., more than one host at a site), there is a good deal of data that can be shared between different hosts to save space and ease the task of maintenance. If shareable files are grouped together in a logical manner a significant reduction in administrator workload can be realized. o In a networked environment, certain files contain information specific to a single host. Therefore these filesystems cannot be shared (without taking special measures). o Interspersing shareable and unshareable data in the same hierarchy makes it difficult to share large portions of the filesystem. Here is a summarizing chart: +---------+-----------------+-------------+ | | shareable | unshareable | +---------+-----------------+-------------+ |static | \programs | \ecs | +---------+-----------------+-------------+ |variable | \home | \var | +---------+-----------------+-------------+ \ecs - intended for static, nonshareable files -- read-only -- will not be made available on the lan -- must be located on host system -- must be on the boot volume \home - intended for variable, shareable files -- read-write -- may be made available on the lan -- does not need to be located on the host system -- does not need to be on the boot volume \programs - intended for static, shareable files -- read-only -- may be made available on the lan -- does not need to be located on the host system -- does not need to be on the boot volume \var - intended for variable, nonshareable files -- read-write -- will not be made available on the lan -- must be located on host system -- does not need to be on the boot volume END RATIONALE 3. The Boot Volume 3.1 Purpose The contents of the boot volume must be adequate to boot, restore, recover, and/or repair the system. o To boot a system, enough must be present on the boot volume to mount other filesystems. This includes utilities to modify, move and delete files in order to restore a satisfactory configuration. \home and \programs are designed such that they may be located on other volumes or host systems. BEGIN RATIONALE The primary concern used to balance these considerations, which favor placing many things on the boot volume, is the goal of keeping boot volume as small as reasonably possible. For several reasons, it is desirable to keep the boot volume small: o The boot volume contains many system-specific configuration files. This means that the boot volume isn't always shareable between networked systems. Keeping it small on servers in networked systems minimizes the amount of lost space for areas of unshareable files. It also allows workstations with smaller local hard drives. o Disk errors that corrupt data on the boot volume are a greater problem than errors on any other partition. A small root filesystem is less prone to corruption as the result of a system crash. o Smaller boot volumes permit greater flexibility in system setup and maintenance to include the use of bootable memory disks, remote boot volumes, and "universal" boot volumes customised to fit a particular line of identical systems. Software must never create or require files or subdirectories in the root directory. Other locations in the eFDS hierarchy provide more than enough flexibility for any package. There are several reasons why introducing a new subdirectory in the root directory is prohibited: o It demands space on a root partition which the system administrator may want kept small and simple for either performance or security reasons. o It evades whatever discipline the system administrator may have set up for distributing standard file hierarchies across mountable volumes. END RATIONALE 3.2 Requirements The following directories are required to meet eFDS standards: \ecs operating system related directories - unshareable static files \home user home directories - shareable variable files \programs application directories - shareable static files \var temp and log files - unshareable variable files 3.3 Specific Options The \ecs directory shall contain the following directories: \ecs\bin essential command binaries (no subdirectories allowed) \ecs\book .inf files \ecs\boot device drivers \ecs\dll essential shared libraries \ecs\doc documentation files (contains only subdirectories) \ecs\help .hlp files \ecs\install installation files (contains subdirectories) \ecs\lang national language support \ecs\system essential system binaries (contains only subdirectories) NOTE: \ecs\bin and \ecs\system both contain essential binaries but they are for very different purposes. \ecs\system contains only directories that hold files related to large complex packages, while \ecs\bin is for standalone system utilities. There is no implied GUI/CLI split; a CLI ini file editor and backup program can be a large complex package which should be located in \ecs\system, while a GUI volume manager could be a standalone binary located in \ecs\bin. The \programs directory shall contain only subdirectories which in turn will contain the files and subdirectories specific to a particular application. As an example: \programs\mozilla would contain the static executable files required to run Mozilla. The \home directory shall contain only subdirectories which in turn will contain the files and subdirectories specific to a particular user. As an example: \home\\mozilla would contain the variable configuration and data files created and used by Mozilla. The \var directory shall contain the following directories: \var\cfg application configuration files that contain data not specific to an individual user \var\log .log files (no subdirectories allowed) \var\temp temporary files (no subdirectories allowed) Each directory listed above is specified in detail in separate subsections below. 3.4 \ecs\bin : Essential user command binaries (for use by all users) 3.4.1 Purpose \ecs\bin contains commands that may be used by both the system administrator and by users. It may also contain commands which are used indirectly by scripts. 3.4.2 Requirements There must be no subdirectories in \ecs\bin. \ecs\bin must be included in the SET PATH statement in CONFIG.SYS. The following commands are required in \ecs\bin. cpu.exe Utility to report the number of processors installed memory.exe Utility to report the amount of memory installed resetwps.exe Utility to restart the WorkPlace Shell unzip.exe The unzip unarchiving utility zip.exe The zip archiving utility ...add additional utilities here as required BEGIN RATIONALE The requirement for a minumum set of system utilities to perform various maintenance and troubleshooting functions is vital to the capability to keep the system operating as desired. END RATIONALE 3.5 ecs\boot : Static device driver files 3.5.1 Purpose This directory contains device drivers with the exception of device drivers that must be located elsewhere such as BASEDEV drivers which must be located in "\" or "\os2\boot". 3.5.2 Requirements Device driver loading: A clean boot is desirable. Default driver operation will be Quiet mode (/Q). There are three situations where a driver may temporarily pause the boot process and post a message: 1) If registration is pending. 2) If the driver detects a problem during boot and needs to post a warning or error message. 3) If the user tells the driver to post information by adding the /V (Verbose) parameter to the driver in the config.sys file. /* various missing parts here */ 3.7 config.sys : Host-specific system configuration 3.7.1 Purpose config.sys contains the basic configuration information that is specific to a system. It is necessary that we define certain mandatory entries: SET OSDIR=x:\ecs SET HOME=x:\home\ SET PROGRAMS=x:\programs SET LOGFILES=x:\var\log SET TMP=x:\var\temp SET TEMP=x:\var\temp SET TMPDIR=x:\var\temp SET USER_INI=x:\home\\cfg\os2.ini It is also necessary that we define certain programming guidelines: - Programs/utilities that create log files should check to see if LOGFILES is set and use it if it is. If LOGFILES is not set or the directory doesn't exist then log files should not be created. Log file names should follow this example: .log - estyler.log - Programs/utilities that use ini files to store configuration information should check SET USER_INI= and use this directory to store ini files. Ini files should follow this example: .ini - estyler.ini. An example of the location: SET USER_INI=x:\home\stjohnb\cfg\os2.ini eStyler would then locate estyler.ini as such: x:\home\stjohnb\cfg\estyler.ini - Programs/utilities should always check to see if their ini exists and if it doesn't exist then a new one with reasonable defaults should be created. INI files should be standard OS/2 style binary INI files. - Programs/utilities should not make modifications to CONFIG.SYS with the exception of adding required device drivers nor should they use os2.ini to store settings. **= Email 5 ==========================** Date: Mon, 14 Apr 2003 19:56:32 -0700 (PDT) From: "Steve Wendt" Subject: Re: eFDS-1.TXT On Mon, 14 Apr 2003 22:52:16 -0300, Nicky Morrow wrote: >> \var\log .log files (no subdirectories allowed) >> \var\temp temporary files (no subdirectories allowed) >> >>You can't very well place this "no subdirectories allowed" restriction on >>variable data. Sometimes it makes perfect sense to use a subdirectory. > >Give me a good example please. 1) Installers routinely create a subdirectory to create all of their temporary files, and then will wipe out the entire subdirectory. That way, they don't need to delete individual files. 2) Some programs generate multiple log files, and thus use a subdirectory to contain all of them (mailman, for example). I'm sure there are countless examples people could come up with... ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 6 ==========================** Date: Mon, 14 Apr 2003 22:52:16 -0300 From: Nicky Morrow Subject: Re: eFDS-1.TXT Steve Wendt wrote: >>- If something is stupid, tell me why it is stupid and what the proper >>solution is. >> >> > > \var\log .log files (no subdirectories allowed) > \var\temp temporary files (no subdirectories allowed) > >You can't very well place this "no subdirectories allowed" restriction on >variable data. Sometimes it makes perfect sense to use a subdirectory. > Give me a good example please. Regards, Nick **= Email 7 ==========================** Date: Mon, 14 Apr 2003 23:43:00 +0200 From: Andreas Buening Subject: Re: Newbie Nicky Morrow wrote: [eCS File and Directory Standard] > We are trying to set some standards > for folks to follow in order to ease system administration. This sounds like a great idea. [snip] > Anyway, if anyone here is interested in seeing the document in its > current form please let me know and I'll email a copy to you. Please, could you post this on this list, if it isn't a nn MB file? Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie.