procps
Following the recent introduction of /proc to Cygwin, I have ported the Linux procps utilities to Cygwin. This is my first package submission, so please don't flame me too hotly if I've done something wrong. .tar.bz2's and setup.hint can be found here: http://www.doc.ic.ac.uk/~ccj00/procps-010801/ setup.hint: sdesc: "Utilities for monitoring your system and processes on your system." ldesc: "The procps package contains a set of system utilities which provide system information. Procps includes ps, free, sysctl, skill, snice, tload, top, uptime, vmstat, w, and watch. The ps command displays a snapshot of running processes. The top command provides a repetitive update of the statuses of running processes. The free command displays the amounts of free and used memory on your system. Sysctl is a simple program for managing system configuration entries. The skill command sends a terminate command (or another specified signal) to a specified set of processes. The snice command is used to change the scheduling priority of specified processes. The tload command prints a graph of the current system load average to a specified tty. The uptime command displays the current time, how long the system has been running, how many users are logged on and system load averages for the past one, five and fifteen minutes. The w command displays a list of the users who are currently logged on and what they're running. The watch program watches a running program. The vmstat command displays virtual memory statistics about processes, memory, paging, block I/O, traps and CPU activity." skip: category: System requires: cygwin libncurses6
RE: Setup: capturing postinstall output
Sorry about the wacky line breaks--I'll provide the un-broken patch upon
request, although it should be pretty easy to fix up.
- Bradey
-Original Message-
From: Bradey Honsinger
Sent: Wednesday, June 26, 2002 5:37 PM
To: '[EMAIL PROTECTED]'
Subject: Setup: capturing postinstall output
Being able to run package-specific postinstall scripts is pretty nifty, but
one drawback is that the output of those scripts is lost. It flickers by in
console windows as setup finishes, but that's pretty much unreadable, at
least
on my system. Since some packages (like apache-mod*) aren't really installed
unless their postinstall script succeeds--and the only way to tell whether
it
succeeded is by looking at the output--this is kind of a problem.
I searched the list for "postinstall output" and "postinstall log" and
didn't
find anything, so I decided to have a go at it myself. Given the complexity
of redirecting child processes' stdin/stdout/stderr using Win32[1], it
seemed
like the simplest solution was to make bash do the redirection, so I wrote a
little script and patched setup to call it instead of running the
postinstall scripts directly. It's a little less cool than the current
implementation--no opportunity to use the Visitor pattern!--but to my
Unix-centric mind, it seems just as elegant.
The script is pretty simple:
#!/bin/sh
# This is /tmp/run-postinstall.sh
{
for file in /etc/postinstall/*.sh
do
echo "Running $file:"
sh $file
mv $file $file.done
echo "--"
done
} > /var/log/postinstall.log 2>&1
The patch (which is against setup-2.249.2.4, not the tip) is included below.
It worked for me with an existing Cygwin 1.3.10 install and the script above
in /tmp/run-postinstall.sh (although I had to make some minor changes to get
setup to build). I haven't yet tried it with a 'clean' install. YMMV.
There are a couple of considerations:
- This script doesn't run .bat files, while the current code does.
The only .bat postinstall script that I saw was passwd-grp.bat (and I
installed pretty much everything). There's nothing in passwd-grp.bat
that
can't go in a shell script, so I just renamed it passwd-grp.sh (this is
included in the patch). Not allowing .bat postinstalls would, of course,
have to be a well-considered policy change by whoever considers these
things.
- The run-postinstall.sh script has to come from somewhere. Since there
isn't
a mandatory 'setup' package that could contain it, we'd either have to
make
one or write it out from code (like passwd-grp.sh in desktop.cc).
- This doesn't really solve the problem of failed postinstall scripts. It
would be nice to require postinstall scripts to exit non-zero if they
fail,
and then have setup notify the user. This script does at least allow the
user to _detect_ that a postinstall script failed, though, which is a
start.
- Bradey
[1] Look at
to see how to redirect a child process's standard input and output using the
Win32 API.
diff -ruN setup-2.249.2.4/setup-0/desktop.cc
setup-2.249.2.4-capture-postinstall-output/setup-0/desktop.cc
--- setup-2.249.2.4/setup-0/desktop.cc 2002-05-12 04:28:22.0 -0700
+++ setup-2.249.2.4-capture-postinstall-output/setup-0/desktop.cc
2002-06-26 16:49:03.0 -0700
@@ -278,7 +278,7 @@
static void
make_passwd_group ()
{
- String fname = cygpath ("/etc/postinstall/passwd-grp.bat");
+ String fname = cygpath ("/etc/postinstall/passwd-grp.sh");
io_stream::mkpath_p (PATH_TO_FILE, String("file://") + fname);
if ((uexists ("/etc/passwd") || uexists ("/etc/passwd.lnk"))
@@ -304,9 +304,9 @@
if (!p)
return;
if (!(uexists ("/etc/passwd") || uexists ("/etc/passwd.lnk")))
-fprintf (p, "bin\\mkpasswd -l > etc\\passwd\n");
+fprintf (p, "bin/mkpasswd -l > etc/passwd\n");
if (!(uexists ("/etc/group") || uexists ("/etc/group.lnk")))
-fprintf (p, "bin\\mkgroup -l > etc\\group\n");
+fprintf (p, "bin/mkgroup -l > etc/group\n");
fclose (p);
}
diff -ruN setup-2.249.2.4/setup-0/postinstall.cc
setup-2.249.2.4-capture-postinstall-output/setup-0/postinstall.cc
--- setup-2.249.2.4/setup-0/postinstall.cc 2002-05-18
20:07:52.0 -0700
+++ setup-2.249.2.4-capture-postinstall-output/setup-0/postinstall.cc
2002-06-26 16:30:52.0 -0700
@@ -22,32 +22,14 @@
#endif
#include "dialog.h"
-#include "find.h"
#include "mount.h"
#include "script.h"
-#include "FindVisitor.h"
-class RunFindVisitor : public FindVisitor
-{
-public:
- RunFindVisitor (){}
- virtual void visitFile(String const &basePath, const WIN32_FIND_DATA
*theFile)
-{
- run_script ("/etc/postinstall/", theFile->cFileName);
-}
- virtual ~ RunFindVisitor () {}
-protected:
- RunFindVisitor (RunFindVisitor const &);
-
Setup: capturing postinstall output
Being able to run package-specific postinstall scripts is pretty nifty, but
one drawback is that the output of those scripts is lost. It flickers by in
console windows as setup finishes, but that's pretty much unreadable, at
least
on my system. Since some packages (like apache-mod*) aren't really installed
unless their postinstall script succeeds--and the only way to tell whether
it
succeeded is by looking at the output--this is kind of a problem.
I searched the list for "postinstall output" and "postinstall log" and
didn't
find anything, so I decided to have a go at it myself. Given the complexity
of redirecting child processes' stdin/stdout/stderr using Win32[1], it
seemed
like the simplest solution was to make bash do the redirection, so I wrote a
little script and patched setup to call it instead of running the
postinstall scripts directly. It's a little less cool than the current
implementation--no opportunity to use the Visitor pattern!--but to my
Unix-centric mind, it seems just as elegant.
The script is pretty simple:
#!/bin/sh
# This is /tmp/run-postinstall.sh
{
for file in /etc/postinstall/*.sh
do
echo "Running $file:"
sh $file
mv $file $file.done
echo "--"
done
} > /var/log/postinstall.log 2>&1
The patch (which is against setup-2.249.2.4, not the tip) is included below.
It worked for me with an existing Cygwin 1.3.10 install and the script above
in /tmp/run-postinstall.sh (although I had to make some minor changes to get
setup to build). I haven't yet tried it with a 'clean' install. YMMV.
There are a couple of considerations:
- This script doesn't run .bat files, while the current code does.
The only .bat postinstall script that I saw was passwd-grp.bat (and I
installed pretty much everything). There's nothing in passwd-grp.bat
that
can't go in a shell script, so I just renamed it passwd-grp.sh (this is
included in the patch). Not allowing .bat postinstalls would, of course,
have to be a well-considered policy change by whoever considers these
things.
- The run-postinstall.sh script has to come from somewhere. Since there
isn't
a mandatory 'setup' package that could contain it, we'd either have to
make
one or write it out from code (like passwd-grp.sh in desktop.cc).
- This doesn't really solve the problem of failed postinstall scripts. It
would be nice to require postinstall scripts to exit non-zero if they
fail,
and then have setup notify the user. This script does at least allow the
user to _detect_ that a postinstall script failed, though, which is a
start.
- Bradey
[1] Look at
to see how to redirect a child process's standard input and output using the
Win32 API.
diff -ruN setup-2.249.2.4/setup-0/desktop.cc
setup-2.249.2.4-capture-postinstall-output/setup-0/desktop.cc
--- setup-2.249.2.4/setup-0/desktop.cc 2002-05-12 04:28:22.0 -0700
+++ setup-2.249.2.4-capture-postinstall-output/setup-0/desktop.cc
2002-06-26 16:49:03.0 -0700
@@ -278,7 +278,7 @@
static void
make_passwd_group ()
{
- String fname = cygpath ("/etc/postinstall/passwd-grp.bat");
+ String fname = cygpath ("/etc/postinstall/passwd-grp.sh");
io_stream::mkpath_p (PATH_TO_FILE, String("file://") + fname);
if ((uexists ("/etc/passwd") || uexists ("/etc/passwd.lnk"))
@@ -304,9 +304,9 @@
if (!p)
return;
if (!(uexists ("/etc/passwd") || uexists ("/etc/passwd.lnk")))
-fprintf (p, "bin\\mkpasswd -l > etc\\passwd\n");
+fprintf (p, "bin/mkpasswd -l > etc/passwd\n");
if (!(uexists ("/etc/group") || uexists ("/etc/group.lnk")))
-fprintf (p, "bin\\mkgroup -l > etc\\group\n");
+fprintf (p, "bin/mkgroup -l > etc/group\n");
fclose (p);
}
diff -ruN setup-2.249.2.4/setup-0/postinstall.cc
setup-2.249.2.4-capture-postinstall-output/setup-0/postinstall.cc
--- setup-2.249.2.4/setup-0/postinstall.cc 2002-05-18
20:07:52.0 -0700
+++ setup-2.249.2.4-capture-postinstall-output/setup-0/postinstall.cc
2002-06-26 16:30:52.0 -0700
@@ -22,32 +22,14 @@
#endif
#include "dialog.h"
-#include "find.h"
#include "mount.h"
#include "script.h"
-#include "FindVisitor.h"
-class RunFindVisitor : public FindVisitor
-{
-public:
- RunFindVisitor (){}
- virtual void visitFile(String const &basePath, const WIN32_FIND_DATA
*theFile)
-{
- run_script ("/etc/postinstall/", theFile->cFileName);
-}
- virtual ~ RunFindVisitor () {}
-protected:
- RunFindVisitor (RunFindVisitor const &);
- RunFindVisitor & operator= (RunFindVisitor const &);
-};
-
void
do_postinstall (HINSTANCE h, HWND owner)
{
next_dialog = 0;
init_run_script ();
SetCurrentDirectory (get_root_dir ().cstr_oneuse());
- RunFindVisitor myVisitor;
- String postinst = cygpath ("/etc/postinstall");
- Fin
Re: User URLs in setup.exe
On Thu, Jun 27, 2002 at 06:27:36AM +1000, Robert Collins wrote:
> I always like patches. As for the right thing, how does this sound:
> For all urls (i.e. no special cases);
> Show one of:
> * a friendly path provided in the mirrors.lst or last-mirror files.
> * the entire path
It sounds very good to me! So add syntax (or just more parsing because
it's already there?) to mirrors.lst so setup.exe could display stuff
like
http://foonet.no (Norway)
Cool :-).
I'm not sure how the friendly extra information would get into
last-mirror though. If a last-mirror is from mirrors.lst then you've
got the information in mirrors.lst anyway, and otherwise it's a User URL
and you'd have to get the user to type it in, which seems over-the-top.
That change seems like something easily big enough for HEAD, and
probably it'd be over the threshold that I'd need to be copyright-
assigned. That's doable, but it'll take time of course.
In the meantime, we have what I think is a serious UI bug in the 2002-06
branch: people can't correct typos in User URLs without manipulating
last-mirror in a way that needs some expertise.
One way to fix that would be to change #3 (as defined in my previous
posting) so that adding an URL that happens to have the same key as an
existing one *does* overwrite it. I think [1] the following surprisingly
simple patch achieves this:
--- site.cc.origThu Jun 27 02:09:10 2002
+++ site.cc Thu Jun 27 02:24:41 2002
@@ -409,6 +409,7 @@ bool SitePage::OnMessageCmd (int id, HWN
if (&listobj != newsite)
{
// That site was already registered
+ listobj = *newsite;
delete
newsite;
}
>> There is also the question of whether setup User URLs should be
>> susceptible to trailing slashes and spaces. Here's a (ugly and
>> untested) patch that strips trailing spaces:
>
> I think this is the wrong thing to do. Us users shouldn't need to
> understand url encoding, which is why trailing '/'s and spaces are
> currently preserved. (because http://foo.com/cygwin//setup.ini is a
> valid URL different from http://foo.com/cygwin/setup.ini).
Sure it's valid, and I agree with you, but to be really convincing
you'd have to demonstrate a situation in which someone actually *wanted*
that :-). It's a UI question: what proportion of the times that a user
types a trailing space or slash (so ends up with "[...]//setup.ini") do
they actually *intend* to do that?
For example, at the moment I'm getting real live bug reports because
morons insist on typing in "http://prc-tools.sourceforge.net/install/";
and "[...]/install//setup.ini" doesn't exist.
However, it occurs to me that the real solution to that is not to muck
with setup.exe, but for me to play more games with HTTP redirection on
my server. So that's fine.
John
[1] This is just a gedankenexperiment; I still haven't got around to
building setup.exe myself :-(
wget-1.8.1-1 postinstall script bug
The wget-1.8.1-1 package's postinstall script tries to copy tries to copy sample.wgetrc from /usr/doc/wget-1.8.1-1, which doesn't exist, instead of from /usr/doc/wget-1.8.1, which does. Again, not a big deal, but it wouldn't hurt to fix it. There's a patch below with what appeared to me to be the simplest fix. I can provide an updated package file if necessary, but I figured it'd be best to give the package maintainer first crack at it. - Bradey diff -ruN wget-1.8.1-1/etc/postinstall/wget.sh wget-1.8.1-1-fixed/etc/postinstall/wget.sh --- wget-1.8.1-1/etc/postinstall/wget.sh2002-06-26 14:07:07.0 -0700 +++ wget-1.8.1-1-fixed/etc/postinstall/wget.sh 2002-06-26 14:08:59.0 -0700 @@ -1,6 +1,6 @@ #!/bin/sh -VERSION=1.8.1-1 +VERSION=1.8.1 INFODIR=/usr/info INSTALLINFO=/usr/bin/install-info
enscript-1.6.3-2 postinstall script bug
The enscript-1.6.3-2 package's postinstall script tries to copy /etc/enscript.cfg.default to /etc/enscript/cfg instead of /etc/enscript.cfg, which doesn't work so well. Not a big deal, but it wouldn't hurt to fix it. There's a patch below; I can provide an updated package file if necessary, but I figured it'd be best to give the package maintainer first crack at it. - Bradey diff -ruN enscript-1.6.3-2/etc/postinstall/enscript.sh enscript-1.6.3-2-fixed/etc/postinstall/enscript.sh --- enscript-1.6.3-2/etc/postinstall/enscript.sh2002-04-16 11:52:33.0 -0700 +++ enscript-1.6.3-2-fixed/etc/postinstall/enscript.sh 2002-06-26 13:57:11.0 -0700 @@ -10,5 +10,5 @@ fi if [ ! -e /etc/enscript.cfg ] ; then - cp /etc/enscript.cfg.default /etc/enscript/cfg + cp /etc/enscript.cfg.default /etc/enscript.cfg fi
Re: New setup snapshot and changes
Robert Collins wrote: > I've uploaded a new setup.exe snapshot. It's got some major parsing > changes... I don't think I've broken anything, but I'd appreciate > feedback :}. I have noticed that some 3rd party ini files fail to parse > - (prc-tools and cygutils specifically) News to me. I eat my own dog food -- and it works fine... --Chuck
Re: New setup snapshot and changes
- Original Message - From: "Robert Collins" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 27, 2002 7:54 AM Subject: New setup snapshot and changes > I've uploaded a new setup.exe snapshot. It's got some major parsing > changes... I don't think I've broken anything, but I'd appreciate > feedback :}. I have noticed that some 3rd party ini files fail to parse > - (prc-tools and cygutils specifically) but not all - and I'm looking > into that now. I needed to commit what I have however, as it was getting > to the 'too large to ever commit' stage. Actuall, it looks like the only breakage is on the kde-cygwin setup.ini file. Hmm, Rob
Re: New setup snapshot and changes
On Thu, 27 Jun 2002 07:54:05 +1000 Robert Collins <[EMAIL PROTECTED]> wrote: > I've uploaded a new setup.exe snapshot. It's got some major parsing > changes... I don't think I've broken anything, but I'd appreciate > feedback :}. I have noticed that some 3rd party ini files fail to parse > - (prc-tools and cygutils specifically) but not all - and I'm looking > into that now. I needed to commit what I have however, as it was getting > to the 'too large to ever commit' stage. Look for it in http://www.cygwin.com/setup-snapshots/ . -- Mac :}) ** I normally forward private questions to the appropriate mail list. ** Ask Smarter: http://www.tuxedo.org/~esr/faqs/smart-questions.html Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age.
New setup snapshot and changes
I've uploaded a new setup.exe snapshot. It's got some major parsing changes... I don't think I've broken anything, but I'd appreciate feedback :}. I have noticed that some 3rd party ini files fail to parse - (prc-tools and cygutils specifically) but not all - and I'm looking into that now. I needed to commit what I have however, as it was getting to the 'too large to ever commit' stage. Key changes: * Support for parsing a debian Releases file (named setup.ini/setup.bz2). This may allow greater reuse of existing tools for site maintainers. (Tested on a 7Mb unstable file). * Feedback on MD5 processing. * Feedback on parsing progress. The following syntax changes are parsed, but not used (yet) Versioned package lists for the following: Dependencies, pre-dependencies, suggestions, recommendations, conflicts, provisions. Different source packages to the binary - i.e. gettext and libgettext can explicitly share a single source package. John Marshall's user list feedback patch. If you want more info, see the changelog entry, it's only 120 odd lines :}. So please, hit on this test as hard as you can, I'm keen to see what y'all think. Rob
RE: User URLs in setup.exe
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of John Marshall > Sent: Thursday, 27 June 2002 4:22 AM > I'm not sure what the right fix is. I think probably #2 > above is right > (because if http://example.com appears twice in the list but the full > URLs behind them are different... that's confusing), but #1 and #3 are > wrong. I suspect displayed_url for an URL that you type in yourself > should be the full thing you typed, so that you can see it. (And then > #3 would no longer be an issue.) > > If others agree (and want me to back my words with actions :-)), I'll > send a patch to do this. I always like patches. As for the right thing, how does this sound: For all urls (i.e. no special cases); Show one of: * a friendly path provided in the mirrors.lst or last-mirror files. * the entire path And: * Use a pop-up box to show the entire path for -every- mirror. * And generate the unique key based on the entire path not the display path. > There is also the question of whether setup User URLs should be > susceptible to trailing slashes and spaces. Here's a (ugly and > untested) patch that strips trailing spaces: I think this is the wrong thing to do. Us users shouldn't need to understand url encoding, which is why trailing '/'s and spaces are currently preserved. (because http://foo.com/cygwin//setup.ini is a valid URL different from http://foo.com/cygwin/setup.ini). > If that turned out not to be a good idea, it might be worth making the > spaces visible in the error message, e.g. like this: Thanks, I'm checking these two changes in. Rob
User URLs in setup.exe
A few things are currently (2.249.2.4) interacting to make setup's
user interface for adding "User URLs" extremely susceptible to typos.
Suppose you have a bunch of packages living outside the usual set of
Cygwin mirrors, so you tell your users to add (random example :-))
http://prc-tools.sourceforge.net/install
to their list of mirror sites (i.e. on setup's site.cc page). Then
1. It gets listed as just "http://prc-tools.sourceforge.net"; so they
can't tell if they actually typed it all in correctly. While I think
hiding the details of the URL is good for the ones in mirrors.lst,
I'm not sure it's right for ones the users type in themselves.
2. The URL's unique key in all_site_list is (derived from) the
abbreviated one that's displayed, not the full URL.
3. If you type in another URL with the same key as one that's already in
the list (say you're trying to fix a suspected (and invisible! :-))
typo), your new URL will get discarded (!) instead of overwriting the
old one or appearing beside it (SitePage::OnMessageCmd, site.cc:418).
Example: Add "http://example.com/foo"; as a User URL. Now try to add
"http://example.com/bar";. To get the change to stick you have to either
manually delete /etc/setup/last-mirror and rerun setup, or ensure that
"http://example.com"; is not selected and quit setup (thus getting it out
of last-mirror) and rerun setup. Both of these are difficult to explain
to clueless newbies, especially ones who don't believe that they could
possibly have made a typo.
Dumb user #1 example: user types in
"http://prc-tools.sourceforge.net/install/";, which sadly doesn't work.
They get this error message:
Unable to retrieve setup.ini from http://prc-tools.sourceforge.net/install/
so with luck they can see that they need to retype it. So they try
again with "http://prc-tools.sourceforge.net/install"; and check it
*really carefully* before they press Add. Unfortunately they can check
it as much as they like; setup will ignore the change and they'll still
get the same error.
Dumb user #2 example: it turns out that instead of typing in the URL
above, many of the users cut&paste it from the instructions Web page,
which until today would often give them a trailing space. This would
lead to an error message that looks like this:
Unable to retrieve setup.ini from http://prc-tools.sourceforge.net/install
and they *really* couldn't tell what they'd done wrong! And similarly
trying to fix the invisible typo wasn't actually doing anything.
I'm not sure what the right fix is. I think probably #2 above is right
(because if http://example.com appears twice in the list but the full
URLs behind them are different... that's confusing), but #1 and #3 are
wrong. I suspect displayed_url for an URL that you type in yourself
should be the full thing you typed, so that you can see it. (And then
#3 would no longer be an issue.)
If others agree (and want me to back my words with actions :-)), I'll
send a patch to do this.
There is also the question of whether setup User URLs should be
susceptible to trailing slashes and spaces. Here's a (ugly and
untested) patch that strips trailing spaces:
Index: site.cc
===
RCS file: /cvs/cygwin-apps/setup/site.cc,v
retrieving revision 2.18
diff -u -p -r2.18 site.cc
--- site.cc 6 May 2002 14:40:41 - 2.18
+++ site.cc 26 Jun 2002 13:54:51 -
@@ -25,6 +25,7 @@ static const char *cvsid =
#include
#include
#include
+#include
#include
#include "dialog.h"
@@ -50,7 +51,13 @@ list < site_list_type, String, String::c
void
site_list_type::init (String const &newurl)
{
- url = newurl;
+ char *spaces = newurl.cstr();
+ char *space = spaces + strlen (spaces);
+ while (space > spaces && isspace (space[-1]))
+--space;
+ *space = '\0';
+ url = String (spaces);
+ delete[] spaces;
char *dots = newurl.cstr();
char *dot = strchr (dots, '.');
It might also be worth stripping trailing '/' characters; if some mirror
really needed to end in a space, you could presumably use %20 notation.
Comments? Me, I'm not particularly comfortable about changing what the
user typed in, but...
If that turned out not to be a good idea, it might be worth making the
spaces visible in the error message, e.g. like this:
Index: res.rc
===
RCS file: /cvs/cygwin-apps/setup/res.rc,v
retrieving revision 2.40
diff -u -p -r2.40 res.rc
--- res.rc 12 May 2002 11:28:22 - 2.40
+++ res.rc 26 Jun 2002 13:54:51 -
@@ -439,7 +439,7 @@ BEGIN
IDS_CYGWIN_FUNC_MISSING "Error: unable to find function `%s' in %s"
IDS_DOWNLOAD_SHORT "Download error: %s too short (%d, wanted %d)"
IDS_ERR_OPEN_WRITE "Can't open %s for writing: %s"
-IDS_SETUPINI_MISSING"Unable to get setup.ini from %s"
+IDS_SETUPINI_MISSING"Unable to get setup.ini from <%s>"
Re: TCP Wrappers
As you wish *grin* http://www.stonegard.com/cygwin/tcp_wrappers_7.6/tcp_wrappers-7.6-1-src.tar.bz2 http://www.stonegard.com/cygwin/tcp_wrappers_7.6/tcp_wrappers-7.6-1.tar.bz2 http://www.stonegard.com/cygwin/tcp_wrappers_7.6/setup.hint # TCP Wrappers sdesc: "TCP Wrappers, Tool to provide host based access restrictions in tcp services" ldesc: "TCP Wrappers, With this package you can monitor and filter incoming requests for the SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, TFTP, TALK, and other network services. The package provides tiny daemon wrapper programs that can be installed without any changes to existing software or to existing configuration files. The wrappers report the name of the client host and of the requested service; the wrappers do not exchange information with the client or server applications, and impose no overhead on the actual conversation between the client and server applications." category: Net requires: cygwin On Wed, 26 Jun 2002, Corinna Vinschen wrote: > On Wed, Jun 26, 2002 at 10:23:35AM -0400, Prentis Brooks wrote: > > Ok, the packages are now ready for someone to upload them to the > > distribution. Sorry for the delay, work and life intruded with a > > vengence. Let me know if there is anything still missing, I pretty > > much, just did as Charles Wilson suggested (thanks for the script > > Charles). I will be working with trying to get a DLL version done, > > hopefully sooner than I got to this. > > > > Packages can be found at the following location: > > > > http://www.stonegard.com/cygwin/tcp_wrappers_7.6/ > > Please send the full paths to the files and the full content of your > setup.hint file to this list. > > Thanks, > Corinna > > -- Prentis Brooks | [EMAIL PROTECTED] | 703-265-0914 | AIM: PrentisBrooks Senior System Administrator - Web Infrastructure & Security A knight is sworn to valor. His heart knows only virtue. His blade defends the helpless. His word speaks only truth. His wrath undoes the wicked. - the old code of Bowen, last of the dragonslayers
Re: TCP Wrappers
On Wed, Jun 26, 2002 at 10:23:35AM -0400, Prentis Brooks wrote: > Ok, the packages are now ready for someone to upload them to the > distribution. Sorry for the delay, work and life intruded with a > vengence. Let me know if there is anything still missing, I pretty > much, just did as Charles Wilson suggested (thanks for the script > Charles). I will be working with trying to get a DLL version done, > hopefully sooner than I got to this. > > Packages can be found at the following location: > > http://www.stonegard.com/cygwin/tcp_wrappers_7.6/ Please send the full paths to the files and the full content of your setup.hint file to this list. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
TCP Wrappers
Ok, the packages are now ready for someone to upload them to the distribution. Sorry for the delay, work and life intruded with a vengence. Let me know if there is anything still missing, I pretty much, just did as Charles Wilson suggested (thanks for the script Charles). I will be working with trying to get a DLL version done, hopefully sooner than I got to this. Packages can be found at the following location: http://www.stonegard.com/cygwin/tcp_wrappers_7.6/ -- Prentis Brooks | [EMAIL PROTECTED] | 703-265-0914 | AIM: PrentisBrooks Senior System Administrator - Web Infrastructure & Security A knight is sworn to valor. His heart knows only virtue. His blade defends the helpless. His word speaks only truth. His wrath undoes the wicked. - the old code of Bowen, last of the dragonslayers
