From e1e0ac22b2e7d4ff38b5d665cc0fa893a3de4d37 Mon Sep 17 00:00:00 2001 From: "Todd C. Miller" Date: Mon, 14 Jun 2010 14:56:45 -0400 Subject: [PATCH] Remove obsolete porting guide --- MANIFEST | 1 - doc/PORTING | 85 ----------------------------------------------------- 2 files changed, 86 deletions(-) delete mode 100644 doc/PORTING diff --git a/MANIFEST b/MANIFEST index 6fa65bffa..902135c86 100644 --- a/MANIFEST +++ b/MANIFEST @@ -52,7 +52,6 @@ configure.in doc/HISTORY doc/LICENSE doc/Makefile.in -doc/PORTING doc/TROUBLESHOOTING doc/UPGRADE doc/sample.pam diff --git a/doc/PORTING b/doc/PORTING deleted file mode 100644 index 861e0c03e..000000000 --- a/doc/PORTING +++ /dev/null @@ -1,85 +0,0 @@ -Sudo porting hints -================== - -Before trying to port sudo to a new architecture, please join the -sudo-workers mailing list (see the README file) and ask if anyone -has a port working or in-progress. Sudo should be fairly easy to -port. Since it uses a configure script, most of the work is often -done for you. As long as your operating system is reasonably POSIX -compliant porting should be easy. If your operating system has a -separate library for POSIX compatibility you may need to add it by -using configure's --with-libraries option. - -If your OS is an SVR4 derivative (or some approximation thereof), it may -be sufficient to tell configure you are runnng SVR4, something like: - configure foo-bar-sysv4 -where foo is the hardware architecture and bar is the vendor. - -A possible pitfall is getdtablesize(2) which is used to get the -maximum number of open files the process can have. If an OS has -the POSIX sysconf(2) it will be used instead of getdtablesize(2). -ulimit(2) or getrlimit(2) can also be used on some OS's. If all -else fails you can use the value of NOFILE in . - -Sudo tries to clear the environment of dangerous environment variables -such as LD_* to prevent shared library spoofing. If you are porting -sudo to a new OS that has shared libraries you'll want to mask out -the variables that allow one to change the shared library path. -See initial_badenv_table() in env.c to see how this is done for -various operating systems. - -It is possible that on a really weird system, tgetpass() may not -compile. (The most common cause for this is that the "fd_set" type -is not defined in a place that sudo expects it to be. If you can -find the header file where "fd_set" is typedef'd, have tgetpass.c -include it and send in a bug report.) -Alternately, tgetpass.c may compile but not work (nothing happens -at the Password: prompt). It is possible that your C library -contains a broken or unusable crypt() function--try linking with --lcrypt if that exists. Another possibility is that select() is -not fully functional; running configure with --with-password-timeout=0 -will disable the use of select(). If sudo prompts you for a -password but never accepts it, see below. - -Sudo detects and recognizes most common shadow password schemes -automatically. If you find that sudo is not accepting your password -and you are sure that it has been typed in correctly there are two -likely problems. One possibility is that your C library has a -broken crypt() function (see above). The other is that your operating -system is using shadow passwords and sudo has not detected that -fact. Look in config.h to see what, if any, shadow password scheme -was detected. The most common are SVR4 (HAVE_GETSPNAM will be -defined) and SecureWare (HAVE_GETPRPWNAM will be defined). Check -the manual pages on your system for "getspnam" and "getprpwnam". -If one of those exist but the appropriate define does not exist in -config.h then the problem is most likely that those routines live -in a library that sudo does not know to link against. The manual -page should tell you what library this is. You can then use the ---with-libraries option to configure to tell sudo to link with the -library in question. For example: - --with-libraries='-lgen' -would cause sudo to link in libgen which contains "getspnam" on SCO -systems. - -If you are trying to port to a system without standard Berkeley -networking you may find that interfaces.c will not compile. This -is most likely on OS's with STREAMS-based networking. It should -be possible to make it work by modifying the ISC streams support -(see the _ISC #ifdef's). However, if you don't care about ip address -and network address support, you can just run configure with the ---without-interfaces flag to get a do-nothing load_interfaces() -stub function. - -Sudo wants POSIX signals (sigaction and friends). If your system -lacks sigaction but has the 4.3BSD sigvec() function, sigvec() will -be used instead via the wrapper functions in sigaction.c. It is -not currently possible to use the old SVR3 and 4.2BSD signals, but -this is due more to my lack of a test machine than anything else. - -If you port sudo to a new architecture, please send the output of -"configure", the config.log file and your changes to: - sudo@courtesan.com - -If you are unable to get sudo working, and you are willing to -give me an account on a machine, send mail to sudo@courtesan.com. -Note, however, that I can't make any promises. -- 2.50.0