[9fans] dns SRV records
Investigating the possibility of replacing the MS DNS on Plan9 DNS,not found in the man ndb mention of records of type SRV. It is necessary to support Microsoft Active Directory. Maybe I missed something? http://en.wikipedia.org/wiki/SRV_record
Re: [9fans] dns SRV records
Hello ! As far as I know, ndb have support for SRV, PTR, TXT resords. There is no sample, of cause :) I think tha it may look like this: ip=10.0.0.1 sys=_service dom=_tcp.local srv= 2011/4/28 Sergey Kornilovich : > Investigating the possibility of replacing the MS DNS on Plan9 DNS,not found > in the man ndb mention of records of type SRV. > It is necessary to support Microsoft Active Directory. Maybe I missed > something? > http://en.wikipedia.org/wiki/SRV_record > -- С наилучшими пожеланиями Жилкин Сергей With best regards Zhilkin Sergey
Re: [9fans] spaces in filenames
spaces in filenames.. does not it break the rules?? Who actually needs them?? ++pac
Re: [9fans] spaces in filenames (and filesystems...)
On Thu, Apr 28, 2011 at 11:58:01AM +0200, Peter A. Cejchan wrote: > spaces in filenames.. does not it break the rules?? Who actually needs > them?? > > ++pac Mostly people who have grown up with graphical user interfaces and have no appreciation of the command line parsing complexity it adds I think. And of course others that have to interract with such people, such as sharing filesystems with them. On a slightly related topics, one of my constant headaches lately is the problem of deciding what filesystem to put on large capacity removeable storage to give me maximum interoperability... What I really want is somthing that I can copy files to and from from any of my OSs without losing meta-data. NTFS seems to be reasonably capable, but pervesely designed to be difficult to write to other than from Windows. FAT32 has limitations such as with the metadata it can represent, and anything else is problematic with certain commonly used proprietary OSs. If there was one clear winner, then I suppose filesystem drivers could be (maybe are) made available for the proprietary systems. Perhaps this is what UFS was designed for if it is not overly optimised for optical media. Anyone have any ideas here? Regards, DigbyT -- Digby R. S. Tarvin digbyt(at)digbyt.com http://www.digbyt.com
Re: [9fans] portable filesystem (was: spaces in filenames (and filesystems...))
On Thursday 28 of April 2011 14:11:27 Digby Tarvin wrote: > On a slightly related topics, one of my constant headaches lately > is the problem of deciding what filesystem to put on large capacity > removeable storage to give me maximum interoperability... > > What I really want is somthing that I can copy files to and from > from any of my OSs without losing meta-data. ext2/ext3 seems to work between windows and linux for free [1], and macos x with some payment [2] or perhaps for free via FUSE. surprisingly, you can even use LUKS [3] with it and it still works r/w between windows and linux. no idea about p9, sorry, but there used to be a r/o ext2 driver. you can freely convert filesystem between ext2 and ext3 mode on linux. at some point i had that crazy idea to have a pendrive formatted in ext3 or nilfs2, with small auxiliary partition with a virtual machine -- and use the virtual machine as a filesystem server when on hostile OS. personally, i'd love to have nilfs2 [4] ported to p9 and windows; but i guess it's matter of future. [1] http://www.ext2fsd.com/ [2] (lost the link, sorry) [3] http://www.freeotfe.org/ on windows, cryptsetup on linux [4] http://www.nilfs.org/ -- dexen deVries [[[↓][→]]] ``In other news, STFU and hack.'' mahmud, in response to Erann Gat's ``How I lost my faith in Lisp'' http://news.ycombinator.com/item?id=2308816
Re: [9fans] portable filesystem (was: spaces in filenames (and
> no idea about p9, sorry, but there used to be a r/o ext2 driver. not just r/o - ext2srv(4)
Re: [9fans] portable filesystem (was: spaces in filenames (and filesystems...))
On Thu, Apr 28, 2011 at 02:35:56PM +0200, dexen deVries wrote: > On Thursday 28 of April 2011 14:11:27 Digby Tarvin wrote: > > On a slightly related topics, one of my constant headaches lately > > is the problem of deciding what filesystem to put on large capacity > > removeable storage to give me maximum interoperability... > > > > What I really want is somthing that I can copy files to and from > > from any of my OSs without losing meta-data. > > ext2/ext3 seems to work between windows and linux for free [1], and macos x > with some payment [2] or perhaps for free via FUSE. > surprisingly, you can even use LUKS [3] with it and it still works r/w > between > windows and linux. > > no idea about p9, sorry, but there used to be a r/o ext2 driver. > > you can freely convert filesystem between ext2 and ext3 mode on linux. Thanks. I did experiment with a couple of Windows based ext2/ext3 options a while ago, with limited success. I dont remember the details, but the filesystem I wanted to read was rejected with an obscure error message. I think the fac suggested re-formatting my filesystem might help, and that put me off. But as I said, that was quite a while ago, so maybe it is worth revisiting. Ext2fsd looks promising. However I do wish that at least the Unix world would settle on a common filesystem format to support (in addition whatever is native) other than FAT32 or NTFS. I dont currently use MACOS X, but I do use BSD on some servers. If I go Ext2/Ext3 then I am probably reducing my interoperability with more esoteric operating systems, which might be livable but is unfortunate. > at some point i had that crazy idea to have a pendrive formatted in ext3 or > nilfs2, with small auxiliary partition with a virtual machine -- and use the > virtual machine as a filesystem server when on hostile OS. Not a bad idea, but you probably want an intelligent device able to run the virtual machine itself (in which case it isnt really virtual), otherwise you are limited to hostile os's with virtual machine support. Perhaps a file server on a wireless or usb equipped smart phone... I have a small wireless hotspot that also can serve files from an optional MicroSD. But I am thinking more of the 2TB or more USB drives that are now quite affordable, but more useful if not tied to a single OS. > personally, i'd love to have nilfs2 [4] ported to p9 and windows; but i guess > it's matter of future. Nice. I hadnt come across that one. But What I think is really needed for this sort of application is a filesystem with: Minimal restrictions of file size (64 bit addresses) Maximum versatility in FS topology (hard link support etc) Minimal restriction on file names (character set, length) Maximum support for all conceiveable meta-data. My off the top of the head solution would be a filesystem were each file has two open ended data forks. One for conventional file content, and the other used for tagged meta-data. Each OS supporting the filesystem would be able to define meta-data fields such that all meta data meaningful to the original filesystem could be retained in files copied to the removeable system, and mapped to ANSI equivalent standards meta data fields where appropriate. File accesses would interpret native metadata with fallback to the ANSI as required. I suppose it should even be able to suport slashes and nulls in file names, although that would make such fules hard to deal with from Unix. At least it would be usable as a universal backup and file transfer medium. Failing that, a simple and universally adopted filesystem - like FAT, but without the stupid limitations, would be a step forward. Regards, DigbyT -- Digby R. S. Tarvin digbyt(at)digbyt.com http://www.digbyt.com
Re: [9fans] portable filesystem (was: spaces in filenames (and filesystems...))
On Thursday 28 of April 2011 16:00:53 Digby Tarvin wrote: > > at some point i had that crazy idea to have a pendrive formatted in ext3 > > or nilfs2, with small auxiliary partition with a virtual machine -- and > > use the virtual machine as a filesystem server when on hostile OS. > > Not a bad idea, but you probably want an intelligent device able to > run the virtual machine itself (in which case it isnt really virtual), > otherwise you are limited to hostile os's with virtual machine support. > > Perhaps a file server on a wireless or usb equipped smart phone... > I have a small wireless hotspot that also can serve files from an > optional MicroSD. funny thing, my current pendrive (which really is nokia n900 phone) has abundance of powerful hardware -- cpu, ram and 32GB + microSD block storage. you got me fantasizing. 9p served over usb (either directly, as mentioned recently in somebody's post about registering usb ids), or over tcp/ip over usb would be cool. if only various OSes interfaced with that easily. another silly, but perhaps doable, approach could be to make the phone serve either ext2/ext3 or fat, translated on-the-fly from whatever's the underlying fs. as in, the (say) fat would not reside literally on the device, but relevant parts would be generated on-demand by the phone in its ram and presented as a blockdevice over usb mass storage proto. in a way, a reverse of typical p9 fileserver -- read files, serve filesystem image. um, how crazy is that? -- dexen deVries [[[↓][→]]] ``In other news, STFU and hack.'' mahmud, in response to Erann Gat's ``How I lost my faith in Lisp'' http://news.ycombinator.com/item?id=2308816
Re: [9fans] portable filesystem (was: spaces in filenames (and filesystems...))
On Thursday 28 of April 2011 16:00:53 Digby Tarvin wrote: > But What I think is really needed for this sort of application is a > filesystem with: > Minimal restrictions of file size (64 bit addresses) > Maximum versatility in FS topology (hard link support etc) > Minimal restriction on file names (character set, length) > Maximum support for all conceiveable meta-data. > > My off the top of the head solution would be a filesystem were each file > has two open ended data forks. One for conventional file content, and the > other used for tagged meta-data. Each OS supporting the filesystem would > be able to define meta-data fields such that all meta data meaningful to > the original filesystem could be retained in files copied to the > removeable system, and mapped to ANSI equivalent standards meta data > fields where appropriate. File accesses would interpret native metadata > with fallback to the ANSI as required. I suppose it should even be able to > suport slashes and nulls in file names, although that would make such > fules hard to deal with from Unix. > > At least it would be usable as a universal backup and file transfer medium. > > Failing that, a simple and universally adopted filesystem - like FAT, but > without the stupid limitations, would be a step forward. long time ago, iso9660 was supplanted/extended in-line by jolliet and/or ufs. the new filesystem was interleaved with the iso9660. control structures were mostly separate, partly shared; bulk data was just shared. perhaps something along those lines could be doable with `smart' pendrives (like my nokia n900 phone), that would keep all two/three fses in sync. or, just have two or three filesystems residing at separate addresses (partitions?) of block device, but having shared de-duplicating backend like venti. so the bulk data doesn't occupy more blocks than needed. meta: terribly sorry for spamming with those very hairy ideas. -- dexen deVries [[[↓][→]]] ``In other news, STFU and hack.'' mahmud, in response to Erann Gat's ``How I lost my faith in Lisp'' http://news.ycombinator.com/item?id=2308816
[9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
OK,
So I'm trying to compile the pcf kernel from quanstro's 9atom.iso.bz2.
There seems to be an undocumented dependency on the quanstro/fis
contrib(1). (Without it, 8c complains that it can't find an include
file named fis.h or some such.) I now have that.
I've also added the two assembly routines (_tracein and _traceout) to
/sys/src/libc/386/trace.s, as specified, and rebuilt and reinstalled
libc.
Nevertheless, when running mk 'CONF=pcf', the build fails with the
following error:
8l -p -e -o 9pcf -T0xF0100020 -l l.8 plan9l.8 [...]
size 9pcf
_strayintrx: _tracein/_traceout not defined 5 5
_strayintrx: _tracein: not defined
_strayintrx: _traceout: not defined
mk: 8c -FTVw '-DKERNDATE='`{date ... : exit status=rc 5800: 8l 5804: error
The only source file which seems to reference '_strayintrx' is l.s.
--
+---+
|E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B|
+---+
[9fans] how big?
so i was looking at what's going on with gs. it appears to be having ape issues. but along the way this cropped up: ; ps -a | grep gs quanstro 795900:04 0:03 4292893752K Broken gs -dNOPAUSE -dDELAYSAFER -sDEVICE=plan9 -sOutputFile=/fd/3 -dQUIET -r100 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 - that's interesting. 4TB of memory. i don't recall having that much memory. /proc/79590/segment looks a little more reasonable, and hints at the problem, with the bucky bit being set ; cat /proc/79590/segment Stack defff000 d0001 Text R 1000 002320001 Data 00232000 002b80001 Bss 002b8000 8170f0001 it turns out to be a sign extension problem in devproc. since we need to face up to 64 bits at some point, i just used a uvlong /n/dump/2011/0428/sys/src/9/port/devproc.c:677,682 - devproc.c:677,683 char *a, flag[10], *sps, *srv, statbuf[NSEG*64]; int i, j, m, navail, ne, pid, rsize; long l; + uvlong u; uchar *rptr; ulong offset; Confmem *cm; /n/dump/2011/0428/sys/src/9/port/devproc.c:857,869 - devproc.c:858,870 readnum(0, statbuf+j+NUMSIZE*i, NUMSIZE, l, NUMSIZE); } /* ignore stack, which is mostly non-existent */ - l = 0; + u = 0; for(i=1; iseg[i]; if(s) - l += s->top - s->base; + u += s->top - s->base; } - readnum(0, statbuf+j+NUMSIZE*6, NUMSIZE, l>>10, NUMSIZE); + readnum(0, statbuf+j+NUMSIZE*6, NUMSIZE, u>>10u, NUMSIZE); readnum(0, statbuf+j+NUMSIZE*7, NUMSIZE, p->basepri, NUMSIZE); readnum(0, statbuf+j+NUMSIZE*8, NUMSIZE, p->priority, NUMSIZE); memmove(a, statbuf+offset, n); a test machine gives more reasonable numbers ; ps -a | grep gs quanstro2650:02 0:01 2120760K Broken gs -dNOPAUSE -dDELAYSAFER -sDEVICE=plan9 -sOutputFile=/fd/3 -dQUIET -r100 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 - - erik
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
> So I'm trying to compile the pcf kernel from quanstro's 9atom.iso.bz2.
> There seems to be an undocumented dependency on the quanstro/fis
> contrib(1). (Without it, 8c complains that it can't find an include
> file named fis.h or some such.) I now have that.
>
> I've also added the two assembly routines (_tracein and _traceout) to
> /sys/src/libc/386/trace.s, as specified, and rebuilt and reinstalled
> libc.
>
> Nevertheless, when running mk 'CONF=pcf', the build fails with the
> following error:
>
> 8l -p -e -o 9pcf -T0xF0100020 -l l.8 plan9l.8 [...]
> size 9pcf
> _strayintrx: _tracein/_traceout not defined 5 5
> _strayintrx: _tracein: not defined
> _strayintrx: _traceout: not defined
> mk: 8c -FTVw '-DKERNDATE='`{date ... : exit status=rc 5800: 8l 5804:
> error
_straintrx is a red herring. have you recompiled libc?
- erik
Re: [9fans] portable filesystem
dexen deVries writes: tar? webdav? > in a way, a reverse of typical p9 fileserver -- read files, serve filesystem > image. I was thinking of that. An embedded Linux or Plan 9 device as USB client, presenting an MSD interface. It could present a number of partitions, each with an partition/fs type liked by different OSes. Whichever partition ends up getting read by the OS selects the fs that the device serves. If the device presented a USB network interface, various network servers could be used... webdav, FTP, etc. Think NAS-in-your-pocket. -- +---+ |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] portable filesystem (was: spaces in filenames (and filesystems...))
On Thu, Apr 28, 2011 at 04:13:17PM +0200, dexen deVries wrote: > > funny thing, my current pendrive (which really is nokia n900 phone) has > abundance of powerful hardware -- cpu, ram and 32GB + microSD block storage. > you got me fantasizing. > > 9p served over usb (either directly, as mentioned recently in somebody's post > about registering usb ids), or over tcp/ip over usb would be cool. if only > various OSes interfaced with that easily. > > another silly, but perhaps doable, approach could be to make the phone serve > either ext2/ext3 or fat, translated on-the-fly from whatever's the underlying > fs. as in, the (say) fat would not reside literally on the device, but > relevant parts would be generated on-demand by the phone in its ram and > presented as a blockdevice over usb mass storage proto. > > in a way, a reverse of typical p9 fileserver -- read files, serve filesystem > image. > > > um, how crazy is that? > Well, if you are going to serve in a format that is distinct from what is actually used on the physical media, why not just provide servers for multiple formants - 9p, nfs, smb etc.. I think there are some network enabled external drives that already do that (maybe not the 9p yet).. Of course if you are backing up filesystems, then you still really need a the media and served formats to be capable of preserving all relevent metadata. I encountered this most recently on a project where I was developing an embedded Linux application for a client whose development environment was exclusively Windows cross development based. I developed on my Linux laptop, but they wanted the kernel source tree checked into their surround SCM. I tried using samba to copy the tree to windows (which hosted the surround client) but of course it failed after about half an hour due to some incompatible file names. Trying to check in a complete vmware image exceeded the maximum file size, and in any case would have defeated the revision management capabilities. Any renaming of files would have broken who knows how many parts of the convoluted set of makefiles and scripts. If you only care about the contents of a modest number of files, interoperability isnt such a big problem. If you want to be able to make accurate backups of entire filesystems then it gets hard if the target is not a natice filesystem format. Regards, DigbyT -- Digby R. S. Tarvin digbyt(at)digbyt.com http://www.digbyt.com
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
erik quanstrom writes:
>> size 9pcf
>> _strayintrx: _tracein/_traceout not defined 5 5
>> _strayintrx: _tracein: not defined
>> _strayintrx: _traceout: not defined
>> mk: 8c -FTVw '-DKERNDATE='`{date ... : exit status=rc 5800: 8l 5804:
>> error
>
> _straintrx is a red herring. have you recompiled libc?
Yes, I'm sure. :) In typical paranoid newbie fashion, I made sure to do
an 'ls -l /386/lib' before trying to build the kernel... oh, wait. Let
me try a 'mk clean' first... nope. Same error.
Remember, I'm running your 9atom 9pcf.gz, with quanstro/fis, on an
otherwise stock P9 4e fossil+venti system.
Hm. The /386/lib/libc.a and the one on /n/dump have the same exact
size. But they have different contents (cmp differ @ char 26). It sure
looks like I recompiled and installed libc.
--
+---+
|E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B|
+---+
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
> Yes, I'm sure. :) In typical paranoid newbie fashion, I made sure to do > an 'ls -l /386/lib' before trying to build the kernel... oh, wait. Let > me try a 'mk clean' first... nope. Same error. how about cd /sys/src/libc; mk && mk clean - erik
Re: [9fans] dns SRV records
There is a package called zonefresh in my contrib, this doea and axfr transfer from the given host/domain and writes an ndb file with the results. This understands srv records though I have never tried re-exporting the info from ndb and checking the results agains msdns. you should be able to do this however. -Steve
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
erik quanstrom writes: Wow, you know, as a Gentoo user, I'm amazed AMAZED amazed amazed AMAZED amazed how fast Plan 9 can compile a kernel or libc. Compiling glibc (on Linux) usually takes over half a day. Compiling a kernel generally takes a couple of hours. This is great! > how about > > cd /sys/src/libc; mk && mk clean Just tried it. Same error. Is there perhaps some other source dependency we're not thinking of? In case it's relevant, I have the source in /sys/src/9atom instead of /sys/src/9, but I doubt that would break anything. -- +---+ |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
> This is great! it is, isn't it? 6 seconds kernel compile, 15 seconds turnaround time when developing anything in the kernel (with PXE boot). beat that, modern operating systems :)
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Thu, Apr 28, 2011 at 10:35 AM, andrey mirtchovski wrote: >> This is great! > > it is, isn't it? 6 seconds kernel compile, 15 seconds turnaround time > when developing anything in the kernel (with PXE boot). beat that, > modern operating systems :) yes, I had to help config and build a linux kernel yesterday; every time I see it I just want to claw my eyes out. And it gets worse every month ... ron
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Thu Apr 28 13:25:13 EDT 2011, smi...@zenzebra.mv.com wrote: > erik quanstrom writes: > > Wow, you know, as a Gentoo user, I'm amazed AMAZED amazed amazed AMAZED > amazed how fast Plan 9 can compile a kernel or libc. Compiling glibc > (on Linux) usually takes over half a day. Compiling a kernel generally > takes a couple of hours. This is great! i pity andrey for his poor setup. usually a kernel compile takes < 2s here, and with /dev/reboot, i can be starting a new kernel within 100ms. > > > how about > > > > cd /sys/src/libc; mk && mk clean > > Just tried it. Same error. > ; 9diff mkfile /n/sources/plan9//sys/src/libc/386/mkfile:23,28 - mkfile:23,29 strcpy.s\ strlen.s\ tas.s\ + trace.s\ vlop.s\ - erik
Re: [9fans] dns SRV records
See ndb(6).
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
Ron wrote: > andrey mirtchovski > > wrote: > >> This is great! > > > > it is, isn't it? 6 seconds kernel compile, 15 seconds > turnaround time > > when developing anything in the kernel (with PXE > boot). beat that, > > modern operating systems :) > > yes, I had to help config and build a linux kernel > yesterday; every > time I see it I just want to claw my eyes out. And it gets > worse every > month ... Life is too short to configure and compile Linux and GNU software. BLS
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
>Compiling glibc (on Linux) usually takes over half a day. you're not counting iterations where something goes wrong, as it always does for me.
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Apr 28, 2011, at 1:50 PM, Brian L. Stuart wrote: > Life is too short to configure and compile Linux and > GNU software. > > BLS another nomination for the fortunes file
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Thursday 28 of April 2011 20:50:14 Brian L. Stuart wrote: > Life is too short to configure and compile Linux and > GNU software. or spending days on choosing a computer with all the hardware supported. oh wait. to the wit: the current hacker-unfriendlines of linux (a.k.a. `user friendlines') is the price paid for vide driver support. -- dexen deVries ``One can't proceed from the informal to the formal by formal means.''
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Thu Apr 28 15:30:38 EDT 2011, dexen.devr...@gmail.com wrote: > On Thursday 28 of April 2011 20:50:14 Brian L. Stuart wrote: > Life is > too short to configure and compile Linux and > GNU software. > > or spending days on choosing a computer with all the hardware > supported. oh wait. that's not how you do it. you spend about the normal amount of time checking, and then when you get the machine you fix what's left. :-) i've just configured an new xeon 1155, which has had a nic that wasn't quite supported (pch2 lan + 82579 phy), and a wierd lapic/ioapic configuration. all told, it was only about a day to get it working. now i could have spend that amount of time with an os that might have supported everything out-of-the-box, but it's doubtful that i'd have it even configured yet. - erik
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Apr 28, 2011, at 3:29 PM, dexen deVries wrote: > the current hacker-unfriendlines of linux (a.k.a. `user > friendlines') is the price paid for vide driver support. perhaps in some vague philosophical terms, but certainly that isn't any sort of actual engineering trade-off. you also seem to be positing that linux scores highly on "user friendly" measures, which seems wrong. PGP.sig Description: This is a digitally signed message part
Re: [9fans] dns SRV records
>Investigating the possibility of replacing the MS DNS on Plan9 DNS,not found >in the man ndb mention of records of type SRV. >It is necessary to support Microsoft Active Directory. Maybe I missed >something? >http://en.wikipedia.org/wiki/SRV_record I got AD to work with Plan 9 DNS just last year. It didn't work very well, and I had problems with the DNS service dying from time to time and I'd have to go restart it. Much as I'd preferred to have stayed on Plan 9 DNS, I switched to BIND 9 on OpenBSD and have had far fewer problems. But anyway, here's the Active Directory support portion of my /ndb/local. This supported a domain whose domain was "testad". Like I said, it works, but not as seamlessly as MS DNS or BIND 9 with dynamic updates enabled... (pardon the excessive comments) # # # Active Directory support # See http://technet.microsoft.com/en-us/library/dd316373.aspx # # # # Domain Controllers: # ip=10.0.0.20 sys=kfdc1 dom=kfdc1.testad.test.local ether= ip=10.0.0.21 sys=kfdc2 dom=kfdc2.testad.test.local ether=005056b36086 # # requisite CNAME aliases # cname=kfdc2.testad.test.local dom=testad.test.local cname=kfdc2.testad.test.local dom=8df1f9af-8c89-4263-9c30-a40ad5ac728f._msdcs.testad.test.local # # SRV records, etc # dom=testad.test.local soa= refresh=3600 ttl=3600 ns=ns2.test.local #ns=ns1.test.local dnsdomain=testad.test.local dom=_ldap._tcp.testad.test.local soa= srv=kfdc1.testad.test.local pri=0 weight=0 port=389 srv=kfdc2.testad.test.local pri=1 weight=1 port=389 dom=_kerberos._tcp.testad.test.local soa= srv=kfdc1.testad.test.local pri=0 weight=0 port=88 srv=kfcd2.testad.test.local pri=1 weight=1 port=88 dom=_kpasswd._udp.testad.test.local soa= srv=kfdc1.testad.test.local pri=0 weight=0 port=464 srv=kfdc2.testad.test.local pri=1 weight=1 port=464 dom=_kpasswd._tcp.testad.test.local soa= srv=kfdc1.testad.test.local pri=0 weight=0 port=464 srv=kfdc2.testad.test.local pri=1 weight=1 port=464 dom=_ldap._tcp.dc._msdcs.testad.test.local soa= srv=kfdc1.testad.test.local pri=0 weight=0 port=389 srv=kfdc2.testad.test.local pri=1 weight=1 port=389 dom=_ldap._tcp.gc._msdcs.testad.test.local soa= srv=kfdc1.testad.test.local pri=0 weight=0 port=389 srv=kfdc2.testad.test.local pri=1 weight=1 port=389 # only one PDC dom=_ldap._tcp.pdc._msdcs.testad.test.local soa= srv=kfdc2.testad.test.local pri=0 weight=0 port=389 dom=_ldap._tcp.KlamathFalls._sites.gc._msdcs.testad.test.local soa= srv=kfdc1.testad.test.local pri=0 weight=0 port=389 srv=kfdc2.testad.test.local pri=1 weight=1 port=389 dom=_kerberos._tcp.dc._msdcs.testad.test.local soa= srv=kfdc1.testad.test.local pri=0 weight=0 port=88 srv=kfdc2.testad.test.local pri=1 weight=1 port=88 dom=gc._msdcs.testad.test.local soa= srv=kfdc1.testad.test.local pri=0 weight=0 port=3268 srv=kfdc2.testad.test.local pri=1 weight=1 port=3268 dom=_gc._tcp.testad.test.local soa= srv=kfdc1.testad.test.local pri=0 weight=0 port=3268 srv=kfdc2.testad.test.local pri=1 weight=1 port=3268 dom=_ldap._tcp.e3514235-4b06-11d1-ab04-00c04fc2dcd2.domains._msdcs.testad.test.local srv=kfdc1.testad.test.local pri=0 weight=0 port=389 srv=kfdc2.testad.test.local pri=1 weight=1 port=389 # Key Management Service dom=_VLMCS._tcp.testad.test.local soa= srv=kfdc2.testad.test.local pri=0 weight=0 port=1688 dom=_ldap._tcp.KlamathFalls._sites.domaindnszones.testad.test.local soa= srv=kfdc1.testad.test.local pri=0 weight=0 port=389 srv=kfdc2.testad.test.local pri=1 weight=1 port=389 dom=_ldap._tcp.domaindnszones.testad.test.local soa= srv=kfdc1.testad.test.local pri=0 weight=0 port=389 srv=kfdc2.testad.test.local pri=1 weight=1 port=389 dom=_ldap._tcp.KlamathFalls._sites.forestdnszones.testad.test.local soa= srv=kfdc1.testad.test.local pri=0 weight=0 port=389 srv=kfdc2.testad.test.local pri=1 weight=1 port=389 dom=_ldap._tcp.forestdnszones.testad.test.local soa= srv=kfdc1.testad.test.local pri=0 weight=0 port=389 srv=kfdc2.testad.test.local pri=1 weight=1 port=389 # # # End Active Directory Support # #
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Thursday, April 28, 2011 12:39:07 PM erik quanstrom wrote: > On Thu Apr 28 15:30:38 EDT 2011, dexen.devr...@gmail.com wrote: > > On Thursday 28 of April 2011 20:50:14 Brian L. Stuart wrote: > Life is > > too short to configure and compile Linux and > GNU software. > > > > or spending days on choosing a computer with all the hardware > > supported. oh wait. > > that's not how you do it. you spend about the normal amount > of time checking, and then when you get the machine you fix > what's left. :-) > > i've just configured an new xeon 1155, which has had a nic > that wasn't quite supported (pch2 lan + 82579 phy), and a > wierd lapic/ioapic configuration. > > all told, it was only about a day to get it working. > > now i could have spend that amount of time with an os that might > have supported everything out-of-the-box, but it's doubtful that i'd > have it even configured yet. > I'd be more excited about quick compile times on plan 9 when I can use plan 9 to check my bank account, watch youtube videos, and order movie tickets or pizza over the web. But I still need a loonix box to do those things, so I still need to suffer the horrors of glibc[1] and ~760M kernel sources - which is unfortunate. I understand why plan 9 avoids posix and unix and gtk+ and the gnu toolchain - or flash, or firefox, etc., etc. - but it would be nice if it had fuller, more complete support for "the web". I wish AWE would manifest. APE - "a posix environment" vs. AWE - "a web(kit) environment". Alas, if wishes were fishes... (we'd all be rich fishermen). Though I don't understand why folks around here complain about "linux" so often and so vehemently, when the only reason why you're complaining is because you _need_ linux... to furnish all the things you can't do with plan 9 - either personally, or within your organization. [1] For those gnashing teeth over glibc - might want to check out musl libc. It's no plan 9 libc, but it's definitely "less worse" than glibc.
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
errno, you sound like you may be trespassing on our collective 9fans lawn. i wave a cane in your general direction.
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
> Though I don't understand why folks around here complain about > "linux" so often and so vehemently, when the only reason why you're > complaining is because you _need_ linux... to furnish all the things > you can't do with plan 9 - either personally, or within your organization. people who care about Doing Things Right are easy to upset. - erik
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
erik quanstrom writes: > ; 9diff mkfile > /n/sources/plan9//sys/src/libc/386/mkfile:23,28 - mkfile:23,29 > strcpy.s\ > strlen.s\ > tas.s\ > + trace.s\ > vlop.s\ Oh, of course! If it isn't assembled, the loader will never find the symbols. :) That addition enabled libc to compile successfully. The subsequent kernel compile succeeded as well. After a reboot, my file system is now able to store files with spaces in their names. Yeay! Much thanks! (Interestingly, the 9pcf.gz produced was about 7KB smaller than the one you gave me. I'm guessing that there's some additional stuff in your 9pcf that's not in mine, but it seems to be working fine.) -- +---+ |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
> (Interestingly, the 9pcf.gz produced was about 7KB smaller than the one > you gave me. I'm guessing that there's some additional stuff in your > 9pcf that's not in mine, but it seems to be working fine.) you're using 16-bit runes, and the standard pre-unicode 3.0 tables, which are smaller. - erik
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Thu, Apr 28, 2011 at 7:00 PM, errno wrote: > [1] For those gnashing teeth over glibc - might want to check out > musl libc. It's no plan 9 libc, but it's definitely "less worse" than glibc. Once I get my teeth back in I will gnash them even more. ron
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Thu, 28 Apr 2011 19:00:49 PDT errno wrote: > > Though I don't understand why folks around here complain about > "linux" so often and so vehemently, when the only reason why you're > complaining is because you _need_ linux... to furnish all the things > you can't do with plan 9 - either personally, or within your organization. Nobody *needs* linux. That is like saying people need McDonald's. What people need is to *eat*. Not the same thing. If they are forced to eat at McDonald's when they know better alternatives exist, they are going to complain. Bitterly.
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Thursday, April 28, 2011 08:03:23 PM erik quanstrom wrote: > > Though I don't understand why folks around here complain about > > "linux" so often and so vehemently, when the only reason why you're > > complaining is because you _need_ linux... to furnish all the things > > you can't do with plan 9 - either personally, or within your > > organization. > > people who care about Doing Things Right are easy to upset. > Bloat... can't live with it, can't live without it. ... I hope that something better comes along. http://www.youtube.com/watch?v=_yaP_kc3y9w On Thursday, April 28, 2011 08:11:49 PM andrey mirtchovski wrote: > errno, you sound like you may be trespassing on our collective 9fans > lawn. i wave a cane in your general direction. > Plan 9 rules and linux drools - I get it - but, wake me up when there's a Grand Unified Solution for implementing a perfectly clean, multi-purpose, general-use operating platform for an ad-hoc, rapidly (d)evolving, messy industry/market/society - that isn't itself intrinsically, hopelessly bloated in order to fulfill said purpose. Until then, complaining about de-facto linux bloat is a lot like complaining about death and taxes. Boring and disingenuous. IMHO, at least. (I'm just glad the collective plan 9 lawn expands far beyond the pointless linux-hate gazebo.)
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
> clean, multi-purpose, general-use operating platform for an ad-hoc, rapidly > (d)evolving, messy industry/market/society here: http://mirtchovski.com/p9/canthave.png
