RANCID stores the configuration of network devices
I am quite careful about how I use ssh agent forwarding, deciding how much I trust the remote host, only using it as needed, and putting my more sensitive keys in separate agents. There is still a risk as the superuser on the remote machine can connect through your auth socket and perform key operations.
I was thinking to myself how great it would be if I could confirm/deny each authentication attempt and as it turns out ssh-agent already supports this. From ssh-add(1)
-c Indicates that added identities should be subject to confirmation before being used for authentication. Confirmation is performed by the SSH_ASKPASS program mentioned below. Successful confirma- tion is signaled by a zero exit status from the SSH_ASKPASS pro- gram, rather than text entered into the requester.
This requires a wrapper to use Xdialog although any program which is able to prompt and return an error code can be used. In ~/bin/ssh-yesno,
Xdialog --wrap --title "ssh-agent" --yesno "$@" 0 0
I also added the environment variable above ssh-agent in ~/.xinitrc
eval `ssh-agent -s`
Lastly the keys need to be added with the -c option in order to prompt
ssh-add -c ~/.ssh/id_dsa
Now when I (or someone else) try to authenticate using the agent keys it pops up.
I have written up how I set up a server with ZFS for remote replication here. When trying to sync hundreds of gigabytes of small files, solutions such as rsync do not cut it. ZFS scales well, its fast, and replication is pretty much free.
Over the last two months I have been working on the FreeBSD wireless code. Having a single net80211 stack is a huge benefit and the wireless drivers tend to be around 1/4 of some other operating systems. The driver is an interface to the hardware and leaves beacon processing, state changes, encryption, scanning/roaming and so on to net80211.
Sam committed a large set of net80211 changes that brought in revamped scanning, background scanning/roaming and changes needed for 11n. As part of this I worked on the iwi, wi and ndis drivers and there is also a pending update to ipw. Hopefully people are testing their setups, the 7.0 BETA is coming up soon which will give the code even more exposure.
I finally got around to adding vlan support to the FreeBSD bridge driver. The vlan tag is now used in the bridge forwarding table so that the same device on two different vlans is treated as separate. The vlan changes in if_ethersubr.c made this easy now that the tag is always available in the mbuf header.
In the weekend I added support for the Marker protocol in lagg(4).
The basic function of it is to verify that the interface queues are empty for all the aggregated interfaces. Frame distribution is supressed and a marker frame places on the queue for each interface, the frame will be sent to the partner device and then returned immediately on the same link. Once each frame is received then we can be sure that no other ethernet frames are queued for that port and when all ports are complete then frame distribution is re-enabled.
All this is needed because frames must be delivered in order for Ethernet, the lagg device can send frames over different ports to utilize all the combined bandwidth by hashing the header (ethernet src/dst, vlan tag, ip header, ipv6 header). The hash selects the transmit port and this ensures for each connection the frames take exactly the same path. If a port is added or removed then the hash output is affected since its modulo the number of ports, the marker protocol ensures that frames for a particular connection are not put on a different interface queue and arrive out of order.
My next job is to add bgscan for iwi(4) and hopefully the card will arrive tomorrow.