Running with a readonly root partition
As devfs is running by default, it seems to me that it would be relatively easy to run with a readonly root partition, assuming that the directories under which writing is necessary (ie; /tmp, /var, /home) are located in separate, writable partitions. The main advantages are that none of the configuration files or binaries in /etc and /usr (which may still be on a separate readonly partition) are vulnerable to attack (even from a local privilege escalation) without remounting the partition as writable. This used to be a very common setup in the *NIX world, so I am surprised to find little to no mention of it in the archives. I set up my machine this way a couple of months back, and have noticed some minor things (some few things assume a writable /etc, notably including dump(8), and the boot process update to /etc/motd). Once these have been rectified by relocating the files and setting up symlinks, there have been no problems. My questions are: - does anyone else do this? - if not, why not? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dmesg empty after shutdown -r
On Thursday 01 May 2008 01:58:46 A Hamilton-Wright wrote: After "shutdown -r now" and the subsequent reboot, I have (... no dmesg) On Thu, 1 May 2008, Mel wrote: dmesg -M doesn't show anything either? Wish I'd thought to try that last night. I eventually shut it down again (shutdown -p) until I could come in this morning and take a look at the console while booting -- and now everything is fine. I have now tried a few reboots (shutdown -r) and halts (shutdown -h), and I have a dmesg every time it recovers. I will certainly keep an eye on this and see if I can reproduce this in any fashion. If anyone else sees this phenomena (even transiently), I would love to know about it. Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dmesg empty after shutdown -r
This is very strange. After "shutdown -r now" and the subsequent reboot, I have logged in to my machine FreeBSD qemg.org 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 Everything seems to be running normally, except "dmesg" produces no output, and /var/run/dmesg.boot is zero bytes long. Does anyone have any ideas why this would ever occur? Or even how it could occur? Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB HD based backup schemes
On Sat, 26 Apr 2008, Jeffrey Goldberg wrote: On Apr 26, 2008, at 3:38 PM, David N wrote: We used to use RSnapshot http://www.rsnapshot.org/ to backup to an external disk, its a great tool that also does incremental via hard links which is a plus. Just after I posted, I started thinking about rsync. I hadn't known about rsync's hard link feature. So once I saw that, the trail did lead me to rsnapshot. The only thing I don't like about it is the security hole it demands of remote machines to be able to back up to them. Take a look at rsync's -e feature. You can use it to pipe its output through an ssh tunnel much as I just posted a moment ago: rsync -e "ssh -x" ... kreacher:path/to/usb/storage Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB HD based backup schemes
You haven't mentioned how large a USB drive you have available to use for this scheme, but it sounds to me like your situation can be summed up as follows: - you have two machines to back up, one is remote, but both have consistent network accessibility - you have a (removable) drive upon which you want to place regular backups, based on some use of dump/restore, and presumably this drive is large enough for all backup data, to be managed under some rotation scheme (old -vs- current directories, for example) - the main question is how to collect and organize the data onto this (removable) drive on a machine remote from the one being backed up If the above pretty much fits the bill, I would suggest a simple script to be run out of cron to copy the data. Keep in mind that you can easily transfer the data directly from dump to your remote machine by piping it into an ssh command. On your dobby machine, a command of the form: dump 1nuLf - /my/data | ssh -x kreacher /path/to/some/handler/script will present the dump output to a script run on the backup machine that can presumably ensure sane handling of the incoming data and potentially mount your USB device. Passing the mount point on dobby as an argument to your remote script will help you organize things if you have set up multiple filesystems on dobby that you need to dump separately. Note that I am assuming here that you have made a zero level dump and that it will be perpetually available in some safe place. I'm sure that I could roll my own with dump or such, but I'm sure that I would leave important things out and that this has already been done by people who are smarter and more experienced than I am. So recommendations please. As long as you are dumping whole filesystems, I don't really see how you can "leave anything out" -- recovery is then simply a case of: - boot off an install/live CD - fdisk, label, newfs - restore dump level 0, restore most recent dump level 1 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CPU throttling on amd64
Does anyone on this list know the state of any userland control tools for CPU throttling on the amd64 platform? I see in the archives that there was little functionality in this are as of 2004, and then substantial work in 2005 to make cpufreq available through sysctl. At that time there is a thread indicating how nice it would be if someone wrote a daemon to do the control for this a la cpufreqd http://lists.freebsd.org/mailman/htdig/freebsd-amd64/2005-February/003524.html I cannot seem to find anything relating to throttling and or AMD Cool&Quiet after that point. Is there such a daemon? Thanks for any pointers, Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
