[PATCH] wpa-supplicant script
Hi, the following work-in-slow-progress patch brings in some changes from FreeBSD that will allow to bring up a wireless interface with: ifconfig_ath0="up WPA DHCP" That is, besides the special parameters WPA and DHCP, all normal ifconfig parameters are possible in the ifconfig_... line now. The patch also adds interface renaming via rc.conf, e.g.: ifconfig_rl0_name="net0" ifconfig_net0="DHCP media 10baseT/UTP" http://leaf.dragonflybsd.org/~swildner/ifconfig_wpa.20070626.diff Don't forget -p0 as it adds the wpa_supplicant rc script. My work is eating most of my time at the moment so it's not the final version. Some things to consider with this version: * I haven't tested the pccard part at all. * Without "up" in the ifconfig_... line WPA doesn't yet seem to work it seems. Setting "DHCP polling" also didn't work last time I checked (didn't yet test if it works with "up", though). * FreeBSD has OpenBSD's dhclient so I had to comment out some stuff (that uses -b which we don't have) in dhclient's rc script. As I figure out these issues and find more stuff to add, I'll post another patch later next week or so. Sascha -- http://yoyodyne.ath.cx
Re: Watching a file system
:# cc -I/usr/src/sys ncptrace.c -o /usr/local/bin/ncptrace -lkvm :ncptrace.c: In function `dumpncp': :ncptrace.c:133: warning: comparison is always true due to limited range of :data type :ncptrace.c:143: error: `NCF_MOUNTPT' undeclared (first use in this function) :ncptrace.c:143: error: (Each undeclared identifier is reported only once :ncptrace.c:143: error: for each function it appears in.) : :I do like this idea though. :-- :Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] Use the ncptrace.c from HEAD. The debug code doesn't get updated reliably but the one in HEAD will compile under RELEASE. -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: Watching a file system
Matthew Dillon <[EMAIL PROTECTED]> writes: > If you just want a summary of what files were accessed you can use > ncptrace from /usr/src/test/debug/ncptrace.c. Read the header on > how to compile it. You would then be able to 'ncptrace /mnt' (or > wherever you mounted the CD) to dump the namecache for that mount > point. You can clear the cache by unmounting and remounting the CD. # cc -I/usr/src/sys ncptrace.c -o /usr/local/bin/ncptrace -lkvm ncptrace.c: In function `dumpncp': ncptrace.c:133: warning: comparison is always true due to limited range of data type ncptrace.c:143: error: `NCF_MOUNTPT' undeclared (first use in this function) ncptrace.c:143: error: (Each undeclared identifier is reported only once ncptrace.c:143: error: for each function it appears in.) I do like this idea though. -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< A man had lost a ring. His friend stopped by that morning and offered to help. By late-afternoon, his friend remarked "I don't see it anywhere. Are you sure you lost your ring here?" "Oh no," replied the man, "I lost it in the room over there...but the room is too dark. Here I can see better."
Re: Watching a file system
:Matthew Dillon <[EMAIL PROTECTED]> writes: :> You can monitor system calls made by programs with ktrace. : :Ok, but what if I want to watch access to a particular file system :(e.g. a mounted cdrom) by *all* system processes? :) :-- :Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] :>>> The opinions expressed above are entirely my own <<< ktrace can be told to attach to a process and all its descendants. Attach to pid 1 with that option and BANG, every single process in the system will be ktraced. You'll get a massive amount of data and performance will be terrible, though. Another option... export the CD via NFS and access it via NFS, and use tcpdump to monitor access. You won't get the cache hits, but you will get a good idea as to what is being accessed. It won't be pretty though. If you just want a summary of what files were accessed you can use ncptrace from /usr/src/test/debug/ncptrace.c. Read the header on how to compile it. You would then be able to 'ncptrace /mnt' (or wherever you mounted the CD) to dump the namecache for that mount point. You can clear the cache by unmounting and remounting the CD. -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: Watching a file system
: While you're at it would you commit the patch for implementing :jscan -o (in the submit@ archives title "Patch to implemet jscan -o") ? :Ah heck here it is again :) How'd I miss that! Committing it now. -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: Watching a file system
Matthew Dillon <[EMAIL PROTECTED]> writes: > You can monitor system calls made by programs with ktrace. Ok, but what if I want to watch access to a particular file system (e.g. a mounted cdrom) by *all* system processes? :) -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< Nasrudin found a weary falcon sitting one day on his window-sill. He'd never seen a bird of this kind before. "You poor thing," he said, "how ever were you allowed to get into this state?" He clipped the falcon's talons, cut its beak straight, and trimmed its feathers. "Now you look more like a bird."
Re: Watching a file system
On Tue, 26 Jun 2007 12:41:08 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
>
> :Is there a way to log all pathnames accessed by a specific mounted
> :file system?
> :--
> :Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED]
> :>>> The opinions expressed above are entirely my own <<<
>
> You can monitor system calls made by programs with ktrace.
>
> you can monitor *MODIFYING* operations to filesystems with the
> journaling support, e.g.:
>
> mountctl -a -o fd=1 /tmp:monitor | jscan -d
>
> Hmm. mountctl -l doesn't work. I'll go fix that.
While you're at it would you commit the patch for implementing
jscan -o (in the submit@ archives title "Patch to implemet jscan -o") ?
Ah heck here it is again :)
Index: jscan/dump_output.c
===
RCS file: /home/dcvs/src/sbin/jscan/dump_output.c,v
retrieving revision 1.3
diff -u -r1.3 dump_output.c
--- jscan/dump_output.c 7 Sep 2005 19:10:09 - 1.3
+++ jscan/dump_output.c 28 Jan 2007 16:05:17 -
@@ -39,5 +39,11 @@
void
dump_output(struct jsession *ss, struct jdata *jd)
{
+int written = write (STDOUT_FILENO, jd->jd_data, jd->jd_size);
+if (written != jd->jd_size)
+{
+perror ("Write to stdout failed");
+exit (1);
+}
jsession_update_transid(ss, jd->jd_transid);
}
--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins.| A better way to focus the sun
You lose and Bill collects. |licences available see
|http://www.sohara.org/
Re: Watching a file system
:Is there a way to log all pathnames accessed by a specific mounted :file system? :-- :Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] :>>> The opinions expressed above are entirely my own <<< You can monitor system calls made by programs with ktrace. you can monitor *MODIFYING* operations to filesystems with the journaling support, e.g.: mountctl -a -o fd=1 /tmp:monitor | jscan -d Hmm. mountctl -l doesn't work. I'll go fix that. -Matt Matthew Dillon <[EMAIL PROTECTED]>
Watching a file system
Is there a way to log all pathnames accessed by a specific mounted file system? -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< "War doesn't determine who's right. War determines who's left." -Confucious
Re: Using PKGSRC to install to non-standard LOCALBASE
reed <[EMAIL PROTECTED]> writes: > The "pkgviews" support is supposed to be able to do that also. I have used > it before, but last time I tried it didn't work for me anymore. (I have > read postings from others indicating it does work though.) Thanks for the pointer. I was unable to immediately determine how to get it to use a different LOCALBASE, but I have to say it's a fine idea in theory. I haven't put the requisite time in to consider whether the infrastructure work Matt Dillon on his new filesystem (i.e. the different views of a directory) might be a better solution to the problem that pkgviews is solving, but I'd certainly love to hear what more experienced minds have to say on this topic. In the meantime, I guess I'll be using the chrooted alternate pkgsrc build environment. -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< "It is a dragon, destroyer of all," cried the ants. Then a cat caught the lizard.
Re: Using PKGSRC to install to non-standard LOCALBASE
On Sun, 24 Jun 2007, Dave Hayes wrote: > If I wanted to build Apache, for example, out of pkgsrc but I wanted > it to be installed to a different prefix than LOCALBASE, how would I > do that? > > There's enough warnings about using different values for LOCALBASE > that I'd thought I'd check with the more experienced people out > there. The "pkgviews" support is supposed to be able to do that also. I have used it before, but last time I tried it didn't work for me anymore. (I have read postings from others indicating it does work though.) Jeremy C. Reed
Re: Apache in pkgsrc has largefile support on?
:>From /usr/pkgsrc/www/apache/Makefile: : : # Explicitly turn on large file support : APACHE_CUSTOM_CFLAGS+= -D_LARGEFILE_SOURCE : APACHE_CUSTOM_CFLAGS+= -D_FILE_OFFSET_BITS=64 : :DFly does not have largefile support yet, correct? So this should be :turned off for DFly, yes? :-- :Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] :>>> The opinions expressed above are entirely my own <<< : :Nasrudin, camping for the night, put down a bottle as a pillow. :"Mulla," said a friend, "surely that is going to be too hard?" :"As an ordinary bottle, yes" said Nasrudin, "but I am going to :stuff it with straw before I put my head on it." All BSD systems have native large-file support. off_t is 64 bits. This large-file crap was invented by Linux because they weren't forward thinking enough to use a 64 bit off_t at the beginning, even though at that time the BSDs already *HAD* 64 bit off_t's. Actually, I think Microsoft is to blame too, but at least they had an excuse 20 years ago. -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: Apache in pkgsrc has largefile support on?
On Tue, Jun 26, 2007 at 09:12:12AM -0700, Dave Hayes wrote: > From /usr/pkgsrc/www/apache/Makefile: > > # Explicitly turn on large file support > APACHE_CUSTOM_CFLAGS+= -D_LARGEFILE_SOURCE > APACHE_CUSTOM_CFLAGS+= -D_FILE_OFFSET_BITS=64 > > DFly does not have largefile support yet, correct? So this should be > turned off for DFly, yes? All BSDs have *only* largefile support except for kernel ABI compat. Joerg
Re: Apache in pkgsrc has largefile support on?
On Tue, 26 Jun 2007 09:12:12 -0700 Dave Hayes <[EMAIL PROTECTED]> wrote: > >From /usr/pkgsrc/www/apache/Makefile: > > # Explicitly turn on large file support > APACHE_CUSTOM_CFLAGS+= -D_LARGEFILE_SOURCE > APACHE_CUSTOM_CFLAGS+= -D_FILE_OFFSET_BITS=64 > > DFly does not have largefile support yet, correct? So this should be > turned off for DFly, yes? off_t is 64 bit by default on DFly. -- C:>WIN | Directable Mirror Arrays The computer obeys and wins.| A better way to focus the sun You lose and Bill collects. |licences available see |http://www.sohara.org/
Apache in pkgsrc has largefile support on?
>From /usr/pkgsrc/www/apache/Makefile: # Explicitly turn on large file support APACHE_CUSTOM_CFLAGS+= -D_LARGEFILE_SOURCE APACHE_CUSTOM_CFLAGS+= -D_FILE_OFFSET_BITS=64 DFly does not have largefile support yet, correct? So this should be turned off for DFly, yes? -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< Nasrudin, camping for the night, put down a bottle as a pillow. "Mulla," said a friend, "surely that is going to be too hard?" "As an ordinary bottle, yes" said Nasrudin, "but I am going to stuff it with straw before I put my head on it."
Re: Using PKGSRC to install to non-standard LOCALBASE
Justin C Sherrill <[EMAIL PROTECTED]> writes: > It may be possible to do something in a jail or with chroot where you > build a new pkgsrc location with a bootstrap, install to that location, > package up that install, and then use it with your normal pkgsrc install. This appears to be a working strategy when coupled with null mounts. It was kind of fun to do too. ;) Thanks. -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< "Obviously, the obvious is not obvious" --The Unknown Drummer
Re: Who maintains http://opengrok.creo.hu/dragonfly/ ?
On 2007-06-04, Dionysus Blazakis <[EMAIL PROTECTED]> wrote: > What does OpenGrok do better? I saw the OpenGrok feature matrix on > the website, but it wasn't very illuminating. Was there a compelling > reason to use it? I'm only asking out of curiosity -- tools for code > understanding tend to interest me and I haven't had a chance to play > with OpenGrok much. Well, it boils down to UI preferences. Eg. it speeds up browsing that for functions which are defined in the currently browsed file the occurrences of the function name are just anchors pointing to the location of the definition, and they don't trigger an overall source search for the identifier. I started my own xref service because the Dfly source on FXR was out of date. So my main problem was the content, not the web software. Nevertheless, I had to make a choice web-software-wise and I choose OpenGrok because it looked interesting (yes, you can say it was hyped). Now I will have a bit to catch up... Btw, these guys: http://openit.disco.unimib.it had a very promising enhanced LXR version -- eg., it could also display the names of the functions which are calling a given function, IIRC -- but they took it off. Csaba
Re: Who maintains http://opengrok.creo.hu/dragonfly/ ?
On 2007-06-04, Justin C. Sherrill <[EMAIL PROTECTED]> wrote: > Csaba Henk <[EMAIL PROTECTED]>, if I remember correctly. I haven't heard > anything from Csaba in a while - Csaba, you reading the lists? Currently it's the DragonFly BSD Log which I read regularly. I will take a look at the OpenGrok issue, thank you for notifying me. Csaba
