Posted by Tres
Sat, 03 May 2008 13:49:00 GMT
Installing Postgres on FreeBSD, as always with packages and ports, is a breeze. pkg_add -r postgresql82-server or better yet, portinstall -P databases/postgresql82-server and a quick edit to /etc/rc.conf later, it’s Miller Time… Well almost…
Getting Postgres running in a FreeBSD jail requires that the jail host allows access to FreeBSD’s System V interprocess communication send and receive system calls.
Warning:This breaks down the separation of jailed processes from the host. If you’re paranoid about the security of your host environment, you’ll probably not want to do this – since the same namespace is used for IPC primitives of both the host and in the jail environment as well. This means that someone can potentially send and receive to processes being run in the host environment, or in other jailed environments. There is potential for denial of service, but so long as there are users on a box, there’s always a potential for denial of service, right?
So, to get things running just add the following to /etc/sysctl.conf in the host environment:
security.jail.sysvipc_allowed=1
That will make sure that things start up right whenever the box gets rebooted. To get things running right now, type the command in your terminal window.
sudo security.jail.sysvipc_allowed=1
Posted in FreeBSD, Sysadmin | Tags FreeBSD, Jail, postgresql, virtualization
Posted by Tres
Thu, 05 Apr 2007 06:03:00 GMT
Introduction to CARP
CARP makes it possible to have redundant, fault-tolerant routers using off-the-shelf general computing systems. Using CARP can increase the reliability, extensibility and robustness of your core routers while decreasing the cost of ownership and lowering the barrier to entry. Older systems can easily be re-commissioned for use as routers, bringing the hardware costs to zero. I’ve seen a pair of 550 megahertz pentium III sytems provide layer 3 filtering and routing for a rack of streaming media servers in a datacenter; and the best part: the boxes weren’t even close to being fully utilized. I’ve also set up OpenBSD based CARP systems handle traffic for a site of nearly a thousand computers. These systems handle hundreds of simultaneous users working on 3D Studio Max and Maya files off of network file servers, VOIP traffic for multiple sites as well as day-to-day intranet and Internet services.
How does CARP work? Well, in short, a CARP interface is essentially a virtual interface that can be shared between multiple machines. The CARP interface is active on only one parent interface at any given time, but the virtual interface can be shifted to another parent interface very quickly in the event of a failure.
Now you’re probably saying, “that sure sounds a lot like Cisco’s VRRP!” Well, that’s because it is just like VRRP (Virtual Router Redundancy Protocol). CARP came in to being as an open source implementation of VRRP using VRRP as the spec. But get this–CARP not only performs the same kind of functionality as Cisco’s VRRP , it can also be configured to act like Cisco’s GLBP (Gateway Load Balancing Protocol) (although, technically, the CARP guys had their own implementation of GLBP working before Cisco did). Load-balanced routing with included failover capabilities is very exciting–I know–but GLBP and load-balancing CARP is a subject we’ll leave for another day. For now, let’s take a look at setting up a CARP interface on FreeBSD using rc.conf.
Setting Up CARP interfaces on FreeBSD
There are three basic elements to setting up CARP failover interfaces to boot on FreeBSD:
First, in /etc/rc.conf, tell FreeBSD that you’re creating a “cloned interface.” Unless the interface is included in the list of virtual interfaces, it will never be created by FreeBSD.
cloned_interfaces="carpXX"
The cloned_interfaces directive can contain as many virtual interfaces as you need separated by a space:
cloned_interfaces="carpXX carpYY carpZZ"
Then add the configuration directives for your cloned interfaces to /etc/rc.conf.
ifconfig_carpXX="vhid <carp-interface-id> advskew <priority> pass <password> <carp-ip-address>"
and then in /etc/sysctl.conf, tell the kernel that you want to allow CARP interfaces to preempt each other:
net.inet.carp.preempt=1
This directive also means that once any single interface fails on a router, all virtual CARP interfaces will be shifted to the failover router at once.
The Four Elements of The Interface Definition
The ifconfig_carpXX line is made up of four elements.
vhid <carp_interface_id> the virtual interface ID
advskew <priority> the priority of the interface
pass <password> the password used by hosts to validate the CARP relationship
<carp_ip_address> the IP address of the virtual interface.
ifconfig_carpXX="1==>vhid <carp_interface_id> 2==>advskew <priority> 3==>pass <password> 4==><carp_ip_address>"
That’s all there is to it. You won’t need to worry about where or how the virtual interface attaches, FreeBSD is smart enough to know which parent interface it’s supposed to use by the IP address assigned to the CARP interface. The only real bookkeeping you’ve got to do is to make sure that:
- the VHID on your primary and failover routers match, and
- that the priority of the primary is lower than the failover.
Example
In the following example uses two FreeBSD routers called primo (our primary router) and secundo (our failover router) in a failover configuration:
primo, our primary router
/etc/rc.conf
ifconfig_em0="inet 99.88.77.70/29" # external interface for primo, our primary router
ifconfig_em1="inet 10.11.12.254/24" # internal interface for primo
defaultrouter="99.88.77.65"
gateway_enable="YES"
cloned_interfaces="carp1 carp2"
ifconfig_carp1="vhid 1 advskew 50 pass BigPassword 99.88.77.66" # external CARP interface for primo
ifconfig_carp2="vhid 2 advskew 50 pass BigPass2W 10.11.12.1" #internal CARP interface for primo
secundo, our failover router
/etc/rc.conf
ifconfig_em0="inet 99.88.77.69/29" #external interface for secundo, our failover router
ifconfig_em1="inet 10.11.12.253/24" # internal interface for secundo
defaultrouter="99.88.77.65"
gateway_enable="YES"
cloned_interfaces="carp1 carp2"
ifconfig_carp1="vhid 1 advskew 80 pass BigPassword 99.88.77.66" #our external CARP interface for secundo
ifconfig_carp2="vhid 2 advskew 80 pass BigPass2W 10.11.12.1" # internal CARP interface for secundo
Now I’m sure you’ve already noticed, but I want to reiterate it; the only difference in CARP interface definitions between the two hosts is the advskew assigned to each. This is how the priority of the router is assigned.
Final Notes
A practical consideration when you’re deciding whether CARP is the right choice is that any system is limited to 255 CARP interfaces. This normally is a non issue, but if you expect your network to grow beyond 128 VLANs and want to use load balanced routers, it will become an issue, so keep it in mind. (Of course, there’s a point of diminishing returns when trying to put too many segments on a single router or set of failover routers is more management overhead than just setting up another set.
Also, keep in mind that this covers only configuration of the CARP interfaces themselves. If you plan on doing any packet filtering with PF, you’ll want to set up a pfsync interface. But that’s another story.
Posted in FreeBSD, PF / CARP , Sysadmin | Tags CARP, configure, failover, FreeBSD, interface, redundant, router, rc.conf
Posted by Tres
Sun, 04 Mar 2007 08:00:00 GMT
If you’re using ports OpenSSL, you might be getting the following error when attempting to use portupgrade:
Malformed conditional (${OPENSSL_SHLIBVER_BASE} > ${OPENSSL_SHLIBVER})
If so, link /usr/lib/libcrypto.so to /usr/lib/libcrypto.so.3
Update:
Although the above may work, it’s a workaround, not a solution.
When this happens it means that there’s an issue with the openssl installation from ports. What happens is that even though the openssl libraries are in /usr/local/lib, some ports don’t honor the library configuration; they’re still looking for the system installation of OpenSSL in /usr/lib.
In order to make sure this doesn’t happen, you’ve got to add the following to your /etc/make.conf
OPENSSL_OVERWRITE_BASE=yes
WITH_OPENSSL_PORT=true
Once that’s done, you’ll need to decide how you want to deal with the applications that are built against the applications that have already been built with the other installed version of the port.
Posted in FreeBSD, Sysadmin | Tags FreeBSD, openssl, ports
Posted by Tres
Fri, 21 Jul 2006 07:05:00 GMT
If you’re using nssldap and pamldap in FreeBSD, chances are, you’ve run into the dreaded LDAP stall. If you’ve never run into it, it usually goes something like this: everything comes to a stop while the host attempts to reach the LDAP server. Nothing seems to work–you can’t log in remotely, you can’t even log in locally. And even when you get logged in, things like top just sit and wait for five minutes before it actually runs.
The man pages don’t really help, and even Google proved to be frustratingly unhelpful regarding this one. For FreeBSD issues surrounding LDAP timeouts, Google seems invariably to point toward the useless TIMELIMIT directive. This is good for limiting how long your host will wait for a response from the LDAP server once it’s made a connection, but is absolutely useless for defining how long the host will wait before timing out.
To get FreeBSD to play nicely when the LDAP servers aren’t reachable, just add the following to your ldap.conf:
bind_policy soft
This seemingly undocumented directive is the ldap client’s reconnect policy. If it is set to hard it will attempt to reconnect with exponential backoff. If it is set to soft, the reconnect policy is to fail immediately.
Posted in FreeBSD, Sysadmin | Tags FreeBSD, LDAP, timeout | no comments
Posted by Tres
Thu, 20 Jul 2006 03:08:00 GMT
After installing emulators/linux_base-fc4 and the rpm port, you’re almost ready to install Fedora Core 4 ready RPMs into your FreeBSD system.
If you try to install an RPM and see a message like this:
failed to open /var/lib/rpm/packages.rpm: No such file or directory
The final step is initializing the RPM database. Use rpm –initdb to get the required RPM database files in place.
sudo rpm --initdb
Once you have that completed, you should have the following files in the /var/lib/rpm directory:
$ file /var/lib/rpm/*
/var/lib/rpm/conflictsindex.rpm: Berkeley DB 1.85 (Hash, version 2, native byte-order)
/var/lib/rpm/fileindex.rpm: Berkeley DB 1.85 (Hash, version 2, native byte-order)
/var/lib/rpm/groupindex.rpm: Berkeley DB 1.85 (Hash, version 2, native byte-order)
/var/lib/rpm/nameindex.rpm: Berkeley DB 1.85 (Hash, version 2, native byte-order)
/var/lib/rpm/packages.rpm: data
/var/lib/rpm/providesindex.rpm: Berkeley DB 1.85 (Hash, version 2, native byte-order)
/var/lib/rpm/requiredby.rpm: Berkeley DB 1.85 (Hash, version 2, native byte-order)
/var/lib/rpm/triggerindex.rpm: Berkeley DB 1.85 (Hash, version 2, native byte-order)
Posted in FreeBSD, Sysadmin | Tags Emulation, FreeBSD, Linux, RPM | no comments
Posted by Tres
Wed, 12 Jul 2006 11:27:00 GMT
Someone asked me to see about adding multiple IP addresses to a jail the other day. Now that management tools have finally been added, lack of functionality like multiple IP addresses and of fair time scheduling is really the biggest problem that jail has right now. It’s not really a competitive solution without them. Well, after looking around on the Interweb it seemed that the only “recent” (read 2003) patch was Pawel Jakub Dawidek’s patch for FreeBSD 5.3BETA.
So I updated the patch to work with 6.1-STABLE, and upgraded the startup script to handle multiple IP addresses.
This file will patch FreeBSD 6.1 stable to allow multiple IP addresses within a jail.
If you don’t want to cvsup and compile it yourself, you can download a pre-compiled kernel and jail files here.
Otherwise:
cvsup -g -L2 /usr/local/etc/stable-supfile
cd /usr/src
sudo patch -p1 < ~/downloads/multi_ip_patch
sudo make buldworld
sudo make buldkernel
sudo make installkernel
Warning: You really should follow the canonical method for updating your kernel outlined in the FreeBSD handbook. If you’re upgrading from a 6.1-RELEASE to 6.1-STABLE, and you’re willing to take responsibility for whatever damage your actions cause, you might do the following.
sudo make installworld
sudo mergemaster
When defining jails in /etc/rc.conf, separate all the IP addresses for the jail with commas, like this:
jail_testomatic_ip="10.20.30.8,10.20.30.9,10.20.30.10"
You can use the standard /etc/rc.d/jail interface for starting and stopping jails.
Posted in FreeBSD, Sysadmin | Tags 1, 6, Addresses, FreeBSD, IP, Jail, Kernel, Multiple, Patch | no comments
Posted by Tres
Tue, 04 Jul 2006 14:30:00 GMT
In order to set up VLAN interfaces on FreeBSD, first you’ll need to either use a kernel module by adding:
if_vlan_load="YES"
to loader.conf
or by adding
device vlan
to your kernel configuration file before you recompile your kernel so that the kernel knows how to speak 802.1q.
Once your kernel is 802.1q aware, the next step is to set up rc.conf for vlan interfaces.
set up rc.conf so that any vlan interfaces are listed under the “cloned_interfaces” directive
cloned_interfaces="vlan100 vlan200 vlan300 vlan482"
make sure that the parent device is up and running. If you don’t have an IP address that you’re associating with the device natively, then you should just make sure that it’s up.
ifconfig_fxp0="up"
and finally, set up the interface details in rc.conf
ifconfig_vlan100="inet 102.203.98.97/28 vlan 100 vlandev fxp0"
ifconfig_vlan200="inet 102.203.98.24/28 vlan 200 vlandev fxp0"
ifconfig_vlan300="inet 102.203.98.10/29 vlan 300 vlandev fxp0"
ifconfig_vlan482="inet 102.203.98.223/28 vlan 482 vlandev fxp0"
Once you’ve got all these items configured, your VLAN interfaces should start up on boot. The only other thing you’ll need to do before you can use your VLAN interfaces on the FreeBSD box is to configure the switch for vlan trunking and 802.1q encapsulation. But that’s another story.
Posted in FreeBSD, PF / CARP , Sysadmin | Tags FreeBSD, interface, VLAN | no comments