How far to go with jailing?
Strikes me that setting up jails for bloody-well-every-other service might be 'fun' .. Jail the webserver; seems a logical break, and keep you honest for your partitioning. No more ~/public_html to access it I suppose, but much mroe secure for when people attack your wordpress etc. Jail the 'email services'; use fetchmail to pull down to the jail, and IMAP and POP3 to serve the mail even to local clients; nice clean email mini-server right there in the jail? Jail SMB-serving, so if attacked it still can only serve the content in the very well defined area. Jail the mailing list (mailman etc) .. keep things nice and clean. But is setting up a whole stack of jails a pain? a performance problem? or just un-necessary overkill? Or a good idea? jeff -- If everyone would put barbecue sauce on their food, there would be no war. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Help! Upgrade from fbsd 5.4 to 8.x
On Mon, 1 Feb 2010, Ruben de Groot wrote: # > The GENERIC kernel in 8.0 comes with the COMPAT_FREEBSD5 option by default, so # > the only thing you need to do is to install the misc/compat5x port. # # That is, if the executables weren't dependent on compat[2-4] options in the kernel on the old server ;) Hahahahaha haha h ... erm :/ We'll see :) # Yes, you could even try coying the entire old disk to a subdirectory and # running that as a jail. Should bring you up quickly, giving you more time # to migrate all applications proper. I considered this (or just VMing the whole box), but I'd still be going through to trim out the union of ports (ie: ssh common port etc), so heck with it. I do think I'm going to jail like mad this time through though; ie: stick apache into a jail, stick groupware server into a jail, stick mailing list into a jail, etc; for things that are well defined and should be something considered for peeling to another server some day, just jail them outright from the onset .. better security and help keep me from bleeding lines between services. Good tip :) Not that I've set up a jail before, but nows as good a time as any to learn :) jeff -- If everyone would put barbecue sauce on their food, there would be no war. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Help! Upgrade from fbsd 5.4 to 8.x
On Sun, 31 Jan 2010, Volodymyr Kostyrko wrote: # Not totally true. 5.4 was released in 2005 whereas newest motherboard with # which I faced personally problems booting from USB was from 2003. And it # actually declares that it can boot from USB. 5.4 seemed to actually have many issues with USB; some devices work, others cause kernel panics as soon as they hit the socket, so I generally avoid them on the machine (which causes no end of trouble for backups :) # However it's quite possible the hardware would not boot from USB stick. This An interesting idea to boot from USB here; I've often flirted with the idea of using the local-disk for storage, and the OS from flash media, and thus being able to swap easily without a hypervisor/etc. Anyway, as this box is a shell, mailserver, low end webserver etc, fairly dedicated in function, I think my best route will be to buy another disk (I mean, theyu're cheap right?) and do the jump straight to a fresh-8 install, harden it up, and do the piecemeal migration. Worst case is I go back to the existing drive for a few days until I get it all working. Thanks for the many tips my friends, jeff -- If everyone would put barbecue sauce on their food, there would be no war. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Help! Upgrade from fbsd 5.4 to 8.x
Hello my friends, I've just noticed one of my beloved headless shell boxen is FreeBSD 5.4; its a workhorse I've been neglecting far too long and I'd really like to bring it up to 'current' (say fbsd 8.x). For awhile it was held back by very specific applications I had to support, but I'm in the clear now. Given the age of the installation, I'm wondering what the recommended upgrade path would be. ie: This machine has a lot going on .. wiki's (ie: apache et al), mysql databases, mailing lists, and a dozen hand rolled applications. (Hey, someone has to write custom emulators of ancient systems to keep BBSes alive, right?) Naturally, /etc is modified all to hell, and I'm terrified of any automated upgrades for fear random things would just not work later. Especially with the age... Things work great, but I worry about security naturally, and keeping up with patches or installing anything new is a nightmare due to dependancies. o I should be able to identify most important changes and data; /etc, /home, the kernel build path so I've got the old kernel conf files I used for this machine (yay!), /usr/local was used instead of polluting /usr-proper, etc. o I'd love if I coudl do an upgrade, and things would still work; I mean, from samba configuration etc and so on, eveyrthign is great. I realize this is unlikely though .. upgrading services likely means conf changes all over the random place, etc. o Some of the executables on this box are without source but I still need them to run; short of moving them to a VM and doing some voodoo, what are the chances a binary built for fbsd 5.x works fine in 8.x? (earlier fbsd's had the break between gcc versions, but I'm rather hoping thats not a problem here.) gcc (GCC) 3.4.2 [FreeBSD] 20040728 The obvious options are.. 1 - upgrade step by step; go from fbsd 5.4 to 6.4 (say) to 7.2 (say) to 8.0 2 - one big-ass upgrade from 5.4 to 8 (*fear*) 3 - yank the drive, slap a giant new fat drive in there, do a full fbsd 8.0 install, and then migration from old drive as needed Strikes me most people will recommend (3) -- nice big new drive, no risk of destroying a working machine (can always slap old drive back in), easy migration of service by service, etc and so on. Strikes me as a PITA, but then again .. the others are probably all PITAs as well given the age of the box. Something will break, so maybe its best to just start fresh with a nice new install and go from there. *ugh* but that'll teach me to stay on top of it more :) Aside -- whats the recommended way to stay on top of upgrades anyway? It used to be a tortuous process back 5 years ago, but hopefully things are much more streamlined now .. nightly 'make upgrade' ftw :) jeff -- If everyone would put barbecue sauce on their food, there would be no war. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: telnet/sshd limited by user?
On Mon, 8 Aug 2005, Benjamin Lutz wrote: # > Is it possible to set things so that 'telnet' is allowed only to one # > specific user, while everyone else needs sshd? ie: Obviously, nologin # > can be used as a shell to not permit any logins (but makes 'su' break # > too), but I'd like to allow telnet for one specific user only and keep # > everyone else on sshd. # # Yes, by playing with PAM. You can change telnetd's PAM configuration # (/etc/pam.d/telnetd) to include a group check: # # auth requisite pam_group.sono_warn group=telnetusers # # Then create a group "telnetusers", and make your telnet user a member of it. # # Haven't tested it myself, hope it works. Ah, indeed; I didn't read much up on PAM and didn't realize it could go through a series of phases before allowing on, so you can do a group-check and then additional checks as well. Neat stuff. Thanks for the tip, jeff -- "Have you played Atari today?" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
telnet/sshd limited by user?
Is it possible to set things so that 'telnet' is allowed only to one specific user, while everyone else needs sshd? ie: Obviously, nologin can be used as a shell to not permit any logins (but makes 'su' break too), but I'd like to allow telnet for one specific user only and keep everyone else on sshd. I could of course modify telnetd, but I'd prefer to avoid such voodoo as I'd surely forget during an upgrade later :) Thanks for any tips, jeff -- "Have you played Atari today?" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DVD burning..
On Mon, 1 Aug 2005, Chuck Swiger wrote: # Is "sysctl hw.ata.atapi_dma" set to 1? It looks like your system isn't # able Aha, that seems to be it; I had slapped that into my rc.local with some other sysctl's (before I found out about /etc/sysctl.conf), and that one is read-only by that stage of loading. Had to be in /boot/loader.conf to 'take'. # to send enough data to the burner to run at 4x, perhaps try burning at 1x # speed and see whether that is more reliable. (Often that works better with # low-quality DVD-R media, anyway...) Seems to be chugging away nicely now: 738590720/2937458688 (25.1%) @3.9x, remaining 7:23 757071872/2937458688 (25.8%) @3.9x, remaining 7:17 775520256/2937458688 (26.4%) @3.9x, remaining 7:12 So I imagine I'm good to go :) This ought to me nightly automated backups a snap! Thanks Chuck, Greg and others who emailed me diretly. jeff -- "Have you played Atari today?" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
DVD burning..
So far I'm having no luck so thought I'd post and ask for help :) FreeBSD 5.4, BenQ DVD burner, using DVD-R media. GENERIC kernel with ATAPICAM added. Built an iso with mkisofs, and can burn it out with burncd to CDR no problem (if 700MB or less or so, of course.) For DVD, built a 2GB .iso using the same mkisofs command.. mkisofs -o foo.iso -J -R filelist* 'cdrecord' seems completely crippled and I'm amazed no one has written a 'Free' version (no dependancy on getting key files that expire, or reliance on one person to generate them, etc.) Took me awhile to figure out how to get the key files going... but it now has what seems like a common problem -- it starts up, does the 'grace time', then "Alarm clock" and it stops before doing any work. So after a few hours of buggering around I gave up.. Installed the dvd tools to get growisofs since this seemed like the main alternative to cdrecord. (burncd didn't seem to like to burn DVDs, though I forget exactly its output.) growisofs seems to almost work, but breaks and is slow: growisofs -dvd-compat -speed=4 -Z /dev/cd0=buckdvd.iso That results in.. Executing 'builtin_dd if=buckdvd.iso of=/dev/pass0 obs=32k seek=0' /dev/pass0: "Current Write Speed" is 4.1x1385KBps. 1867776/2937458688 ( 0.1%) @0.4x, remaining 104:46 7503872/2937458688 ( 0.3%) @1.2x, remaining 45:33 7503872/2937458688 ( 0.3%) @0.0x, remaining 71:35 7503872/2937458688 ( 0.3%) @0.0x, remaining 91:06 7503872/2937458688 ( 0.3%) @0.0x, remaining 110:37 7503872/2937458688 ( 0.3%) @0.0x, remaining 136:39 7503872/2937458688 ( 0.3%) @0.0x, remaining 156:11 7503872/2937458688 ( 0.3%) @0.0x, remaining 182:12 7503872/2937458688 ( 0.3%) @0.0x, remaining 201:44 13107200/2937458688 ( 0.4%) @1.2x, remaining 126:25 13107200/2937458688 ( 0.4%) @0.0x, remaining 141:18 13205504/2937458688 ( 0.4%) @0.0x, remaining 151:19 ...etc... 16547840/2937458688 ( 0.6%) @0.0x, remaining 435:23 16547840/2937458688 ( 0.6%) @0.0x, remaining 444:13 16547840/2937458688 ( 0.6%) @0.0x, remaining 455:59 :-[ [EMAIL PROTECTED] failed with SK=6h/ASC=29h/ACQ=00h]: Input/output error builtin_dd: 8080*2KB out @ average 0.1x1385KBps :-( write failed: Input/output error /dev/pass0: flushing cache :-[ FLUSH CACHE failed with SK=2h/ASC=04h/ACQ=01h]: Resource temporarily unavailable :-[ SYNCHRONOUS FLUSH CACHE failed with SK=2h/ASC=04h/ACQ=01h]: Resource temporarily unavailable So it would seem to take hours to burn a DVD, and tanks after a few moments anyway. Any ideas? jeff Aside .. seems like a lot of tools depend on cdrecord to work, and it seems cdrecord with its key situation is volitile and requires userland knowledge to sort out.. so a bad situation :( -- "Have you played Atari today?" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
