Re: rexecd broken(?) on -current
> Hi Mark, Hi > > I tried to use rexecd on my -current environment, but it failed. > > If OPIE is defined, opiechallenge() is called to configure opiedata > structue, but this structure is filled with 0 because I don't use > one-time password. > > I think it should fallback to call crypt() or so if opiechallenge() is > failed. > > I don't know how it should work with OPIE. Could you please fixing > this, Mark? Sure! I've never used rexecd, su could you please suggest a minimalist test/command that I could use, and I'll get right to it. :-) M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: anonymous-ftp cracked
[broken quoting fixed] Kory Hamzeh <[EMAIL PROTECTED]> wrote: > Ted Mittelstaedt wrote: > > I've had a bit of experience with this sort of thing and I have > > to say that > > nobody should be running an open FTP server that allows uploading > > to anyone > > unless they are willing to take the time to monitor it - and I mean every > > day, preferably several times a day. > > [...] > > Yup, I had some jerk constantly fill up the filesystem of the ftp directory > until I finally disabled all uploads. The ethics of some people just amazes > me. If you absolutely need to have an anonymous upload directory, it is probably a good idea to disable ls and read-permission in that directory. That way people can upload things, but they can neither list nor download them without prior operator intervention. Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE usage, and one forgotten item (PC98)
In message <[EMAIL PROTECTED]> Julian Elischer writes:
: All looks good.. obviously the logic of what was going on was easy
: enough to pick up :-)
:
: the only bit I didn't see so easily was:
:
: static int
: -fdformat(dev, finfo, p)
: +fdformat(dev, finfo, td)
: dev_t dev;
: struct fd_formb *finfo;
: - struct proc *p;
: + struct thread *td;
: {
: + struct proc *p = td->td_proc;
: fdu_t fdu;
: fd_pfd;
:
: @@ -2860,7 +2861,7 @@
: /*
: * keep the process from being swapped
: */
: - PHOLD(p);
: + PROC_LOCK(p);
: bzero((void *)bp, sizeof(*bp));
: bp->bio_cmd = BIO_FORMAT;
:
: @@ -2898,7 +2899,7 @@
: /*
: * allow the process to be swapped
: */
: - PRELE(p);
: + PROC_UNLOCK(p);
: free(bp, M_TEMP);
: return rv;
: }
:
: the replacement of PHOLD with PROC_LOCK().. I'm not sure of what this actualy
: means..
Since I don't know what either PHOLD or PROC_LOCK are, I don't know if
I did this right. Maybe it is bogus.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
kern.flp blown out again
I don't know what the KSE commit added (or if it was even anything more than bad timing), but we've hit the limit on the kernel floppy again (x86): Setting up /boot directory for kern floppy /R/stage/image.kern/kernel: 53.9% -- replaced with /R/stage/image.kern/kern el.gz sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt 1440 /R/stage/image.kern 8 fd1440 disklabel: ioctl DIOCWLABEL: Operation not supported by device Warning: Block size restricts cylinders per group to 6. Warning: 1216 sector(s) in last cylinder unallocated /dev/md0c: 2880 sectors in 1 cylinders of 1 tracks, 4096 sectors 1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 32 i/g) super-block backups (for fsck -b #) at: 32 cpio: write error: No space left on device *** Error code 1 Any new device drivers added in the last day or so? - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern.flp blown out again
On Thu, Sep 13, 2001 at 01:43:32AM -0700, Jordan Hubbard wrote: Hm. Isn't this a strong sign that something fundamental must be done about the boot floppy process? Alpha has been suffering from this longer already due to the bigger binaries. > I don't know what the KSE commit added (or if it was even anything > more than bad timing), but we've hit the limit on the kernel floppy > again (x86): > > Setting up /boot directory for kern floppy > /R/stage/image.kern/kernel: 53.9% -- replaced with /R/stage/image.kern/kern > el.gz > sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt > 1440 /R/stage/image.kern 8 fd1440 > disklabel: ioctl DIOCWLABEL: Operation not supported by device > Warning: Block size restricts cylinders per group to 6. > Warning: 1216 sector(s) in last cylinder unallocated > /dev/md0c: 2880 sectors in 1 cylinders of 1 tracks, 4096 sectors > 1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 32 i/g) > super-block backups (for fsck -b #) at: > 32 > cpio: write error: No space left on device > *** Error code 1 > > Any new device drivers added in the last day or so? > > - Jordan > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message ---end of quoted text--- -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD current is very slow
On 12 Sep, John Baldwin wrote: >> Just put this symlink into /etc and try again. >> >> (2) netchild@ttyp1 % ll /etc/malloc.conf >> lrwx-- 1 root wheel 2 18 Aug 21:47 /etc/malloc.conf@ -> aj > > That doesn't affect INVARIANTS or WITNESS, which slow the system considerably > (esp. WITNESS). I didn't knowed WITNESS is in GENERIC (I use a custom kernel), but INVARIANTS isn't that bad (Celeron@400 & Duron@800). Bye, Alexander. -- Failure is not an option. It comes bundled with your Microsoft product. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern.flp blown out again
> Hm. Isn't this a strong sign that something fundamental must be done > about the boot floppy process? Alpha has been suffering from this longer > already due to the bigger binaries. Hey, be my guest, just so long as we can install from whatever you come up with. :-) Seriously, the fact that it needs fundamental fixing is why we're still using what we do. It's just easier to keep band-aiding it, as ugly a scenario as that might be. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern.flp blown out again
> > I don't know what the KSE commit added (or if it was even anything > more than bad timing), but we've hit the limit on the kernel floppy > again (x86): Hehe, it's time to add bzip2 into loader ;) I had a patch, but it provides only marginal improvement as due to memory constrains you can only use 100k compression blocks, `bzip2 -1', but it still provides 3% better compression that `gzip -9'. -Maxim > > Setting up /boot directory for kern floppy > /R/stage/image.kern/kernel: 53.9% -- replaced with /R/stage/image.kern/kern > el.gz > sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt > 1440 /R/stage/image.kern 8 fd1440 > disklabel: ioctl DIOCWLABEL: Operation not supported by device > Warning: Block size restricts cylinders per group to 6. > Warning: 1216 sector(s) in last cylinder unallocated > /dev/md0c: 2880 sectors in 1 cylinders of 1 tracks, 4096 sectors > 1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 32 i/g) > super-block backups (for fsck -b #) at: > 32 > cpio: write error: No space left on device > *** Error code 1 > > Any new device drivers added in the last day or so? > > - Jordan > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern.flp blown out again
On 13-Sep-2001 Jordan Hubbard wrote: > > Hm. Isn't this a strong sign that something fundamental must be done > > about the boot floppy process? Alpha has been suffering from this longer > > already due to the bigger binaries. > > Hey, be my guest, just so long as we can install from whatever you > come up with. :-) Seriously, the fact that it needs fundamental fixing > is why we're still using what we do. It's just easier to keep > band-aiding it, as ugly a scenario as that might be. I have a patch for sysinstall which allows you to load kld's from a floppy. Basically if you can boot the floppy you can load everything else you need later on. (Except non-pnp ISA devices because you can't specify port/irq/etc) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern.flp blown out again
On Thu, Sep 13, 2001 at 02:00:57AM -0700, Jordan Hubbard wrote: > > Hm. Isn't this a strong sign that something fundamental must be done > > about the boot floppy process? Alpha has been suffering from this longer > > already due to the bigger binaries. > > Hey, be my guest, just so long as we can install from whatever you I knew you would say that ;) > come up with. :-) Seriously, the fact that it needs fundamental fixing > is why we're still using what we do. It's just easier to keep > band-aiding it, as ugly a scenario as that might be. Until you have to leave something essential out and then we are SOL. For alpha I could think of only supporting CD installs, and drop floppies altogether. This follows DECs/CPQs convention of only supporting OS installs from CD. Say a special install CD without packages (140MB or so). W/ -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rexecd broken(?) on -current
At Thu, 13 Sep 2001 08:27:04 +0100, Mark Murray wrote: > Sure! I've never used rexecd, su could you please suggest a minimalist > test/command that I could use, and I'll get right to it. :-) Hmmm, I tried with Astec-X (*1). I don't know how to test rexecd easily. But I can test on my environment if you make patch for rexecd. (*1) http://www.astec.co.jp/products/ENGLISH/ASTECX/ -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone experience problems with the "tap" device in current?
Marcel Moolenaar wrote: > > On Wed, Sep 12, 2001 at 04:59:16PM -0700, Doug Ambrisko wrote: > > I just tried using tap in current. In both cases I don't see the > > /dev/tapX devices with devfs and accessing it without devfs doesn't > > work reporting "Device not configured". I tried it as a module and > > built into the kernel. Does anyone have this working? > > My guess is that the breakage is related to the recent commits > that were made to if_tap. VMWare doesn't work anymore on -current > because the NG modules aren't loaded. These, AFAICT, depend on > the device. > > So, at this time I can only acknowledge the breakage. I probably > won't have the time to suggest or implement fixes. the recent if_tap patch implements device cloning (a-la tun(4)). unfortunately i had to change vmnet device mask and that affects VMWare port because minor numbers for vmnet devices has changed. bottom line: in order to make vmnet working you need to change minor numbers for vmnet device nodes. another solution would be to link /dev/vmnet? to /compat/linux/dev/vmnet? port maintainer has been notified. i'm sorry for the trouble. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fixing chown(8) and friends to handle symlinks properly
[Bcc'ed to -current in a hope for a more wider auditory]
The attached patch fixes the handling of symlinks in chown(8)
and chgrp(1). It is currently broken in many different ways.
Basically, it is broken because -h is not supported with -RH
or -RL. The actual problem lies in the depths of the fts(3)
implementation, in particular, how the `fts_stat' is getting
initialized. The trick in supporting roughly any combination
of command line flags ([-h] [-R [-H | -L | -P]]) was to avoid
looking into the `fts_stat' (as we don't know whether it is
from lstat(2) or stat(2)), and just call chown(2) or lchown(2)
as appropriate. Although it may seem as a big performance
degradation, in fact it isn't, as kernel doesn't modify the
inode if nothing is to be changed.
This work is based on the latest POSIX drafts, and the
superior NetBSD implementation (which I had to fix in a
number of cases anyway, in particular, handling of dead
symlinks in the -h case).
The new algorithm of handling a symlink encountered during
a file tree traversal works as follows:
+-+-+
| Options | Action |
+-+-+
| -- | chown |
| -h | lchown |
| | Notes: only FTS_SL symlinks may end up here |
+-+-+
| -RP | SKIP|
| -RP -h | lchown |
| | Notes: only FTS_SL symlinks may end here|
+-+-+
| -RH | SKIP|
| -RH -h | lchown |
| | Notes: both FTS_SL and FTS_SLNONE symlinks |
| | may end up here. FTS_SLNONE's are deadlinks|
| | specified as command line arguments |
+-+-+
| -RL | SKIP|
| -RL -h | lchown |
| | Notes: only FTS_SLNONE symlinks may end up here |
+-+-+
Or, in a more compact form:
: if symlink {
: if -R
: -h ? lchmod : SKIP
: else
: -h ? lchmod : chmod
: } else
: chmod
For the testing purposes, I'd suggest creating the following
structure, which should be self-explaining:
afile
alink -> afile
deadlink -> nofile
dir
adir -> dir
dir/afile
dir/alink -> afile
dir/deadlink -> nofile
PLEASE TEST THIS PATCH THROUGHLY!
NOTE: This implementation is still not quite POSIX compliant, as
the latter says to follow a symlink (in the -R case) only if it
points to an object of type directory. Our fts(3) routines are
unable of doing this.
If this patch is accepted, I'm going to revisit and fix the rest
of the fts(3) utilities that are listed on the symlink(7) manpage.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
Index: chown.c
===
RCS file: /home/ncvs/src/usr.sbin/chown/chown.c,v
retrieving revision 1.19
diff -u -p -r1.19 chown.c
--- chown.c 2001/09/13 14:55:59 1.19
+++ chown.c 2001/09/13 16:54:28
@@ -80,6 +80,7 @@ main(argc, argv)
int Hflag, Lflag, Rflag, fflag, hflag, vflag;
int ch, fts_options, rval;
char *cp;
+ int (*change_owner) __P((const char *, uid_t, gid_t));
cp = strrchr(argv[0], '/');
cp = (cp != NULL) ? cp + 1 : argv[0];
@@ -121,19 +122,15 @@ main(argc, argv)
if (argc < 2)
usage();
+ fts_options = FTS_PHYSICAL;
if (Rflag) {
- fts_options = FTS_PHYSICAL;
- if (hflag && (Hflag || Lflag))
- errx(1, "the -R%c and -h options may not be "
- "specified together", Hflag ? 'H' : 'L');
if (Hflag)
fts_options |= FTS_COMFOLLOW;
else if (Lflag) {
fts_options &= ~FTS_PHYSICAL;
fts_options |= FTS_LOGICAL;
}
- } else
- fts_options = hflag ? FTS_PHYSICAL : FTS_LOGICAL;
+ }
uid = (uid_t)-1;
gid = (gid_t)-1;
@@ -156,6 +153,7 @@ main(argc, argv)
err(1, NULL);
for (rval = 0; (p = fts_read(ftsp)) != NULL;) {
+ change_owner = chown;
CVSup mirrors (was Re: Alpha kernel breakage)
[Moved to -hubs, BCC'd to -current] John Polstra <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]>, > Mike Barcroft <[EMAIL PROTECTED]> wrote: > > It appears this was the problem. Switching to cvsup2.FreeBSD.org > > seems to have have solved it. I assume this is a result of the S1G > > bug in cvsup. FYI: I was using cvsup.ca.FreeBSD.org. > > Not intending to single out you folks in particular, but ... > > Just a reminder, people: Please, if you think something is wrong > with a CVSup mirror, write to the maintainer of that mirror and tell > him. All of the maintainers' e-mail addresses are listed in the > Handbook: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html#CVSUP-MIRRORS > > It doesn't do any good to tell the -current list; you have to tell > the maintainer or the problem won't get fixed. I was actually intending to contact the maintainer, but it looks like the problem has already been fixed. Would it be possible for us to be more proactive and check to make sure all the offical CVSup mirrors are running the corrected version? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Autoref_03_redactor
<<< No Message Collected >>> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern.flp blown out again
< -rwxr-xr-x 1 wollman sources 590239 Sep 13 15:13 lots-of-modules.ko.gz* Here's another one, with all of the modules except for those which cannot possibly be used for installation (e.g., sound, discard interface, bktr, etc.): wollman@khavrinen(329)$ ls -l most-modules.ko.gz -rwxr-xr-x 1 wollman sources 1183522 Sep 13 15:26 most-modules.ko.gz* This includes all of netgraph, so udbp and PPPoE could be used for network installs. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/fs/msdosfs denode.h msdosfs_denode.c ms
Note CC list changed.. On Thu, 13 Sep 2001, John Baldwin wrote: > > On 13-Sep-01 Julian Elischer wrote: > > Why are you doing this? > > having pointers to threads that are calle proc is going to be REALLY > > confusing! > > > > All vop operations will have threads (do) > > so why are you puting proc structures on them? > > Because the code claims to be shared with NetBSD and they dont have struct > thread. However, as we talked on the phone, if portability with NetBSD is no > longer a concern, then this is moot. #define proc threadB is a REALLY bad choice of how to do this.. If You REALLY MUST do this.. #ifdef __FreeBSD__ #define OS_THREAD thread #else #define OS_THREAD proc #endif at least that way it will be obvious in the code that it's not a proc in FreeBSD. But as I said on the phone, NetBSD are making hteir own changes in these files without ifdeffing, so the minimal diff changes (easy to see and understand) you are removing simply massively obscure the code for FreeBSD. We have a struct proc, so to define proc to actually be a thread is not just obscure, it's possitively misleading. We could add general macros for compatibility but they should probably go in a central place so that they can be used in multiple places. If you really wanted to go overboard, we could #ifdef __FreeBSD__ typedef struct thread *vop_thread_arg; #define V_TD_PROC(dta) ((dta)->td_proc) #else typedef struct proc *vop_thread_arg; #define V_TD_PROC(dta) (dta) #endif or some similar set of macros but I'm uncomfortable about obfuscating the code and even more unhappy about making it plain misleading! > > -- > > John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/fs/msdosfs denode.h msdosfs_denode.cmsdosfs_lookup.c msdosfs_vfsops.c msdosfs_vnops.c
On Thu, 13 Sep 2001, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Julian >Elischer writes: > : Why are you doing this? > : having pointers to threads that are calle proc is going to be REALLY > : confusing! > > I did the opposite to make my stuff more portable to -stable. Eg, I > was able to get away with '#define thread proc' given my use of the > struct thread/proc. > > I find changes of this nature to be espeically bad for people that > have to live in multiple versions of the OS. changes of which nature (It's not sure if you are FOR #define proc thread or against it.. (It wouldn't be so bad if it were #define task thread on one OS and #define task proc on another.. > > Warner > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE usage, and one forgotten item (PC98)
On Thu, 13 Sep 2001, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Julian Elischer writes: > : All looks good.. obviously the logic of what was going on was easy > : enough to pick up :-) > : > : the only bit I didn't see so easily was: > : ... > : @@ -2860,7 +2861,7 @@ > : /* > : * keep the process from being swapped > : */ > : - PHOLD(p); > : + PROC_LOCK(p); > : bzero((void *)bp, sizeof(*bp)); > : bp->bio_cmd = BIO_FORMAT; > : ... > : the replacement of PHOLD with PROC_LOCK().. I'm not sure of what this actualy > : means.. This means that this version of fd.c has been broken :-). > Since I don't know what either PHOLD or PROC_LOCK are, I don't know if > I did this right. Maybe it is bogus. PHOLD() used to hold the user pages in core while the process waited for i/o to complete. The pc98 version of fd.c is rather out of date, so it still rather bogusly does DMA from the address where sys_generic.c:ioctl() copied the user data. This address may be on the kernel stack, so the driver needs to lock down the user pages until the DMA completes. I'm not sure if PROC_LOCK() does this accidentally. It gives a lock that is too strong in most ways. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern.flp blown out again
On Thu, Sep 13, 2001 at 11:26:40AM +0200, Wilko Bulte wrote: > Until you have to leave something essential out and then we are SOL. For > alpha I could think of only supporting CD installs, and drop floppies > altogether. This follows DECs/CPQs convention of only supporting OS installs Only after someone spends the time to fix src/release/Makefile to produce a boot image intended for CDROM booting. There is no reason we cannot have a 5 MB CD-ROM boot kernel image on the Alpha. Thus we would not need to cut anything out. JKH signed up to do this (poke, poke :-)), but that has yet to happen. Do you know what the size limit is for the CD-ROM boot image on Alpha(SRM)? -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
DEVFS and device nodes that reside outside of /dev
Hackers, here is small problem(?) with DEVFS and device nodes that reside outside of /dev directory. here is an example: recent patch for tap(4) added "cloning" feature. the tap(4) also implements support for vmnet device that required by VMWare port. however, vmnet device nodes reside in /compat/linux/dev. if you load if_tap module and try to access /dev/tap? device everything is working fine, but if you create device node *outside* of /dev directory and try to access it, *before* you access the same node under /dev, you will get "Device not configured". # pwd /root # mknod tap0 c 149 0 # kldload if_tap # cat tap0 cat: tap0: Device not configured # cat /dev/tap0 ^C # cat tap0 ^C # the same probably true for tun(4) device. is that a problem? is it the way it should work? thanks, max From: Doug Ambrisko Subject: Re: Anyone experience problems with the "tap" device in current? Doug Ambrisko wrote: > > Maksim Yevmenkin writes: > | Brooks Davis wrote: > | > > | > On Wed, Sep 12, 2001 at 04:59:16PM -0700, Doug Ambrisko wrote: > | > > I just tried using tap in current. In both cases I don't see the > | > > /dev/tapX devices with devfs and accessing it without devfs doesn't > | > > work reporting "Device not configured". I tried it as a module and > | > > built into the kernel. Does anyone have this working? > | > > | > With devfs, you just need to try opening the device and you'll get it if > | > it's not busy. You can also open /dev/tap and get an arbitrary one. > | > This is due to tun(4) style cloning code I committed recently. I'm not > | > actually sure this is the way we want to handle cloning hybrid devices, > | > but there is precident so I committed the patch. I think we may want to > | > move to a model were we use interface cloning rather then devfs cloning > | > because it will work in stable. > | > | patch was tested on -current as of Aug 31. everything was working for > | me. i'm upgrading my system now to test it. > > My mess up I forgot about the cloning changes, however, seems the minor > number for vmnet type devices changed: > > a21p% ls -l /compat/linux/dev/vmnet? > crw-r--r-- 1 root wheel 149, 0x00010001 Sep 5 17:11 /compat/linux/dev/vmnet1 > crw-r--r-- 1 root wheel 149, 0x00010002 Sep 5 19:37 /compat/linux/dev/vmnet2 > crw-r--r-- 1 root wheel 149, 0x00010003 Aug 9 13:58 /compat/linux/dev/vmnet3 > crw-r--r-- 1 root wheel 149, 0x00010004 Aug 13 14:02 /compat/linux/dev/vmnet4 > crw-r--r-- 1 root wheel 149, 0x00010005 Aug 10 11:31 /compat/linux/dev/vmnet5 > crw-r--r-- 1 root wheel 149, 0x00010006 Aug 30 10:22 /compat/linux/dev/vmnet6 > crw-r--r-- 1 root wheel 149, 0x00010007 Aug 30 10:22 /compat/linux/dev/vmnet7 > crw-r--r-- 1 root wheel 149, 0x00010008 Sep 5 17:22 /compat/linux/dev/vmnet8 > crw-r--r-- 1 root wheel 149, 0x00010009 Sep 5 16:57 /compat/linux/dev/vmnet9 > a21p% > > to: > > a2# ls -l /dev/vmnet? > crw--- 1 root wheel 149, 0x0080 Sep 12 17:32 /dev/vmnet0 > crw--- 1 root wheel 149, 0x0084 Sep 12 17:32 /dev/vmnet4 > crw--- 1 root wheel 149, 0x0086 Sep 12 17:32 /dev/vmnet6 > crw--- 1 root wheel 149, 0x0087 Sep 12 17:32 /dev/vmnet7 > a2# > > So for now I got around this via: > > a2# ls -l /compat/linux/dev/vmnet? > lrwxr-xr-x 1 root wheel 11 Sep 13 01:54 /compat/linux/dev/vmnet1 -> /dev/vmnet1 > lrwxr-xr-x 1 root wheel 11 Sep 13 01:54 /compat/linux/dev/vmnet2 -> /dev/vmnet2 > lrwxr-xr-x 1 root wheel 11 Sep 13 01:55 /compat/linux/dev/vmnet3 -> /dev/vmnet3 > lrwxr-xr-x 1 root wheel 11 Sep 13 01:55 /compat/linux/dev/vmnet4 -> /dev/vmnet4 > lrwxr-xr-x 1 root wheel 11 Sep 13 01:55 /compat/linux/dev/vmnet5 -> /dev/vmnet5 > lrwxr-xr-x 1 root wheel 11 Sep 13 01:54 /compat/linux/dev/vmnet6 -> /dev/vmnet6 > lrwxr-xr-x 1 root wheel 11 Sep 13 01:56 /compat/linux/dev/vmnet7 -> /dev/vmnet7 > lrwxr-xr-x 1 root wheel 11 Sep 13 01:56 /compat/linux/dev/vmnet8 -> /dev/vmnet8 > a2# > > Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: anonymous-ftp cracked
On Thu, Sep 13, 2001 at 12:13:08PM -0300, Rik van Riel wrote: > On Wed, 12 Sep 2001, Ted Mittelstaedt wrote: > > > nobody should be running an open FTP server that allows > > uploading to anyone unless they are willing to take the time to > > monitor it > > Some ftp daemons have the option to automatically email > the admins every time a file gets uploaded. Yes. NcFPTd (which has a version for FreeBSD) allows one to do this. It also has many other configuration options that I consider mandatory for anonymous ftp servers -- esp. ones with an incoming directory. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: anonymous-ftp cracked
> Ted: I've been watching this one because I've HAD to allow uploads to > incoming because of a need for such a place article submissions from our > Tech mag website from 175+ countries. > > Your tips for monitoring (like the script for a daily listing of the > directory) are so simple and obvious it put a smile on my face. Thanks! LUV > this list! Assuming you're using wuftpd: You may have to allow incoming, but perhaps you don't have to allow downloads of /incoming. Think about it. :-) Alternatively, wuftpd has a very nice notification feature that will mail you when something is submitted. Some of us do have good reasons for allowing both-way incoming access. Make sure your /incoming directory is unreadable in any case... > From [EMAIL PROTECTED] Thu Sep 13 18:42:44 2001 > Return-Path: <[EMAIL PROTECTED]> > Date: Thu, 13 Sep 2001 18:42:41 -0500 (CDT) > From: wu-ftpd <[EMAIL PROTECTED]> > Subject: New file uploaded: file.tmp > To: undisclosed-recipients:; > > jgreco@ uploaded /incoming/file.tmp from 206.55.xxx.xxx. > File size is 504586240. > Please move the file where it belongs. This has the advantage of being almost instantaneous. After an @Home wanker decided to fill a few gigabytes on snarchive, creating a denial-of-service to the legitimate users, I turned this on. Now when somebody tries to use me for their warez, I accidentally corrupt a bunch of bytes in their files. So far, they seem to have gotten the message, because I've only seen one unauthorized file attempted upload this week. >:-> -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
vmware2 KSE patches
Below you can find the patches that are needed to compile vmware2 on -current with the KSE changes. It works like a charm again. http://www.ripe.net/home/mark/files/vmware2_kse.patch.tgz Just extract the files in 'ports/emulators/vmware2/files/' and rebuild. Note: To get networking to work (due to the cloning problems with if_tap) you have to 'create' '/dev/vmnet1' and link to it from '/compat/linux/dev/vmnet1'. (see other thread about if_tap/cloning) Mark ps. Julian/KSE experts: this is a first hack at KSE for me so correct me if I should have solved it differently please. -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern.flp blown out again
On Thu, Sep 13, 2001 at 11:59:04AM +0300, Maxim Sobolev wrote: > Hehe, it's time to add bzip2 into loader ;) I had a patch, but it provides > only marginal improvement as due to memory constrains you can only use > 100k compression blocks, `bzip2 -1', but it still provides 3% better > compression that `gzip -9'. Commit!! :-) 3% can actually help here, and we can always improve on it over time. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern.flp blown out again
On Thu, Sep 13, 2001 at 06:37:22PM +0930, Daniel O'Connor wrote: > I have a patch for sysinstall which allows you to load kld's from a floppy. Please post!! :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern.flp blown out again
On 13-Sep-2001 David O'Brien wrote: > On Thu, Sep 13, 2001 at 06:37:22PM +0930, Daniel O'Connor wrote: > > I have a patch for sysinstall which allows you to load kld's from a floppy. > > Please post!! :-) http://www.gsoft.com.au/~doconnor/sysinstall-kld.diff I am thinking of storing which modules the user picks and then 'later' in the install process (post install) copying them into /modules (if they aren't already there) and modifying /boot/loader.conf. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: anonymous-ftp cracked
Ted: I've been watching this one because I've HAD to allow uploads to incoming because of a need for such a place article submissions from our Tech mag website from 175+ countries. Your tips for monitoring (like the script for a daily listing of the directory) are so simple and obvious it put a smile on my face. Thanks! LUV this list! At 09:28 PM 9.12.2001 -0700, Ted Mittelstaedt wrote: >>-Original Message- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED]]On Behalf Of Giorgos >>Keramidas >> >>Another common thing done in writable incoming/ directories is to create a >>file of fixed size, say 100 Mb, and use vnconfig to mount this file as the >>incoming/ directory of an FTP server. Then there's only about 100 Mb of >>space available in your incoming/ and nobody can store tons of data in there, >>wasting your disk space until disks are full. >> > >Hi Uli and Giorgos, > > I've had a bit of experience with this sort of thing and I have to say that >nobody should be running an open FTP server that allows uploading to anyone >unless they are willing to take the time to monitor it - and I mean every >day, preferably several times a day. > >100MB is plenty of space for some jerk to upload his collection >of Sally SpreadEagle in all her silicon glory. If that happens >your going to find every bit of outbound bandwidth you have completely >saturated. If your unlucky enough to have your FTP server at an >ISP you may find yourself fined heavily (ie: overage charges) > > Some people have a little script that runs out of cron and diffs the >output of ls against the previous run and e-mails the maintainer when new >files show up, others simply check by eye. Whatever works for you is fine, >but don't think that you can just put out public storage for anyone to use >as they see fit and just ignore it anymore. > > >Ted Mittelstaedt [EMAIL PROTECTED] >Author of: The FreeBSD Corporate Networker's Guide >Book website: http://www.freebsd-corp-net-guide.com > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-questions" in the body of the message > > Best regards, Jack L. Stone, Server Admin Sage-American http://www.sage-american.com [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: anonymous-ftp cracked
On Thu, 13 Sep 2001 09:08:17 EST, [EMAIL PROTECTED] wrote: > Your tips for monitoring (like the script for a daily listing of the > directory) are so simple and obvious it put a smile on my face. Thanks! LUV > this list! Since the damage of a cross-post is mostly done, I'm surprised nobody bothered to point out that, since you're already running -CURRENT (irrespective of whether it's a suitable platform for you to use), you may as well take advantage of the new -o and -O "write-only mode" options to ftpd. In your case, you probably want -O, "write-only mode for anonymous users only". There's no substitute for reading the documentation that accompanies the software you use. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: anonymous-ftp cracked
On Wed, 12 Sep 2001, Ted Mittelstaedt wrote: > nobody should be running an open FTP server that allows > uploading to anyone unless they are willing to take the time to > monitor it Some ftp daemons have the option to automatically email the admins every time a file gets uploaded. > 100MB is plenty of space for some jerk to upload his collection > of Sally SpreadEagle in all her silicon glory. If that happens > your going to find every bit of outbound bandwidth you have > completely saturated. That's what per-directory bandwidth limitations are for. If your /incoming needs to be usable for articles, you could just limit it to something like 2 kB/s per user. That's enough for legitimate articles, but for warez and porn it becomes effectively write-only. The only real problem is that people tend to upload the most worthless crap, so nothing interesting ever shows up in the 'harvesting' area. cheers, Rik -- IA64: a worthy successor to the i860. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't write CD-Rs with or without new DAO mode
Søren Schmidt <[EMAIL PROTECTED]> wrote:
> It seems Brian Fundakowski Feldman wrote:
> > After updating my system I can't burn CD-Rs successfully. Can anyone else?
> > What happens is pretty simple:
> >
> > {"/home/green/toxicity"}$ burncd -s 8 -d audio /dev/null $(ls | trackclassify >
> > burncd: ioctl(CDRIOCINITWRITER): Input/output error
> > acd0: MODE_SELECT_BIG - ILLEGAL REQUEST asc=0x26 ascq=0x00 error=0x00
>
> Are you absolutely sure your kernel & userland are in sync ?
Yes, I am. I just built a new kernel, did a make includes, and tried
recompiling burncd to the exact same effect.
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED]`--'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: kern.flp blown out again
On Thu, Sep 13, 2001 at 04:03:43AM -0700, David O'Brien wrote: > On Thu, Sep 13, 2001 at 11:26:40AM +0200, Wilko Bulte wrote: > > Until you have to leave something essential out and then we are SOL. For > > alpha I could think of only supporting CD installs, and drop floppies > > altogether. This follows DECs/CPQs convention of only supporting OS installs > > Only after someone spends the time to fix src/release/Makefile to produce > a boot image intended for CDROM booting. There is no reason we cannot > have a 5 MB CD-ROM boot kernel image on the Alpha. Thus we would not > need to cut anything out. JKH signed up to do this (poke, poke :-)), but > that has yet to happen. Do you know what the size limit is for the > CD-ROM boot image on Alpha(SRM)? I don't know of any size limit. Tru64 install CDs have 10MB (or so) kernels on them. -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/bin/ps print.c src/gnu/usr.bin/binutils/gdb/i386 freebsd-nat.c kvm-fbsd.c src/lib/libkvm kvm_proc.c src/sys/alpha/alpha db_interface.c db_trace.c exception.s fp_emulate.c genassym.c interrupt.c locore.s machdep.c mem.c ...
I'm amazed by the numbe of people running -current who have never heard of KSEs until now! The references are: http://www.freebsd.org/~jasone/kse/ and http://www.freebsd.org/~julian (see the threads link) julian Alexandr Listopad wrote: > > On Wed, Sep 12, 2001 at 01:38:13AM -0700, Julian Elischer wrote: > > julian 2001/09/12 01:38:13 PDT > > > > Modified files: > > bin/ps print.c > > gnu/usr.bin/binutils/gdb/i386 freebsd-nat.c kvm-fbsd.c > > lib/libkvm kvm_proc.c > > sys/alpha/alpha db_interface.c db_trace.c exception.s > > fp_emulate.c genassym.c interrupt.c > > [skip] > > > usr.bin/wproc_compare.c > > Log: > > KSE Milestone 2 > > What does it mean? > > > Note ALL MODULES MUST BE RECOMPILED > > make the kernel aware that there are smaller units of scheduling than the > > process. (but only allow one thread per process at this time). > > This is functionally equivalent to teh previousl -current except > > that there is a thread associated with each process. > > -- > Laa -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Alpha kernel breakage
In article <[EMAIL PROTECTED]>, Mike Barcroft <[EMAIL PROTECTED]> wrote: > Marcel Moolenaar <[EMAIL PROTECTED]> writes: > > > > BTW: I used cvsup9.freebsd.org. > > > > That reminds me, I have to let somebody know... > > It appears this was the problem. Switching to cvsup2.FreeBSD.org > seems to have have solved it. I assume this is a result of the S1G > bug in cvsup. FYI: I was using cvsup.ca.FreeBSD.org. Not intending to single out you folks in particular, but ... Just a reminder, people: Please, if you think something is wrong with a CVSup mirror, write to the maintainer of that mirror and tell him. All of the maintainers' e-mail addresses are listed in the Handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html#CVSUP-MIRRORS It doesn't do any good to tell the -current list; you have to tell the maintainer or the problem won't get fixed. Thanks, John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern.flp blown out again
< said: > It's just easier to keep band-aiding it, as ugly a scenario as that > might be. If we added a third disk with modules (This is based on somewhat dated sources, but I think that the idea is right.) wollman@khavrinen(305)$ ls -l *.gz -rwxr-xr-x 1 wollman sources 1232060 Sep 13 14:51 kernel.gz* -rwxr-xr-x 1 wollman sources 590239 Sep 13 15:13 lots-of-modules.ko.gz* Here's the config for that kernel (based on GENERIC): machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident GENERIC maxusers32 options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options MD_ROOT #MD is a potential root device options NFS #Network Filesystem options NFS_ROOT#NFS usable as root device, NFS required options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options KTRACE #ktrace(1) support options KBD_INSTALL_CDEV# install a CDEV entry in /dev device isa device eisa device pci device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices device amd # AMD 53C974 (Tekram DC-390(T)) device isp # Qlogic family device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device bt # Buslogic/Mylex MultiMaster SCSI adapters device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 device dpt # DPT Smartcache III, IV - See NOTES for options! device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct SCSI access) device ida # Compaq Smart RAID device atkbdc 1 # At keyboard controller device atkbd # at keyboard device psm # psm mouse device vga # VGA screen device splash device sc 1 device npx device apm device pmtimer device card# pccard bus device pcic# PCMCIA bridge device sio # 8250, 16[45]50 based serial ports device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip# TCP/IP over parallel device ppi # Parallel port interface device device miibus device cs # Crystal Semiconductor CS89x0 NIC device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device xe # Xircom pccard ethernet device awi # BayStack 660 and others device loop# Network loopback device ether # Ethernet support device sl # Kernel SLIP device ppp 1 # Kernel PPP device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device bpf # Berkeley packet filter device uhci# UHCI PCI->USB interface device ohci# OHCI PCI->USB interface device usb # USB Bus (required) device ugen device uhid device ukbd device umass device umodem device ums lots-of-modules.ko.gz is made by recursively linking together the following: ./modules/usr/src/sys/modules/aac/aac.kld ./modules/usr/src/sys/modules/aha/aha.kld ./modules/usr/src/sys/modules/aic/aic.kld ./modules/usr/src/sys/modules/amr/amr.kld ./modules/usr/src/sys/modules/asr/asr.kld ./modules/usr/src/sys/modules/cd9660/cd9660.kl
