Re: waiting for new files in a directory
Any ideas on how to do this? Any suggestions on the process?
Simple lock (like flock(3)) in the perl script. Lock some ${FILE},
and if you can't get the lock, die. The file should contain the PID
of the process that holds the lock, so that a cleanerd can kill
stuck processes, or so that the lock can be blown away if needed.
Works like a charm.
M
--
Mark Murray
Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On 27 Dec 2000, at 10:11, Mark Murray wrote:
Any ideas on how to do this? Any suggestions on the process?
Simple lock (like flock(3)) in the perl script. Lock some ${FILE},
and if you can't get the lock, die. The file should contain the PID
of the process that holds the lock, so that a cleanerd can kill
stuck processes, or so that the lock can be blown away if needed.
Works like a charm.
Thanks Mark. But what part of the solution does flock solve?
I'm not sure if my lack of comprehension stems from my initial
description being inadequete or my knowledge being too narrow.
--
Dan Langille
The FreeBSD Diary - http://freebsddiary.org/
FreshPorts - http://freshports.org/
NZ Broadband - http://unixathome.org/broadband/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
On Tue, Dec 26, 2000 at 07:45:36AM -0800, [EMAIL PROTECTED] wrote: If I read what you are saying, and please correct me if I'm wrong, you are saying "the original keys were never .". Which original keys are you talking about? Are you saying that the original SSH Public Keys for the servers were always sent in the clear, without PGP signature or anything? Is this correct? Does this, even remotely, have *anything* to do with the original posting that started this thread? Guys. Please stop this. "If I read what you are saying ..." and then a new thread starts all over. Oh, come on. Is this thread still proper for -hackers? Will we kill it some day? - giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On Wed, Dec 27, 2000 at 08:49:51PM +1300, Dan Langille wrote: FreshPorts2 will have a new processing strategy for incoming messages. Each message will be in a separate file in a predetermined directory. As each file arrives, it is processed by a perl script. I want only one instance of that perl script running at a given time. This is primarily for serialization and to ensure the system doesn't get bogged down running perl scripts if many messages arrive in a short period of time. My idea is to have a daemon, or something resembling one, sitting on the box watching the directory. When a new file appears, it starts a perl script. This perl script is beyound the scope of my question, but it processes all the files in the directory. When finished, it looks for any more files and repeats as necessary. If no more files, it exits. If a file arrives, the daemon checks to see if the perl script is already running. If so, it doesn't start another one. Any ideas on how to do this? Any suggestions on the process? I would do that (and have done it in several projects) using opendir() and readdir(). Open the directory, read entry by entry, when you find a file you want, process it and unlink() it. Get to the end of the dir, sleep, repeat. Beware of a subtle problem here though - see that you do not have the process which creates files creating them in that directory; you might very well wind up with a file being processed before it's fully created. There are two solutions to this problem - either DJB's Maildir style, or processing files based on filenames. DJB's Maildir concept is based on having two directories - a temporary one where files are created and then atomically move/rename'd to the real one. This works best when the tempdir and the real dir are located on the same filesystem, and you can use the rename() syscall. However, there is a solution if you want the temporary dir on another filesystem - there is a safecat program, which I shall shortly commit a port for (it's been sitting in my to-do tree for several weeks now). The other way is create the files in the same directory, but with a different name style, e.g. ending in .tmp; then when you readdir() an entry, only process those not ending in .tmp, or only process those ending in .xml, or something like that. This might be a bit easier to implement. G'luck, Peter -- If there were no counterfactuals, this sentence would not have been paradoxical. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On 27 Dec 2000, at 12:11, Peter Pentchev wrote: I would do that (and have done it in several projects) using opendir() and readdir(). Open the directory, read entry by entry, when you find a file you want, process it and unlink() it. Get to the end of the dir, sleep, repeat. Thanks for that. Do you have code I can use as a starting position? DJB's Maildir concept is based on having two directories - a temporary one where files are created and then atomically move/rename'd to the real one. This works best when the tempdir and the real dir are located on the same filesystem, and you can use the rename() syscall. At present the files are created through procmail like this: |/usr/bin/perl $HOME/process_cvs_mail.pl ~/msgs/$FILE I guess I could add a rename. cheers -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On 27 Dec 2000, at 10:11, Mark Murray wrote: [use flock(2)] But what part of the solution does flock solve? It solves the problem of finding out whether the Perl script is already running, but as I understood the original posting, this isn't what you were asking. See below. I'm not sure if my lack of comprehension stems from my initial description being inadequete or my knowledge being too narrow. Probably from it being a little confusing. Here's how I understand it. You have some program putting files in directory /x. You need something that will be notified when a new file appears in /x. That something then starts a Perl script to process the files. If you control the program that's putting files into /x, the easiest way would be to have it send a signal to your daemon. You can put its PID in a well-known file for it to look at. If, however, you don't control the program, you may have to resort to looking at the directory every now and then and checking for new files (``polling''). Depending on your application, this may or may not be acceptable. If you don't want to use polling, you might try fooling around with the select(2), poll(2), or kqueue(2) interfaces. The former two were designed to be used with regular files or sockets, but in unix, a directory is just a special type of file. I don't know how they'd react to it. In particular, the EVFILT_VNODE filter with the NOTE_EXTEND event/flag (notifies you when the file descriptor specified was extended) looks promising. Then again, I'm not a filesystem whiz, so this may all be nonsense. Hopefully I've at least interpreted your question correctly. Regards Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On Wed, Dec 27, 2000 at 11:17:47PM +1300, Dan Langille wrote:
On 27 Dec 2000, at 12:11, Peter Pentchev wrote:
I would do that (and have done it in several projects) using opendir()
and readdir(). Open the directory, read entry by entry, when you find
a file you want, process it and unlink() it. Get to the end of the dir,
sleep, repeat.
Thanks for that.
Do you have code I can use as a starting position?
Try the attached file, it works for me.
Btw, anybody reading this discussion - I tried the attached script with
#!/usr/bin/perl -wT, and Perl died on the unlink() - "unsafe dependency".
What gives?
DJB's Maildir concept is based on having two directories - a temporary
one where files are created and then atomically move/rename'd to
the real one. This works best when the tempdir and the real dir are
located on the same filesystem, and you can use the rename() syscall.
At present the files are created through procmail like this:
|/usr/bin/perl $HOME/process_cvs_mail.pl ~/msgs/$FILE
I guess I could add a rename.
Something like..
| /usr/bin/perl $HOME/process.pl ~/msgs/$FILE.tmp \
mv ~/msgs/$FILE.tmp ~/msgs/$FILE.cvs
..or alternatively, use safecat (which I shall commit real-soon-now), and..
| /usr/bin/perl process.pl | /usr/local/bin/safecat ~/msgs/tmpdir/ ~/msgs/
safecat takes two arguments - a temp dir and the real dir - reads stdin,
and stores it there.
G'luck,
Peter
--
What would this sentence be like if pi were 3?
#!/usr/bin/perl -w
# $Id: procdir.pl,v 1.1 2000/12/27 10:48:30 roam Exp $
use strict;
sub OnePass {
my $dir = (shift || "");
my ($fname, @files);
die("OnePass() requires a dir argument\n") if ($dir eq "");
opendir(D, $dir) or die("Opening $dir: $!\n");
@files = readdir(D);
closedir(D);
foreach $fname (@files) {
next if (($fname eq ".") || ($fname eq ".."));
# more filename vailidity checks go here
next unless $fname =~ /\.cvs$/;
# ok, we want this file
print "Processing $dir/$fname\n";
# done with it..
unlink("$dir/$fname") or warn("Removing $dir/$fname: $!\n");
# this is evil - if we could process it, but could not
# remove it, we might end up processing it again at the next
# iteration :(
}
}
sub ProcessDir {
my $dir = (shift || "");
die("ProcessDir() requires a dir argument\n") if ($dir eq "");
for (;;) {
OnePass($dir);
# this could be done with select(), with a signal handler,
# many different ways.. polling and sleep() is easy
sleep(2);
}
}
MAIN:{
# obtain directory name in some way
my $d = "/tmp";
ProcessDir($d);
# er heh.. this should never return :)
die("ProcessDir() returned?.. $!\n");
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On 27 Dec 2000, at 10:11, Mark Murray wrote:
Any ideas on how to do this? Any suggestions on the process?
Simple lock (like flock(3)) in the perl script. Lock some ${FILE},
and if you can't get the lock, die. The file should contain the PID
of the process that holds the lock, so that a cleanerd can kill
stuck processes, or so that the lock can be blown away if needed.
Works like a charm.
Mark and I have been msging offline and he's agreed to my posting the
results of our discussion:
Thanks Mark. But what part of the solution does flock solve?
It prevents more than one perl script from running. You can then
cron perl scripts to deal with the incoming, and not worry about
them jumping on each other.
Yes. That does make some things much easier. That's a very
simple solution.
I was looking for a gold-plated solution where messages are
processed right away. But it sounds too complicated. I guess
setting up a cron job to run every minute is fine.
The perl script looks like this:
flock a file, if it fails, die.
Write PID to flocked file.
Loop
Get oldest file in directory (file are named Y.m.d.h.m.s.PID)
process it
move file to archives
until no more files
Truncate file
unlock the file
The cleaner you mentioned: run it every 15 minutes, compare the
date/time on the lockfile, if more than 15 minutes old, grab the PID,
and kill the job, remove the lock.
Correct.
Thanks Mark.
--
Dan Langille
The FreeBSD Diary - http://freebsddiary.org/
FreshPorts - http://freshports.org/
NZ Broadband - http://unixathome.org/broadband/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On Wed, Dec 27, 2000 at 12:53:37PM +0200, Peter Pentchev wrote: Btw, anybody reading this discussion - I tried the attached script with #!/usr/bin/perl -wT, and Perl died on the unlink() - "unsafe dependency". What gives? $ man perldiag [snip] Insecure dependency in %s (F) You tried to do something that the tainting mechanism didn't like. The tainting mechanism is turned on when you're running setuid or setgid, or when you specify -T to turn it on explicitly. The tainting mechanism labels all data that's derived directly or indirectly from the user, who is considered to be unworthy of your trust. If any such data is used in a "dangerous" operation, you get this error. See the perlsec manpage for more information. [snip] Note that a filename you get from readdir is (indirectly) from the user, and unlink counts as dangerous. Basically, you need to "untaint" $fname in OnePass before using it in the unlink call; this is fairly trivial to do, and if you can't work it out from perlsec(1), feel free to contact me off-list. -- Mike Bristow, seebitwopie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On Wed, Dec 27, 2000 at 11:09:40AM +, Mike Bristow wrote:
On Wed, Dec 27, 2000 at 12:53:37PM +0200, Peter Pentchev wrote:
Btw, anybody reading this discussion - I tried the attached script with
#!/usr/bin/perl -wT, and Perl died on the unlink() - "unsafe dependency".
What gives?
$ man perldiag
[snip]
Insecure dependency in %s
(F) You tried to do something that the tainting
mechanism didn't like. The tainting mechanism is
turned on when you're running setuid or setgid, or
when you specify -T to turn it on explicitly. The
tainting mechanism labels all data that's derived
directly or indirectly from the user, who is
considered to be unworthy of your trust. If any such
data is used in a "dangerous" operation, you get this
error. See the perlsec manpage for more information.
[snip]
Note that a filename you get from readdir is (indirectly) from the
user, and unlink counts as dangerous.
Basically, you need to "untaint" $fname in OnePass before using it in
the unlink call; this is fairly trivial to do, and if you can't work it
out from perlsec(1), feel free to contact me off-list.
Whoops. Yup, thanks. Updated version attached.
G'luck,
Peter
--
Nostalgia ain't what it used to be.
#!/usr/bin/perl -wT
# $Id: procdir.pl,v 1.2 2000/12/27 11:16:38 roam Exp $
use strict;
sub OnePass {
my $dir = (shift || "");
my ($fname, @files);
die("OnePass() requires a dir argument\n") if ($dir eq "");
opendir(D, $dir) or die("Opening $dir: $!\n");
@files = readdir(D);
closedir(D);
foreach $fname (@files) {
next if (($fname eq ".") || ($fname eq ".."));
# more filename vailidity checks go here
# pattern filtering and subexpression to 'untaint'
next unless $fname =~ /^([\w\d._-]+\.cvs)$/;
$fname = $1;
# ok, we want this file
print "Processing $dir/$fname\n";
# done with it..
unlink("$dir/$fname") or warn("Removing $dir/$fname: $!\n");
# this is evil - if we could process it, but could not
# remove it, we might end up processing it again at the next
# iteration :(
}
}
sub ProcessDir {
my $dir = (shift || "");
die("ProcessDir() requires a dir argument\n") if ($dir eq "");
for (;;) {
OnePass($dir);
# this could be done with select(), with a signal handler,
# many different ways.. polling and sleep() is easy
sleep(2);
}
}
MAIN:{
# obtain directory name in some way
my $d = "/tmp";
ProcessDir($d);
# er heh.. this should never return :)
die("ProcessDir() returned?.. $!\n");
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On Wed, Dec 27, 2000 at 01:18:28PM +0200, Peter Pentchev wrote:
[snip..]
closedir(D);
foreach $fname (@files) {
next if (($fname eq ".") || ($fname eq ".."));
# more filename vailidity checks go here
^ validity.. *sigh* :P
# pattern filtering and subexpression to 'untaint'
next unless $fname =~ /^([\w\d._-]+\.cvs)$/;
$fname = $1;
G'luck,
Peter
--
Thit sentence is not self-referential because "thit" is not a word.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
AMD System Management driver and Newbus
First, sorry this is a bit long; I probably should have split it up, but
when I get going... Y'Know...
I've done some work on a driver for the SMBus functions of the AMD 756
chip found on K7-based motherboards, based on alpm.c from -CURRENT. This
works nicely on my system (Gigabyte GA7IXE-4 with Athlon 700MHz), but is
currently using old-style PCI shims. Since this is my first go at doing
anything in the FreeBSD kernel, I didn't realise that this was not a Good
Thing, so I've been trying to get it to work with Newbus; please see
below.
Anyway, for anyone who'd like to try the old-style compatability version,
please feel free to pull the diffs from:
http://www.3d-med.cse.dmu.ac.uk/~mcf/amdpm_oldpci.tar.gz
My newbus efforts are not going too well; specifically I'm having a hard
time with bus_alloc_resource, which refuses to allocate any I/O space for
me. I've tried all sorts of things, but it just won't work. If anyone can
spot anything idiotic I've done, please let me know; you may just save my
hair!
Here goes (BTW AMDPCI_PMBASE is a long which contains the base of I/O
space for the power management function of the AMD 756):
static int
amdpm_attach(device_t dev)
{
struct amdpm_softc *amdpm_sc = device_get_softc(dev);
u_long l;
int unit = device_get_unit(dev);
if (unit = NAMDPM) {
printf("amdpm%d: attach: only %d units configured.\n",
unit, NAMDPM);
return (0);
}
amdpm_sc = amdpmsoftc[unit];
/* Enable I/O. We must always do this with the AMD 756 for it to
allow
* us access.
*/
l = pci_read_config(dev, AMDPCI_GEN_CONFIG_PM, 2);
pci_write_config(dev, AMDPCI_GEN_CONFIG_PM, l | AMDPCI_PMIOEN, 2);
amdpm_sc-rid = AMDPCI_PMBASE;
amdpm_sc-pio = bus_alloc_resource(dev, SYS_RES_IOPORT,
amdpm_sc-rid,
0, ~0, 1, RF_ACTIVE);
if (!(amdpm_sc-pio)) {
device_printf(dev, "could not map i/o ports\n");
return (ENXIO);
}
amdpm_sc-smbst = rman_get_bustag(amdpm_sc-pio);
amdpm_sc-smbsh = rman_get_bushandle(amdpm_sc-pio);
/* XXX add the I2C interface to the root_bus until pcibus is ready
*/
device_add_child(root_bus, "amdsmb", unit);
return (0);
}
---
Matt
-
Dr. Matthew C. Forman
3D Medical Imaging Group,
De Montfort University, Leicester, UK.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: AMD System Management driver and Newbus
First, sorry this is a bit long; I probably should have split it up, but
when I get going... Y'Know...
Size is not a problem.
My newbus efforts are not going too well; specifically I'm having a hard
time with bus_alloc_resource, which refuses to allocate any I/O space for
me. I've tried all sorts of things, but it just won't work. If anyone can
spot anything idiotic I've done, please let me know; you may just save my
hair!
Don't go reaching for the toupe just yet; you've just made a few simple
mistakes...
Here goes (BTW AMDPCI_PMBASE is a long which contains the base of I/O
space for the power management function of the AMD 756):
static int
amdpm_attach(device_t dev)
{
struct amdpm_softc *amdpm_sc = device_get_softc(dev);
u_long l;
int unit = device_get_unit(dev);
if (unit = NAMDPM) {
printf("amdpm%d: attach: only %d units configured.\n",
unit, NAMDPM);
You can throw out 'NAMDPM' now, and any softc array you have, as well as
the 'count' entry in conf/files.
return (0);
}
amdpm_sc = amdpmsoftc[unit];
And you don't want this here, since you've already set the softc pointer
above.
/* Enable I/O. We must always do this with the AMD 756 for it to
allow
* us access.
*/
l = pci_read_config(dev, AMDPCI_GEN_CONFIG_PM, 2);
pci_write_config(dev, AMDPCI_GEN_CONFIG_PM, l | AMDPCI_PMIOEN, 2);
I'm assuming that AMDPCI_GEN_CONFIG_PM isn't just the command register,
correct?
amdpm_sc-rid = AMDPCI_PMBASE;
amdpm_sc-pio = bus_alloc_resource(dev, SYS_RES_IOPORT, amdpm_sc-rid,
0, ~0, 1, RF_ACTIVE);
Ok, here you come unstuck. The rid should be the offset of the base
address register in configuration space; probably PCIR_MAPS in this case.
/* XXX add the I2C interface to the root_bus until pcibus is ready
*/
device_add_child(root_bus, "amdsmb", unit);
... and you definitely don't want to do this. 8)
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
Just a comment on this... I used to work for a pretty big Unix OS vendor in the operating systems development group. 90% of the bug fixes I applied were never found by the QA group (otherwise they would have been fixed long before I ever worked there :-). Where they really found problems were cross-platform problems. E.g. I committed a change, tested it on platform X Y and it worked just fine. It failed to build on legacy platform Z. Building and testing on platform Z was near impossible, so as a developer, unless you were actually fixing a problem for platform Z, you never did it. After being bit a couple of times, I automated a script that did the cross-build, and never got bit again, but most people didn't do that. Heck, a major part of the QA group was dedicated to making sure the documentation was correct (not a bad thing, but it didn't help the actualy state of the software). Our -current works pretty much like the QA we had at this company. Most machines ran what we call -stable. All development machines (and there were a lot) ran -current, and a few ran a couple of releases back, just in case we had to fix something in that release. Knowing how many people actually run -current, I would say we have better testing than the OS company I worked for. Even though we don't have a real "QA" dept. -Mike On Thu, Dec 21, 2000 at 09:48:44AM -0800, SteveB wrote: Here's the thing about open software that still concerns me. My background is with the major software development tools companies, so that is my point of reference. It is great that code is available and fixes are made and pushed out, but who is doing real testing of these fixes. Sure the obvious problem is fixed, but what other problems has it uncovered, what side effect has it created, and how about compatibility with other software or drivers in this case. With commercial software (well at least the places I worked) nothing could go out the door without a complete QA cycle performed on it. Even the smallest of bug fixes couldn't be released without a QA cycle. A full QA cycle was time consuming and expensive, so fixes sat until there was a stack of them to QA'd as a group or they had to wait until next upgrade. That way we knew state of the product. Yes, the state of the product would include known bugs. The key was a known bug and a known documented bug was as valuable as a fix. Sure a bug is bad, but if it is documented you don't waste trying to make something work that is known to be broke. So who is testing these fixes in open source world? Just seeing if the problem at hand is gone isn't real testing, even claiming thousands of people are now using it isn't enough. There can still be lurking potentially data destroying bugs lurking. In the open source world is there a official QA process or group. Is there a FreeBSD test suite that releases go through. QA is unglamorous work, but needs to be done. Steve B. -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AMD System Management driver and Newbus
In message [EMAIL PROTECTED], "M atthew C. Forman" $B$5$s$$$o$/(B: First, sorry this is a bit long; I probably should have split it up, but when I get going... Y'Know... I've done some work on a driver for the SMBus functions of the AMD 756 chip found on K7-based motherboards, based on alpm.c from -CURRENT. This works nicely on my system (Gigabyte GA7IXE-4 with Athlon 700MHz), but is currently using old-style PCI shims. Since this is my first go at doing anything in the FreeBSD kernel, I didn't realise that this was not a Good Thing, so I've been trying to get it to work with Newbus; please see below. Anyway, for anyone who'd like to try the old-style compatability version, please feel free to pull the diffs from: http://www.3d-med.cse.dmu.ac.uk/~mcf/amdpm_oldpci.tar.gz My newbus efforts are not going too well; specifically I'm having a hard time with bus_alloc_resource, which refuses to allocate any I/O space for me. I've tried all sorts of things, but it just won't work. If anyone can spot anything idiotic I've done, please let me know; you may just save my hair! This driver seems to be based on alpm.c, and alpm.c is based on intpm.c intpm.c is now NEWBUS-ifyed. #Indeed, I was intended to write driver for Power Management part , #such as GPIO etc. So I divide the driver to PCI head and SMBus part. #But As reading through ACPI spec,I convinced that this should be treated #by ACPI fixed feature . $BEOJUB:5*(B $B?@8MBg3XBg3X1!+A32J3X85f2J(BD3$BpJs%a%G%#%"2J3X@l96(B a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html" Public Key/a Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
unlock the file The cleaner you mentioned: run it every 15 minutes, compare the date/time on the lockfile, if more than 15 minutes old, grab the PID, and kill the job, remove the lock. Correct. Actually, you can make it a lot better: If the lockfile exists, then kill -0 the PID to see if it is still live. If not, blow away the lockfile. If still alive and older than N minutes, blow away the PID and break the lock. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: waiting for new files in a directory
Dear All, What you'd really want is some kind of message queueing system for this kind of work. What message queueing systems are (non-commercially) available on UNIX systems? Kees Jan You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
At 01:16 PM 12/19/2000, John Baldwin wrote: We have a saying in Denmark, which I'm sure exist in as many forms as there are languages in the world: "A thief belive everybody steals." Dennis, considering the recorded history of your arguments in our mailing list archives, hearing you come out and praise closed source drivers for open source OS's rings very very hollow. did you even read my comments, you blubbering moron? lol. I said NOTHING about theft. Zero. I guess you dont read english very well. Umm. Dennis, there's this part of English called "figurative language". It involves things like similes, metaphors, etc. I suggest you go read up on it. Things like poetry, humor, etc. really depend on you understanding how it works. Even elementary school English classses in the U.S. cover such language basics. Mr Kamps comments are also "Well documented". I would think that EVERYONE on this list would be offended by his insinuation that anyone that uses FreeBSD and doesnt contribute source to FreeBSD is stealing. Where is that outcry on that ridiculous idea? If you are offended by people using your code then you should get out of the free source business. (haha, " business ", now thats a metaphor!) There are other ways to contribute than to contribute source. How many advertising dollars has Mr Kamp spent promoting the use of FreeBSD? Thousands of users use FreeBSD enhanced with our "contributions". We spend tens of thousands of dollars advertising them, indirectly advertising FreeBSD in the process. People buy products because they think that they are worth the price. The fact that so many people are willing to pay for the enhancements we provide is prima facia evidence of our contribution. Im sorry so few of you understand. Well, since you didn't get Poul's idiom, here's the native US version: "It takes one to know one." His point being that your claim that the original poster had lost all credibility in your judgement is rather hypocritical. It wasnt hypocritical. Anyone who selects an inferior product simply because it has source is more than un credible; hes a fool and an incompetent. I use both binary and source products. I use what is best. I pay for netware because it is better than NFS. I dont need source. It works. DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
At 05:14 PM 12/19/2000, you wrote: On Tue, Dec 19, 2000 at 12:25:43PM -0500, Dennis wrote: Am I a thief because my company provides value added solutions without source to our enhancements on a freebsd platform? If you are insulted that other people are using your work without paying for it then it sounds like you dont fit in very well with the "open source" community Mr. Kamp. This brings about a question I have been wondering about for quite some time: How do you submit binary-only code to the ports collection? I just re-read the porters' handbook, and it seems to be assuming that you will always release source code for everything. But I am thinking about porting some of my Windows software to FreeBSD, yet, I do not want to release the source code (since much of it is the same I *sell* to Windows users in binary-only form). Then again, I may decide not to do it: My latest port submission has been sitting in the GNATS database for months, so why bother submitting more when nobody cares anyway? Welcome to the Animal Farm THIS was my point about the FreeBSD camp particularly alienating binary vendors as to drive them away. The kernel make has been broken for yearsthe "fix it yourself" aka "tough sh*t" echo has been heard loud and clear. They dont want your stinking binary contributions. Get used to it. DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
* Dan Langille [EMAIL PROTECTED] [001226 23:50] wrote: My idea is to have a daemon, or something resembling one, sitting on the box watching the directory. When a new file appears, it starts a perl script. This perl script is beyound the scope of my question, but it processes all the files in the directory. When finished, it looks for any more files and repeats as necessary. If no more files, it exits. This isn't an answer to your main question (i see it's already been discussed), but you may be able to use setup a kevent on the directory which should inform you if any files are added to it. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On Wed, Dec 27, 2000 at 09:16:34AM -0800, Alfred Perlstein wrote: * Dan Langille [EMAIL PROTECTED] [001226 23:50] wrote: My idea is to have a daemon, or something resembling one, sitting on the box watching the directory. When a new file appears, it starts a perl script. This perl script is beyound the scope of my question, but it processes all the files in the directory. When finished, it looks for any more files and repeats as necessary. If no more files, it exits. This isn't an answer to your main question (i see it's already been discussed), but you may be able to use setup a kevent on the directory which should inform you if any files are added to it. Unfortunately, I gather that Dan intends to write most of the FreshPorts code in Perl, and AFAIK, Perl has no kqueue/kevent interface :( Thus, to make use of kevent (which I certainly agree would be a better FreeBSD-specific solution), he'd have to either 1. have a C program which spawns Perl and his script on every change, or 2. have a C program which spawns Perl once and signals it on every change. The first way would be downright stupid IMHO.. The second one may very well be more efficient than the readdir, sleep solution which I proposed in other postings, seeing that Dan wants to process the cvs-all mailings, which certainly do not arrive every few seconds :) As a side-point - does Perl really have a kqueue/kevent interface? If not, how hard would it be to write a litte Perl module to implement that? (Unfortunately, I am a complete stranger to Perl modules..) A Perl script which uses kevent to wait on a directory would certainly be more efficient than any of the above solutions :) G'luck, Peter -- I am jealous of the first word in this sentence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Silent FreeBSD
I've got that FreeBSD gateway in a corner at my house, it works fine dandy but the constant noise (whirring fans, hard drives) gets on my nerves. What solutions have people explored to quiet down a computer system? (actual experience will be preferred over wild speculations). I'm already aware of PicoBSD, but I need more storage than just a floppy. Has anybody experimented with RAM cards? How about noise-proof enclosures? --Renaud To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
On Wed, Dec 27, 2000 at 11:44:34AM -0500, Dennis wrote: At 05:14 PM 12/19/2000, you wrote: On Tue, Dec 19, 2000 at 12:25:43PM -0500, Dennis wrote: Am I a thief because my company provides value added solutions without source to our enhancements on a freebsd platform? If you are insulted that other people are using your work without paying for it then it sounds like you dont fit in very well with the "open source" community Mr. Kamp. This brings about a question I have been wondering about for quite some time: How do you submit binary-only code to the ports collection? I just re-read the porters' handbook, and it seems to be assuming that you will always release source code for everything. But I am thinking about porting some of my Windows software to FreeBSD, yet, I do not want to release the source code (since much of it is the same I *sell* to Windows users in binary-only form). Then again, I may decide not to do it: My latest port submission has been sitting in the GNATS database for months, so why bother submitting more when nobody cares anyway? Welcome to the Animal Farm THIS was my point about the FreeBSD camp particularly alienating binary vendors as to drive them away. The kernel make has been broken for yearsthe "fix it yourself" aka "tough sh*t" echo has been heard loud and clear. They dont want your stinking binary contributions. Get used to it. Not suprisingly you're both wrong. Many binary-only ports exist in the FreeBSD ports tree. If you're going to act like an ass on the mailing lists at least try to be correct while you do it. -- Bill Fumerola - security yahoo / Yahoo! inc. - [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
I was about to write up a group of suggestions that include the notion that you could use kqueue to watch the directory's vnode, you could use Erez's stackable file system code to pass all file creates through a filter, use lpd's spooling mechanism to treat the incoming directory like a print queue, use a standard issue cron job, etc, etc. But... At present the files are created through procmail like this: |/usr/bin/perl $HOME/process_cvs_mail.pl ~/msgs/$FILE ...this fragment tells me that you are in control of the process of creating these files. This makes the whole problem much easier to solve and side steps the issue of watching the directory altogether. In addition to the suggestions above, you could also: You could set up the message processing daemon to listen on a named pipe and send the messages there from the process_cvs_mail script. You could handle queue entry with the process_cvs_mail script and queue exit with your daemon; signal the daemon from the script when new work appears in the queue. This would mirror a threaded work queue approach that blocks on a a conditional variable until work comes into the queue. -- Jack Rusher, Senior Engineer | mailto:[EMAIL PROTECTED] Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
On Wed, 27 Dec 2000, someone on freebsd-hackers wrote: They dont want your stinking binary contributions. Get used to it. Not suprisingly you're both wrong. Many binary-only ports exist in the FreeBSD ports tree. World is not black and white. There are binary ports (for example netscape). But there are no well defined procedures for including binary device drivers with FreeBSD. Even building modules outside /usr/src/sys/modules is not easy task. What about asking for additional driver modules on fresh install? Lack of well defined procedures for inclusion of binary only drivers is definitely our shortcoming. We are moving to right direction (kernel modules etc.), but we are not there yet. There are reasons for binary only drivers. For example - ADSL, it is coming more common, but supply chain is just too long. Card manufacturers are helpful, they provide programming information, but they are not free, they just can't ignore chipset suppliers (who are not ready for releasing some firmware yet). best regards, taavi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Silent FreeBSD
I know your pain. At home I have a good sized collection of hardware and the noise level in my office was getting unbearably high. I used to have the mp3 player (xmms) turned up loud enough that I couldn't hear the doorbell ring. I had been drooling over the G4 cube just because they're silent and MacOS X really is nice. Some additional ideas to think about. If you've got another Unix server on the LAN, you could netboot the gateway. Rather than having a local file system (and consequently hard drive), use a Intel EtherExpress+ and PXE netboot it. It works surprisingly well. I have a stack of old PPro 200's with 128MB of RAM each, one Intel NIC card, and they all netboot off one FreeBSD server. I have them fetch a 25MB root file system which gets mounted as a MFS. You just need to have enough RAM in the machine to accomodate their root file system and nfs mount the /usr and anything else you want. If not, yet another option might be enabling the power management in BIOS so that the drive spins down when not in use. If the machine is just a gateway, it's file system probably isn't all that busy. Some machines also support having their fan speeds slow when in a power savings mode. Alas that wasn't enough for me so I worked around the problem in the following manner. First I replaced the drives in my G3 and FreeBSD X server with IBM GXP75 series UDMA drives. I had tested a few at work and was impressed. Not only are they wicked fast but they're cheap ($150 for 30GB), oh-so-quiet, and run very cool. Cool enough in fact that the internal temperature in my G3 case dropped enough that I was able to remove the CPU cooling fan I installed back when I overclocked it. That was two significant noise reductions. The G3 is very quiet now with only the power supply fan making a little noise. It's quiet enough that it sits on my desk without annoying me. My Dell PII450 on the other hand, that runs FreeBSD is not very silent. Despite the much quieter drive, the cooling fans are still fairly noisy. Rather than disabling one of the fans (without a good way to measure it's effect) I chose to instead get a longer set of KVM and sound cables and shove it into the not-so-far-away closet where it's whirring isn't offending my ears. I can then access the server via the KVM switch and run X programs via a SSH connection from the HP 9000 which is also be left out without offending my ears. The last step in silencing the office was running cat 5 to the garage, buying a 19" rack and rackmounting the pile of FreeBSD servers and networking hardware I had sitting in the office. I only turned on machines as I needed them in the office but since they're 2U rackmount servers, the fans are in the front and they're noisy. The garage has additional power drops and since it's only partially heated, it's always cooler and therefore a better location for the machines. Good luck to you and and may your silence be golden. Matt -Original Message- From: Renaud Waldura [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 27, 2000 11:00 AM To: [EMAIL PROTECTED] Subject: Silent FreeBSD I've got that FreeBSD gateway in a corner at my house, it works fine dandy but the constant noise (whirring fans, hard drives) gets on my nerves. What solutions have people explored to quiet down a computer system? (actual experience will be preferred over wild speculations). I'm already aware of PicoBSD, but I need more storage than just a floppy. Has anybody experimented with RAM cards? How about noise-proof enclosures? --Renaud To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
What solutions have people explored to quiet down a computer system? (actual experience will be preferred over wild speculations). I ran a totally noiseless Xterm for about a 18 months: A P5/133 with the CPU fan running on 7V (12V - 5V = 7V) which made it rotate fast enough to move air, slow enough to not make a din. A wirewound potentiometer in series with the PSU fan, again making the fan rotate below the noise threshold. No cover on the cabinet. A M-Systems Flash based Disk-On-Chip device (www.m-sys.com driver in src/sys/contrib/dev/fla) Today I would use compact flash or Smartmedia I think. I changed the flash disk for PXE diskless boot later on. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard issue
In message [EMAIL PROTECTED] Andreas Brodmann writes: : The pccardd is running. Does anyone know what it could be : or what I have to do to get any output from pccardd (even : if it was just saying "i don't know the card you inserted"). Interesting. You should at least get a card inserted message in dmesg. Try to find a irq that is free to use for a management IRQ. You might also see if there are conflicts with the memory space or i/o space that might be causing this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
In message 005801c07037$47ae6ea0$[EMAIL PROTECTED] "Renaud Waldura" writes: : I've got that FreeBSD gateway in a corner at my house, it works fine dandy : but the constant noise (whirring fans, hard drives) gets on my nerves. : : What solutions have people explored to quiet down a computer system? (actual : experience will be preferred over wild speculations). I'm already aware of : PicoBSD, but I need more storage than just a floppy. Has anybody : experimented with RAM cards? How about noise-proof enclosures? CF cards work great! They are very very quiet in normal operation. In fact, if they do make noise, you have a really big probelm. :-) I've also seen custom cases that have sound dampening devices but still have sufficient airflow for most people's needs. I've also run in a production machine where the edict was there shall be no fans with big honkin heat sinks (like 9inch long 2inch high fins running the length of the unit). But that was a fairly custom design and would likely be too expensive for the normal user (we also had to underclock the CPUs as well to meet temperatuere specs). I have a buddy that swears by the following low-tech cheap technique: Take a big cardboard box. One that is about 1.5x the size of the box you want to keep quiet. Knock a few holes in the box (small holes seem to work best, and only a few of them) and put the cardboard box over the unit. Hav ethe cables come out the bottom. Put something heavy on the box to keep in in place, but not too heavy since this is just cardboard. But I've not tried this. You'll likely need to try this on a system that doesn't run hot to start with. The CF cards will help a lot with the heat (since they run at room temperature, if they are generating heat, again you have big problems). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
I've also run in a production machine where the edict was there shall be no fans with big honkin heat sinks (like 9inch long 2inch high fins running the length of the unit). But that was a fairly custom design and would likely be too expensive for the normal user (we also had to underclock the CPUs as well to meet temperatuere specs). There exist 19" rack cabinets for convention cooling. They are usually used in dusty environments. They have internal fans to circulate the air, and heat-sinks on the outer surface to dissipate the heat. An example in Danish here: http://sql.danbit.dk/kat2001/0410.phtml (The claim that the internal fans generate an overpressure seems rather far-fetched to me) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
In message 463.977951088@critter, Poul-Henning Kamp writes: I've also run in a production machine where the edict was there shall be no fans with big honkin heat sinks (like 9inch long 2inch high fins running the length of the unit). But that was a fairly custom design and would likely be too expensive for the normal user (we also had to underclock the CPUs as well to meet temperatuere specs). There exist 19" rack cabinets for convention cooling. They are usually s/convention/convection/ DuH! :-) used in dusty environments. They have internal fans to circulate the air, and heat-sinks on the outer surface to dissipate the heat. An example in Danish here: http://sql.danbit.dk/kat2001/0410.phtml (The claim that the internal fans generate an overpressure seems rather far-fetched to me) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
On Dec 27, Renaud Waldura wrote: I've got that FreeBSD gateway in a corner at my house, it works fine dandy but the constant noise (whirring fans, hard drives) gets on my nerves. What solutions have people explored to quiet down a computer system? (actual experience will be preferred over wild speculations). I'm already aware of PicoBSD, but I need more storage than just a floppy. Has anybody experimented with RAM cards? How about noise-proof enclosures? There was a fan related discussion in -chat on [... let's see, from procmail log ] From [EMAIL PROTECTED] Wed Jul 26 02:39:25 2000 Subject: Quiet cpu fans Folder: /home/staff/mat/Mail/freebsd-chat If I remember, eventually http://www.quietpc.com/ came about. --Mat --Renaud To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Mathew Kanner [EMAIL PROTECTED] SOCS McGill University Obtuse quote: He [not me] understands: "This field of perception is void of perception of man." -- The Quintessence of Buddhism To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
On Wed, Dec 27, 2000 at 11:44:34AM -0500, Dennis wrote: Then again, I may decide not to do it: My latest port submission has been sitting in the GNATS database for months, so why bother submitting more when nobody cares anyway? Welcome to the Animal Farm THIS was my point about the FreeBSD camp particularly alienating binary vendors as to drive them away. The kernel make has been broken for yearsthe "fix it yourself" aka "tough sh*t" echo has been heard loud and clear. They dont want your stinking binary contributions. Get used to it. Actually, the port submission I was talking about is in source code form. And it is nothing new: Ports always seem to take a long time to be committed. Nor do I mean it as criticism. FreeBSD is a voluntary effort, so it takes time. I just find it kind of weird that whenever I write software for FreeBSD, the Linux community finds it within seconds of the time I release it. They send me email thanking me for my work, they send suggestions, and things like that. Meanwhile, the users of the OS I wrote it for will probably never even know it exists. Most of the email I get from FreeBSD users is critical: They accuse me of using Windows assembly language. I do not know where they get that idea. I use NASM, which has nothing to do with Windows. Windows uses MASM which is totally incompatible with NASM. NASM uses the Intel syntax, excatly as defined by the people who created the '86 series of microprocessors. NASM is written in C, comes with full source code, free, available from the ports, and uncontaminated by GNU license. I thought we were supposed to use tools that are NOT licensed under GNU whenever possible. Well, NASM does not use GNU license (in fact, it was dropped from Sourceforge for that very reason). MASM, on the other hand, uses a syntax that is derived from Intel's syntax, but, as everything that comes from Microsoft, has been modified just enough as to be incompatible. NASM is not MASM. It is a portable cross-assembler that can assemble source code on any platform for any supported platform (which includes all flavors of Unix on the '86 hardware). Ironically, the biggest Microsoft haters -- the Linux community -- are the biggest proponents of NASM. My motivation, however, has nothing to do with hatred. I use it because it offers tighter control over its output than any other assembler available anywhere, and because it was designed as an assembler for assembly language programmers, not as a back end to compilers. If I were to write a compiler for another language, I would let it emit ATT syntax because gas is better suited for the assembly of compiler-produced assembly language code. In the 35 years I have been programming, I have learned to use the tool that is best suited for the task at hand, not a tool that is politically correct. I am sorry to see a certain rigidity in this community, an attitude of "we have always been doing things a certain way and we are not about to change." If I had that attitude, I would still be programming in Fortran, inputting my code on punch cards. I thought it was us old farts that were supposed to be inflexible, hehehe. Nor am I saying, by the way, that everyone should switch to the tools I use. But I certainly don't appreciate it when people, especially people much younger than me, keep telling me to use a "tradition" that was not even born when I was already programming computers. If we keep insisting on traditions, we will end up in a museum. Luckily, not everyone here is like that. There are many in this community who are not anal retentive, though many just talk to me in private and not dare to express their ideas in a public forum. That said, I do think FreeBSD is the best darn OS currently in existence. That is why I am still sticking with it, and will continue to support it. As for the binary thing: That was a question, not a statement. Cheers, Adam -- A billion dollars in the bank, without the experience of carefreeness and charity, is a state of poverty. -- Deepak Chopra To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On 27 Dec 2000, at 12:53, Peter Pentchev wrote: Something like.. | /usr/bin/perl $HOME/process.pl ~/msgs/$FILE.tmp \ mv ~/msgs/$FILE.tmp ~/msgs/$FILE.cvs Thanks for that. It's helped me solve a procmail problem I was having. The files were 600 instead of 640, so I did this: |/usr/bin/perl $HOME/process_cvs_mail.pl ~/msgs/$FILE chmod o+r ~/msgs/$FILE Works great. Cheers. -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
HERKESE MERHABALAR
Tekrar sizlere mail atabilmek gercekten güzel Sitemiz hemen hemen hergün muntazam olarak yenilenmektedir. Sitemize girdiðinizde göreceðiniz en büyük yenilik site tasarýmýmýzýn tamaen deðiþtiðidir. Gerçekten çok güzel olduðuna inandýðýmýz bir tasarýmla karþýnýzdayýz. Kendi serverýmýza turkçe ve yabancý mp3 yuklemeye baþladýk artýk mp3 leri çok rahat ve sorunsuz çekebileceksiniz http://www.hugemp3s.com Saygýlarýmla ! - HUGE MP3 - http://www.hugemp3s.com Listeden Çýkmak için Aþaðýdaki Linke Týklayýnýz http://www.hugemp3s.com/mail.cgi??[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On 27 Dec 2000, at 19:56, Peter Pentchev wrote: On Wed, Dec 27, 2000 at 09:16:34AM -0800, Alfred Perlstein wrote: * Dan Langille [EMAIL PROTECTED] [001226 23:50] wrote: My idea is to have a daemon, or something resembling one, sitting on the box watching the directory. When a new file appears, it starts a perl script. This perl script is beyound the scope of my question, but it processes all the files in the directory. When finished, it looks for any more files and repeats as necessary. If no more files, it exits. This isn't an answer to your main question (i see it's already been discussed), but you may be able to use setup a kevent on the directory which should inform you if any files are added to it. Unfortunately, I gather that Dan intends to write most of the FreshPorts code in Perl, and AFAIK, Perl has no kqueue/kevent interface :( Unfortunately? *grin* FWIW, Most of the existing and new code will be PHP based. Perl is used primarly for importing data from cvs-all. And for various mailings out to users. Thus, to make use of kevent (which I certainly agree would be a better FreeBSD-specific solution), he'd have to either 1. have a C program which spawns Perl and his script on every change, or 2. have a C program which spawns Perl once and signals it on every change. The first way would be downright stupid IMHO.. The second one may very well be more efficient than the readdir, sleep solution which I proposed in other postings, seeing that Dan wants to process the cvs-all mailings, which certainly do not arrive every few seconds :) I like the 2nd concept. It appeals to me. I haven't done any C in about 7 years and all of that was in Windows. Never in a Unix environment. This solution is more complex than the "cron job every minute" which I discussed with Mark, but it fits with my goal of having processed the cvs-all messages as quickly as I can. -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On 27 Dec 2000, at 11:25, Jack Rusher wrote: At present the files are created through procmail like this: |/usr/bin/perl $HOME/process_cvs_mail.pl ~/msgs/$FILE ...this fragment tells me that you are in control of the process of creating these files. That is correct. This makes the whole problem much easier to solve and side steps the issue of watching the directory altogether. In addition to the suggestions above, you could also: You could set up the message processing daemon to listen on a named pipe and send the messages there from the process_cvs_mail script. You could handle queue entry with the process_cvs_mail script and queue exit with your daemon; signal the daemon from the script when new work appears in the queue. This would mirror a threaded work queue approach that blocks on a a conditional variable until work comes into the queue. Will this approach tie up the procmail script? I want the MTA to be freed up ASAP. That's one of the primary reason for wanting separate processes. From time to time, the website can be "flooded" with messages. This is usually the result of the website being offline or otherwise disconnected from the net. The mail builds up and then arrives all at once. That's the reason for freeing up the MTA quickly. -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Thinkpad Partition Problem Solved?
I came up with a very similar solution independently (although I chose a "reserved" partition number). You may also wish to (I did) patch boot0 for the cosmetic fix. It is possible to rescue a 165'd [ATX] series thinkpad by booting an install floppy without an installed HD and hot-inserting the HD before the kernel loads - allowing you to change the partition number (have a fixit.flp or live CD handy). This is probably not very good for the HD, but it works. There's not reason why sysinstall can't come with a tool to change the recognised partition number, is there? Apart from being pig-ugly nasty and implying another line in make.conf and patches to anything using disklabel.h or hardcoding values. Architecturally revolting. /usr/src/sys/boot/thinkpad/, anyone? :) Joshua On Sun, 24 Dec 2000, Michael C . Wu wrote: On Sun, Dec 24, 2000 at 06:16:22PM +, Nik Clayton scribbled: | x-posting to -hackers | | On Fri, Dec 22, 2000 at 12:18:05PM -0800, Bruce A. Mah wrote: | qandaentry | + question id="boot-on-thinkpad" | + paraI have an IBM Thinkpad A20p that FreeBSD installs on, but then | + the machine locks up on next boot. How can I solve this?/para | + /question | | I'd start with "I have an IBM ThinkPad in the A, T, or X series...". My | wonderful (actually it *is*, now that this problem's solved) T20 crapped | out to start this off. | | Is there any way we can detect this at boot time, or sysinstall time? It | would be nice to throw up a | | WARNING | |You are attempting to install on an IBM ThinkPad A, T, or X series |machine. | |A BIOS bug makes it likely that FreeBSD's default install will leave |your computer in an unbootable state. | |Unless you have read and are planning to follow the instructions at |http://www.FreeBSD.org/faq/... you should exit this install |immediately. I do not think that is possible, since the machine is seen as a normal PC like everything else. Unless you wish to somehow have sysinstall look at the BIOS versionew.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
On 26 Dec, Wes Peters wrote: [EMAIL PROTECTED] wrote: On 25 Dec, David O'Brien wrote: On Fri, Dec 22, 2000 at 11:28:07PM -0800, Kris Kennaway wrote: Incorrect..the problems with SSH come down to flaws in the human operator who ignore the warnings SSH gives them, and tell it explicitly to do insecure things like connect to a server which is suddenly not the one you're used to connecting to. And we, the FreeBSD Project, don't do a thing to help this situation. We change the SSH keys on the freebsd.org machines left and right w/o *ANY* notice to committers that they have been changed. So we've trained our own committers to have sloppy habits that could lead a malicious code added to the FreeBSD CVS source repository. Is this correct? Can anyone confirm this. A message by Wes Peters suggests it to be so. No message from me suggested anything about ssh key handling by the FreeBSD project. Don't start quoting me out of context. I'll go back to the original message that was posted, if you like. Your message made a suggestion, nothing more. What exactly it *MEANT* to say IS NOT CLEAR. This is why I'm asking questions. I'm not going to quote you, if I'm not clear on what you are saying. But if you are saying something, please assist my understanding in this matter. Please email me what you are saying. If you believe, I have wronged you, as you are stating, I will appoligize, but I my original understanding of your posting is -what I posted/questioned. Jessem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
On 26 Dec, Mark Murray wrote: Which original keys are you talking about? SSH public server keys. (Sometimes called "server identities"). Are you saying that the original SSH Public Keys for the servers were always sent in the clear, without PGP signature or anything? David was saying that, but he's wrong. There was a time that we were very lax about confirming the server public keys. The last round of changes have all been confirmed by digital signature by well-known server administrators. Okay, can you be specific about what you mean by "There was a time that we were very lax". I'll make the broad assumption that things are now "correct". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
On 25 Dec, David O'Brien wrote: On Mon, Dec 25, 2000 at 06:34:09PM -0800, Mike Smith wrote: No, in several particulars. "The FreeBSD Project" doesn't change the SSH keys on the FreeBSD.org machines. Not changed for change sake, but failure to do anything to preserve them. David has probably been drinking too much; it's Christmas, after all. This was totally uncalled for in a public list. Especially from one that has been critical of me lately. I hate to tell you, but I've been on the BSDi clock all day long. David, I belive that Mike meant to say David Green. I expected that was what he meant. It was Christmas day. Jessem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
the constant noise (whirring fans, hard drives) gets on my nerves. My screen, keyboard and mouse are on 12 metre extension cables. The computer itself (with 3 more fans installed after a heat problem) is 2 floors down, under the stairs. I can't hear those fans :-) -- TJ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
On 27 Dec 2000, at 19:17, [EMAIL PROTECTED] wrote: the constant noise (whirring fans, hard drives) gets on my nerves. My screen, keyboard and mouse are on 12 metre extension cables. The computer itself (with 3 more fans installed after a heat problem) is 2 floors down, under the stairs. I can't hear those fans :-) I'm impressed. No loss of signal I presume? Special cables? or just long? -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Thread DIES [Re: ssh - are you nuts?!? ]
On 26 Dec, Mike Smith wrote: If it is FUD as you claim, then the call should be made by the SO. This would seem to be prudent policy. Jesse, Kris *is* the Security Officer. Now, please let this thread die. Mike, You and I don't often agree, but this time is worth noting. I agree. Messages, flames and counter-claims have now reached a point of dis-information/noise. If you have emailed me, and I have not responded - I will privately. The only exception are Wes Peters, who claims I have mis-quoted him If I have I must make a public appoligy. Bill Fumerola, who states that security policy information is un-available. However, I might refer his comment to the Security Officer instead, if Bill feels this appropriate. Any further comments about this thread should be emailed to me directly. If you post I will respond, but privately. Lastly, I formally request any further continuation about this subject on this thread stop. Jessem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
Okay Wes, This is your original message. You state: "This is exactly the sort of problem we need to solve..." In the context of this message I must assume that since the subject is SSH, then you are referring to SSH. If not, there is nothing in the message that would lead me to believe otherwise. If you I have mis-quoted you, please clarify your statement so that I might make appropriate reperations. respectfully, Jessem. BTW, your original message is below: = Message-ID: [EMAIL PROTECTED] On 25 Dec, Wes Peters wrote: David O'Brien wrote: On Fri, Dec 22, 2000 at 11:28:07PM -0800, Kris Kennaway wrote: Incorrect..the problems with SSH come down to flaws in the human operator who ignore the warnings SSH gives them, and tell it explicitly to do insecure things like connect to a server which is suddenly not the one you're used to connecting to. And we, the FreeBSD Project, don't do a thing to help this situation. We change the SSH keys on the freebsd.org machines left and right w/o *ANY* notice to committers that they have been changed. So we've trained our own committers to have sloppy habits that could lead a malicious code added to the FreeBSD CVS source repository. This is exactly the sort of problem we need to solve in a usable and secure manner, so we can be an example to hold up and say "this is one way you can make it work." I'm completely open to suggestions as to how we can accomplish that. A few ideas leap to mind, but unfortunately, short of an heirarchical calling list, none of them really work, relying on other key information that may have changed also. Sending an email with the new certs signed by the SO or other authoritative key would work, given that everyone already has the OS cert or key, unless it is the SO key that is changing. With a little bit of perspiration, we could probably create a calling list that minimizes overseas and long distance calls, but reaching far-flung people on the phone is often difficult, expensive work. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
At 05:14 PM 12/19/2000, you wrote: On Tue, Dec 19, 2000 at 12:25:43PM -0500, Dennis wrote: Am I a thief because my company provides value added solutions without source to our enhancements on a freebsd platform? If you are insulted that other people are using your work without paying for it then it sounds like you dont fit in very well with the "open source" community Mr. Kamp. This brings about a question I have been wondering about for quite some time: How do you submit binary-only code to the ports collection? I just re-read the porters' handbook, and it seems to be assuming that you will always release source code for everything. But I am thinking about porting some of my Windows software to FreeBSD, yet, I do not want to release the source code (since much of it is the same I *sell* to Windows users in binary-only form). See eg. the StarOffice, WordPerfect, Citrix ICA, Netscape, etc. ports. The process is pretty straightforward, and works well. Then again, I may decide not to do it: My latest port submission has been sitting in the GNATS database for months, so why bother submitting more when nobody cares anyway? Typically, we recommend that you agitate a little more if your PR hasn't been assigned to someone. You're misreading the situation here; it's not that "nobody cares" so much as "there is so much else to care about that you haven't made it to the top of the stack yet". As the saying goes, the squeaky wheel gets the grease. 8) They dont want your stinking binary contributions. Get used to it. On the other hand, non-stinking binary contributions are welcome. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
On Wed, 27 Dec 2000, "Renaud Waldura" [EMAIL PROTECTED] wrote: I've got that FreeBSD gateway in a corner at my house, it works fine dandy but the constant noise (whirring fans, hard drives) gets on my nerves. What solutions have people explored to quiet down a computer system? (actual experience will be preferred over wild speculations). I'm already aware of PicoBSD, but I need more storage than just a floppy. Has anybody experimented with RAM cards? How about noise-proof enclosures? I knew a guy once who was doing sound work on an SGI box, and was constantly complaining about the noise. He finally decided to eliminate everying that moved in the box. The temperature in the case was so high he couldn't touch some parts without getting burnt (don't remember the exact figures.) After some smoke tests to establish the exact air flow, he ended up building a huge wooden container with all walls insulated with a thick layer of foam and a 2 meter chimney to exhume the hot air. It worked like charm, although I think he had to put one fan somewhere. The box was perfectly silent, and ran at a comfortable 30 degrees C, but it took him a few months to get it working, and he was a constant source of amusement to half the Uni population for a year. Trust me, you don't want to attempt a noise-proof enclosure (short of an air-conditioned machine room.) I suggest the following course of action: 1. get a quieter power supply 2. get a quieter fans 3. get a good new drives: they're quiet. 4. get used to the noise. I have three computers running 24/7 in my bedroom, and after some swapping of power supplies, the noise is perfectly bearable. Pat. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Patryk ZadarnowskiUniversity of New South Wales [EMAIL PROTECTED] School of Computer Science and Engineering -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
Jeremiah Gowdy wrote: Trouble is there is no consistency in the rulings. United States Code Title 17 Chapter 12 Section 1201 Subsection (f) My basic interpretation of this is, if you legally own a copy of the software (firmware is software), you can legally reverse engineer the software for the purpose of achiving interoperability. Therefore, if you own a piece of hardware, and you have no driver for the hardware, or the I wonder, if this provision is overriden by the DMCCA (the new proposed and in some places adopted act on software copyrights) ? -SB United States Code Title 17 Chapter 12 Section 1201 IS the DMCA. I said that in my post. :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ONTOPIC - FreeBSD vs Linux, Solaris, and NT - Not a bunch of licence Jihad crap
The current work in progress is available at : http://people.freebsd.org/~murray/ Any feedback would be greatly appreciated. Thanks, - Murray Okay, I read your page and printed it out, and went over it a few times. A couple of things bothered me, but for the most part I agreed with it. Then I showed it to a few friends of mine and they seemed to be bothered by the same statements so I finally decided I would bring them to your attention. In order for your document to be considered a reasonable and unbiased paper, it must be reasonable and unbiased :) Some of your statements leave us with the taste of the Anti-Microsoft-Jihad. For example: All Windows users are familiar with the "Blue Screen of Death". Poor reliability is one of the major drawbacks of Windows. Some of the major issues have been fixed in Windows 2000, but "code bloat" has introduced many more reliability problems. I run Windows 2000 on many desktop systems, and I've run Windows 2000 Server and Advanced Server. So have many friends of mine. I have seen FEW BSODs in Windows 2000. About as many BSODs as I've seen FreeBSD kernel panics or hardware driver lockups. You can't say this statement like this, implying that Windows 2000 BSODs, and then say some of the major issues have been fixed in 2000. Windows 2000 isn't a "fix" of Windows 98. It's basically Windows NT 5.0. I know Windows NT 4.0 Workstation to be a very rock stable OS for basic workstations. Then you introduce the term "code bloat", which is a favorite in Anti-Microsoft rants. "Code bloat" apparently means implementing more code/features/etc than a certain computer "expert" feels should have been included. It also implies that this extra "bloat" causes instability or reduced speed in the product. Certainly, some operating systems, like Windows Millennium, could be described as "bloated", however, to imply that Windows 2000 has some sort of "code bloat" when it actually outperforms the same software applications under Windows 98 is completly nonsensical. Yes, Windows 2000 does take a more powerful computer to run than Windows 98. But that is comparing apples to oranges. How much more powerful of a computer does Windows 2000 take than Windows NT 4.0 ? When considered in this light, Windows 2000 (NT 5) doesn't require much more of a hardware upgrade than many other operating system upgrades. Consider the fact that Windows NT 4.0 to Windows 2000 (5.0) is certainly no small update, one would expect the OS, being much more powerful, to require more resources. So, consider revising this statement. I've found that when you treat it properly, Windows 2000 can be a very stable operating system. Unintelligent administrators can certainly create an unstable Windows 2000 setup, but that doesn't nessisarily detract from the OS itself. If you're going to be critical of Windows 2000's reliability, you need to support it better than you currently are. You're also very quick to talk about FreeBSD's Softupdates, but you fail to say anything reasonable about Windows 2000's disk access speed or reliability. If you slant your judgement so far against the other products, it makes you sound like you don't know what you're talking about (no offense). You need to point out the pros and cons of ALL three systems. Not just the pros of FreeBSD and the cons of Linux/Windows. NO ONE in their right mind believes that FreeBSD is the beginning and the end, the one and only true operating system, master of all features, speed, and reliability. It's just our favorite and it has certain major advantages. That doesn't mean you can ignore the advantages of the other operating systems. Windows is adequate for routine desktop apps, but it is unable to handle heavy network loads. A broad statement with no support. Define heavy network loads. A few organizations try to make it work as an Internet server. Only a few ? For instance, barnesandnoble.com uses Windows-NT Now you're going to cite Windows NT 4 in your argument against Windows 2000 ? Your comparison is FreeBSD vs Linux vs Windows 2000, not Windows NT 4.0. That would be like me saying, blahblahblah.com is using Red Hat Linux 5.0 with Wu-FTPd 2.6 so Linux is totally insecure. For their own "Hotmail" Internet servers, Microsoft used FreeBSD for many years. Although this is somewhat true, how long has Microsoft owned Hotmail ? Didn't they plan to remove all FreeBSD servers and replace them with Win2k servers from the beginning ? Isn't that a massive project to move a live service like that ? Haven't they completed that project and removed all FreeBSD servers (requiring more Win2k servers than former BSD servers to handle the load of course) ? Once again, you made a broad statement that implies a lot, but you are somewhat misleading the reader by not giving enough fact. If you don't have enough room to completely explain a complicated statement like this, I suggest you not
Re: ssh - are you nuts?!?
Okay, can you be specific about what you mean by "There was a time that we were very lax". If there was a change of server identity, then we did not necessarily announce what the new identity was in a way that people could trust. These days, a member of the Security Officer team sends out an announcement (cryptograhically signed of course) letting folks know what identity (fingerprint) to expect. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
