bk bkd(7.3ce) BitKeeper User's Manual bk bkd(7.3ce) NAME bk bkd - the BitKeeper daemon SYNOPSIS bk bkd [<options>] DESCRIPTION The BitKeeper daemon, bkd, is used to synchronize and query reposito- ries. It is typically run in one of the following ways: => automatically started when accessing a remote repository via rsh, ssh, HTTP, and/or the file system; => automatically started via ssh as a login shell; => manually started as a long running stand-alone daemon; => automatically started as a long running service at boot time. The method used usually depends on how the remote repository is named. The stand-alone daemon method has no security, other than the ability to run in read-only mode and/or the ability to limit chdir. If secu- rity is a requirement, use ssh to access the daemon. See below for information on configuring the daemon as a login shell. ANONYMOUS ACCESS The most common use of the stand-alone daemon is for anonymous access to a repository. To provide read-only, anonymous access, you can run: bk bkd -d -xpush This will allow anyone to read (but not write) all repositories at or below the directory in which the bkd was started. If you want to export a single repository, pick a port number, and do this: cd /home/bk/linux-2.6 bk bkd -d -p5555 -xcd -xpush This says to run in daemon mode, bind to port 5555, and disallow the "cd" and "push" commands. By disallowing the "cd" command, the daemon at port 5555 is tied to the repository in the current working directory (bkd needs to be run at the root of the repository). By disallowing the "push" command, the repository is protected from updates. Clients can get to this repository by using the BK URLs of bk://host.domain:5555 http://host.domain:5555 i.e., $ bk clone bk://host.domain:5555 my_tree These HTTP URLs allow access through most firewalls. BitKeeper sup- ports accessing repositories through HTTP proxies, including authenti- cated proxies. SECURED ACCESS VIA SSH Secure access is provided via ssh. There two ways to invoke ssh: a) [<user>@]<host>:<pathname> b) ssh://[<user>@]<host>[:<port>][/<pathname>] Using either form, ssh will be called to run bk bkd on the remote host. When the client command completes, the ssh connection is broken and the bkd daemon goes away. BKD LOGIN SHELL To add security when using ssh, run the bk bkd as the login shell. On Red Hat Linux, the following steps are necessary to add a BitKeeper daemon login shell: create a simple shell script, call it bkd_login, put it someplace like /usr/libexec/bitkeeper/bkd_login, add the full path to the script in /etc/shells, and add a user with that path as their shell. An example bkd_login shell script: #!/bin/sh exec bk bkd -C -xcd Note: using the bkd as a login shell when accessing the system using rsh is unsupported and is known not to work due to a long standing rsh bug. BK/WEB The bkd is a self-contained HTTP server which provides the BK/Web fea- ture of BitKeeper. To access the BK/Web interface, use a web browser to go to the URL: http://<host>:<port>/ where <port> is the port on which the bkd is listening (see the "-p" option, below). WINDOWS BASED BKD It is possible to install a one or more bkd's as Windows services, see OPTIONS -C This option provides a slightly more secure mode of operation in that the bkd will refuse to change directories up out of the directory in which it was started. -d Run as a daemon, typically in the background (but see the next option). -D Debug mode, do not fork and run in the background. -h For all outgoing bk push, bk pull, and bk clone oper- ations, wrap command responses in HTTP protocol. Use when bk bkd is called from a CGI script. -l<log> Log accesses in <log>; if <log> is not specified, then log to stderr. -P<pfile> Write the pid of daemon process into this file at startup. -p<addr>:[<port>] -p<port> Specify an alternative address and/or port. By default, the bkd allows connection requests from any host on port 0x3962 (aka 14690). If <addr> is speci- fied, the bkd will bind to that address, limiting the hosts which are allowed to connect. The most common usage is to bind to localhost (127.0.0.1) which means that any local process may connect but no remote pro- cesses may connect. Note: When specifying an address, the trailing colon is required even when <port> is omitted. This option implies "-d". -i<cmd> Include <cmd> from the by default excluded command list. -S Run in "symlinks are allowed" safe mode. This is similar to -C, with the addition of allowing paths that are symlinks under the bkd root and resolve to outside of the bkd root. This is useful to be able to run this sequence of commands: mkdir /repos ln -s /mnt/disk1/repos/myrepo /repos/myrepo cd /repos bk bkd -S cd $HOME bk clone bk://machine/myrepo Note: a user could check in a symlink to anywhere, then push their repo to the master, then follow that symlink. This option is useful for organizations where that is acceptable. -U Run in "unsafe" mode. Any non-interactive BitKeeper command may be run remotely. The bkd runs the com- mand at the request of a remote BitKeeper client. If the client does not have access to the machine on which the bkd is running then this option allows far more access than is usually prudent. On the other hand, if the client has remote login privileges to the machine (or if the client is on the same machine) then there is no security issue with allowing this feature. Accordingly, this option is turned on auto- matically for any bkd started by the client via the file://, rsh://, or ssh:// access methods. If your environment is secured then running a long lived bkd with this option provides more BitKeeper functional- ity to your users. -x<cmd> Exclude <cmd> from the allowed command list. The list of commands which may be excluded currently are: abort, cd, check, clone, get, httpget, pull, push, pwd, rclone, rootkey, status, synckeys, and version. EXAMPLES We use the following in /var/bitkeeper/repositories to provide anony- mous read only access to some BitKeeper repositories: #---------------------- cut here -------------------------- nobody /home/bk/bk-3.2.x -C -xpush -p3200 nobody /home/bk/bk-3.3.x -C -xpush -p3300 #---------------------- cut here -------------------------- The following init script is known to work on Red Hat Linux based sys- tems. The init script shown can be generated with a $ bk getmsg bitkeeper.init #---------------------- cut here -------------------------- #!/bin/sh # # chkconfig: 2345 24 84 # description: BitKeeper server # Source networking configuration. if [ -f /etc/sysconfig/network ] then . /etc/sysconfig/network # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 0 fi [ -x /usr/bin/bk ] || exit 0 VAR=/var/bitkeeper case "$1" in start_msg) echo "Start BitKeeper daemons" ;; stop_msg) echo "Stop BitKeeper daemons" ;; restart) $0 stop $0 start ;; start) cd $VAR || exit 1 test -f repositories || { echo Nothing advertised exit 0 } while read user dir opts do ( cd $dir || exit 1 F=`basename $dir` CMD="bk bkd -d $opts -l$VAR/log.$F -P$VAR/pid.$F" su -c "$CMD" $user 2>> $VAR/errors echo Started $CMD in $dir ) done < repositories ;; stop) cd $VAR || exit 1 echo Shutting down BitKeeper daemons for i in pid.* do kill `cat $i` rm $i done ;; status) cd $VAR || exit 1 for i in pid.* do echo This pid should be running: `cat $i` done ps -axf | grep bkd ;; *) echo "Usage: bitkeeper {start|stop}" exit 1 ;; esac exit 0 #---------------------- cut here -------------------------- BUGS/NOTES Needs ssh to provide access controlled, authenticated users. One could argue that this is code reuse rather than a bug. BitKeeper does not ship ssh since it is widely available. On Windows the bkd service does not work when started from a network drive. On Windows the bkd service does not work when started from a subst'ed drive. SEE ALSO bk parent bk service bk url bk Howto-bkd CATEGORY Repository Admin BitKeeper Inc 1E1 bk bkd(7.3ce)