1. "userquota" should be set in the options of /etc/fstab for the filesystem where you want you want quotas enabled.



/dev/sd0a       /usr/local      ffs     rw,userquota                1 1



2. Make sure your quota-enabled filesystem is mounted


3. Run /etc/rc.d/quota start to generate an automatic "quotacheck -a" command


4. "edquota -f FILESYSTEM USER" will open up vi and have you fill out the quota file



Quotas for user qtest:
/usr/local: blocks in use: 0, limits (soft = 20, hard = 10)
        inodes in use: 0, limits (soft = 100, hard = 150)



5. "quotaon -a" to turn quotas on for every filesystem with the userquota option


6. Finally, try running repquota -a to see a report of all the quotas and test it out! Here's my attempting to exceed my quota of 100K



Error: bar: Disc quota exceeded; bar: WARNING: FILE TRUNCATED.

Caveats

I found a few issues with quotas-

• The userquota options and the log options are mutually exclusive, so WAPBL and quotas don't work together. (I think there is a plan to fix this)


• After really using quotas, I was unable to umount my fs but fstat didn't show anything using it

quota(1) - check your own quota
repquota(8) - check everyone's quota
quotaon(8) - enable quotas
edquota(8) - edit the quota file
quotacheck(8) - see if a user is exceeding his quota

Labels: NetBSD

Okay, so this is basically a post about procrastination as I avoid working on my first pseudo device. One thing that struck me was how accessible this part of the internal working of NetBSD were. I mean, seriously, if I can get a working device then anyone can.

NetBSD Documentation: Writing a pseudo device tells you everything you need to get started (well, mostly :) ) And studying other drivers shows that they mostly all look the same, use the same few conventions, and can offer a lot of hints on getting something functional fast.

A device-writing section in NetBSD Internals would be a very welcome addition and would give some nice background to the networking pseudo device chapter.

I guess it's time to get some reading in about config_attach_pseudo and friends but if you have an idea for adding a little this-or-that to NetBSD, I'll bet you can get a functional pseudo device in one day or less.

p.s.
Should I be doing this whole thing with rump?

Labels: c programming, NetBSD

CVS' activity digest - Issue 000

Check it out.

Labels: NetBSD

Update! This whole article has proven mostly worthless thanks the following two entries in fstab:
/dev/wd0b /var/log2 mfs rw,-s10m 0 0
/var/log2 /var/log union rw - -

That creates a 10M /var/log2 and then union mounts it onto /var/log, which will auto-magically seed the filesystem as it is used.

Thanks, tech-embed


Install into /sbin/mount_seed_tmpfs

So I like to run my soekris read-mostly and one of the biggest weaknesses of the methods I describe in there is seeding your memory file systems with the correct files so daemons requiring those files will function properly. Basically, if /var/log/messages doesn't exist, syslog isn't going to create it for you!

So, I've written the following script which will populate a tmpfs with all the data currently on the disk before mounting it. I basically works by first mounting the tmpfs to a hidden location, copying everything from the seeddir, and then doing a null mount on-top of the destdir.

So the command:
mount -t seed_tmpfs -o -s10M /var/log /var/log
will create a (hidden to df) mount of a 10M tmpfs, copy everything from /var/log to it, and then null mount that on-top of it.

Using it in /etc/fstab is a two step process (mostly for safety)
/var/log /var/log2 seed_tmpfs noauto,rw,-s10M - -
And then in /etc/rc.conf:
critital_local_filesystems="/ /var/log2"

This is a workaround for a little bug where mount -a will always try to remount the filesystem, and putting the parent and target into critical_local_filesystems will explicitly mount them.

The other bug is that umount can't trigger to umount both systems that I know of so a manual umount requires two commands.

Labels: NetBSD

So after re-installing NetBSD on my soekris I got to thinking about jumpstart for netbsd and about the whole pxe boot in general. After doing a little reading of the pretty excellent pxeboot man page (I mean, NetBSD really does have some great documentation) I wanted to give some of the more flexible options a try.

I didn't have to look much further than the bottom of the pxeboot man page, but I thought I would give a summary post about the booting process, and about how you can completely avoid using NFS for netboot if you want to. (let's hope the automated installer has a no-nfs option!)

The gist of what happens is is that NetBSD overloads the "filename" option in dhcpd.conf, depending on the request.

1) The first request, from the pxe bios is:
option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000" - pxeboot file


fun starts here - by default netbsd will look in next-server/root-path (dhcpd.conf config) for 'netbsd' and boot it, but you have more options at your disposal:

2) pxeboot then does a new request as:
option vendor-class-identifier, 0, 17) = "NetBSD:i386:libsa" looking for "boot.cfg"

3) pxeboot will then do request for 'netbsd' or whatever you tell it to do in boot.cfg!

The neat thing about #2 and #3 is that you can say "tftp:boot.cfg" OR "nfs:boot.cfg" and decide how you want to serve that file.

So if you want to say boot the netbsd kernel over tftp and turn off a troublesome piece of hardware, you can make your boot.cfg look like this:
menu=tftp boot userconf mode:boot netbsd -c

Or point to different kernels:
menu=tftp boot installer:boot netbsd-INSTALL

And then you just override the values in dhcpd.conf:
} else if filename = "netbsd" {
filename "tftp:netbsd-SOMETHINGELSE";

---

So I'm definitely interested to see how the above-mentioned summer of code project decides to use these options, if he decides to use MULTIBOOT to pass an arbitrary list of options into the boot sequence (my-ctrl-file=tftp:macaddress.xml) or who knows what.

Abandon CDROM booting! :)

(my dhcpd.conf is mostly from the pxeboot man page and I'm testing by connecting my eee to my powerbook with a normal patch cable because modern interfaces will automagically act like crossovers)

host eeepc {
hardware ethernet 00:1E:4D:5E:90:75 ;
# filename "/private/tftpboot/pxeboot_ia32.bin";
next-server 192.168.2.201;
option routers 192.168.2.201;
option domain-name-servers 4.2.2.1;
option root-path "/usr/local/soekris/";
fixed-address 192.168.2.203;
# This section allows dhcpd to respond with different answers
# for the different tftp requests for the bootloader and kernel.
if substring (option vendor-class-identifier, 0, 20)
= "PXEClient:Arch:00000" {
filename "pxeboot_ia32_vga.bin";
} elsif substring (option vendor-class-identifier, 0, 17)
= "NetBSD:i386:libsa" {
if filename = "boot.cfg" {
filename "tftp:boot.cfg";
} else if filename = "netbsd" {
filename "tftp:netbsd";
}
}
}


Labels: NetBSD

I just upgraded my soekris from NetBSD 3.1 to NetBSD 5.0. I actually did a fresh install following my own docs at soekris.html and am still working on getting all of my packages installed now. So far the systems seems fine, although I'm having a little more trouble fitting it onto 512MB. :)

Speaking of packages, I'm still waiting on the install of apache to finish (pkg_add seems stuck in select() or something) and I wanted to get this site back up, so I just fired up /usr/libexec/httpd (bozohttpd), which is now included in NetBSD, so I didn't have to wait for pkg_add at all.

NetBSD fester 5.0 NetBSD 5.0 (GENERIC) #0: Sun Apr 26 18:50:08 UTC 2009

Labels: NetBSD