diff options
Diffstat (limited to 'doc')
-rw-r--r-- | doc/appendix/guides/import-existing-ssh-keys.txt | 6 | ||||
-rw-r--r-- | doc/client/tools/augeas.txt | 33 | ||||
-rw-r--r-- | doc/conf.py | 2 | ||||
-rw-r--r-- | doc/contents.txt | 1 | ||||
-rw-r--r-- | doc/development/testing.txt | 4 | ||||
-rw-r--r-- | doc/installation/building-packages.txt | 228 | ||||
-rw-r--r-- | doc/installation/distributions.txt | 7 | ||||
-rw-r--r-- | doc/installation/index.txt | 2 | ||||
-rw-r--r-- | doc/installation/packages.txt | 81 | ||||
-rw-r--r-- | doc/installation/prerequisites.txt | 6 | ||||
-rw-r--r-- | doc/installation/source.txt | 11 | ||||
-rw-r--r-- | doc/releases/1.3.4.txt | 49 | ||||
-rw-r--r-- | doc/releases/index.txt | 10 | ||||
-rw-r--r-- | doc/server/configuration.txt | 43 | ||||
-rw-r--r-- | doc/server/plugins/generators/rules.txt | 4 | ||||
-rw-r--r-- | doc/server/plugins/generators/sshbase.txt | 8 | ||||
-rw-r--r-- | doc/unsorted/emacs_snippet.txt | 2 | ||||
-rw-r--r-- | doc/unsorted/vim_snippet.txt | 6 |
18 files changed, 397 insertions, 106 deletions
diff --git a/doc/appendix/guides/import-existing-ssh-keys.txt b/doc/appendix/guides/import-existing-ssh-keys.txt index 0b396d327..4e2282044 100644 --- a/doc/appendix/guides/import-existing-ssh-keys.txt +++ b/doc/appendix/guides/import-existing-ssh-keys.txt @@ -1,4 +1,5 @@ .. -*- mode: rst -*- +.. vim: ft=rst .. _appendix-guides-import-existing-ssh-keys: @@ -36,6 +37,9 @@ files explicity: .. code-block:: xml <Bundle> + <!-- requires a version of openssh that can generate ecdsa keys --> + <Path name="/etc/ssh/ssh_host_ecdsa_key"/> + <Path name="/etc/ssh/ssh_host_ecdsa_key.pub"/> <Path name='/etc/ssh/ssh_host_dsa_key'/> <Path name='/etc/ssh/ssh_host_rsa_key'/> <Path name='/etc/ssh/ssh_host_dsa_key.pub'/> @@ -93,7 +97,7 @@ Now, we pull the ssh host key data for the client out of the uploaded stats and insert it as host-specific copies of these files in ``/var/lib/bcfg2/SSHBase``.:: - for key in ssh_host_rsa_key ssh_host_dsa_key ssh_host_key; do + for key in ssh_host_ecdsa_key ssh_host_rsa_key ssh_host_dsa_key ssh_host_key; do sudo bcfg2-admin pull <clientname> Path /etc/ssh/$key sudo bcfg2-admin pull <clientname> Path /etc/ssh/$key.pub done diff --git a/doc/client/tools/augeas.txt b/doc/client/tools/augeas.txt index 94ed9066f..6fed5f5ce 100644 --- a/doc/client/tools/augeas.txt +++ b/doc/client/tools/augeas.txt @@ -26,11 +26,20 @@ give it a sequence of commands: The commands are run in document order. There's no need to do an explicit ``save`` at the end. -Each of these commands will only be run if the path does not already -have the given setting. That is, the ip address for the first host -record will only be set to ``192.168.0.1`` if it's not set to that -value already. Its canonical name will only be set to -``pigiron.example.com`` if it's not that already; and so on. +These commands will be run if any of the paths do not already +have the given setting. In other words, if any command has not +already been run, they will all be run. + +So, if the first host already has all of the specified settings, then +that Path will verify successfully and nothing will be changed. But +suppose the first host looks like this:: + + 192.168.0.1 pigiron.example.com pigiron + +All that is missing is the second alias, ``piggy``. The entire Augeas +script will be run in this case. It's important, then, to ensure that +all commands you use are idempotent. (For instance, the ``Move`` and +``Insert`` commands are unlikely to be useful.) The Augeas paths are all relative to ``/files/etc/hosts``. @@ -39,6 +48,20 @@ tags are: ``Remove``, ``Move``, ``Set``, ``Clear``, ``SetMulti``, and ``Insert``. Refer to the official Augeas docs or the `Schema`_ below for details on the commands. +The Augeas tool also supports one additional directive, ``Initial``, +for setting initial file content when a file does not exist. For +instance, the ``Xml`` lens fails to parse a file that does not exist, +and, as a result, you cannot add content to it. You can use +``Initial`` to circumvent this issue: + +.. code-block:: xml + + <Path type="augeas" name="/etc/test.xml" lens="Xml" + owner="root" group="root" mode="0640"> + <Initial><Test/></Initial> + <Set path="Test/#text" value="text content"/> + </Path> + Editing files outside the default load path =========================================== diff --git a/doc/conf.py b/doc/conf.py index 0e4009cd3..1b19d92c7 100644 --- a/doc/conf.py +++ b/doc/conf.py @@ -66,7 +66,7 @@ else: # The short X.Y version. version = '1.3' # The full version, including alpha/beta/rc tags. -release = '1.3.3' +release = '1.3.4' # The language for content autogenerated by Sphinx. Refer to documentation # for a list of supported languages. diff --git a/doc/contents.txt b/doc/contents.txt index 8220d0d1d..e7df568f9 100644 --- a/doc/contents.txt +++ b/doc/contents.txt @@ -21,6 +21,7 @@ Bcfg2 documentation |release| glossary appendix/index man/index + releases/index unsorted/index diff --git a/doc/development/testing.txt b/doc/development/testing.txt index f00193574..b6db98cca 100644 --- a/doc/development/testing.txt +++ b/doc/development/testing.txt @@ -69,8 +69,8 @@ Server Testing Entry: fs13.bgl.mcs.anl.gov.xml Entry: fs13.bgl.mcs.anl.gov.xml good Entry: login1.bgl.mcs.anl.gov.xml - ConfigFile /bin/whatami contents differ - ConfigFile /bin/whatami differs (in bundle softenv) + Path /bin/whatami contents differ + Path /bin/whatami differs (in bundle softenv) Entry: login1.bgl.mcs.anl.gov.xml bad This can be used to compare configurations for single clients, or diff --git a/doc/installation/building-packages.txt b/doc/installation/building-packages.txt new file mode 100644 index 000000000..b3b775869 --- /dev/null +++ b/doc/installation/building-packages.txt @@ -0,0 +1,228 @@ +.. -*- mode: rst -*- +.. vim: ft=rst + +.. _installation-building-packages: + +============================= +Building packages from source +============================= + +Building RPMs +============= + +Building from a tarball +----------------------- + +* Create a directory structure for rpmbuild:: + + rpmdev-setuptree + +* Copy the tarball to ``~/rpmbuild/SOURCES/`` +* Extract another copy of it somewhere else (eg: ``/tmp``) and retrieve + the ``misc/bcfg2.spec`` file +* Run the following:: + + rpmbuild -ba bcfg2.spec + +* The resulting RPMs will be in ``~/rpmbuild/RPMS/`` and SRPMs + in ``~/rpmbuild/SRPMS/``. + +Building Debian packages +======================== + +The Bcfg2 project provides a ``debian`` subdirectory with the project's +source that enables users to create their own Debian/Ubuntu compatible +packages (`.deb` files). + +Build deps +---------- + +If the distribution you are building on already has packaged bcfg2 +(even an older version), the following command will likely install the +necessary build dependencies:: + + apt-get build-dep bcfg2 bcfg2-server + +Install source code +------------------- + +Depending on which version of bcfg2 you want build, you can obtain the +source code from the Download_ page or from the project's git repository. +To create a local anonymous working copy of the latest version of the +bcfg2 source code, use a command like the following:: + + git clone git://git.mcs.anl.gov/bcfg2.git + +Update the changelog +-------------------- + +The next step is to update the ``debian/changelog`` file with an +appropriate package version string. Debian packages contain a version +that is extracted from the latest entry in this file. An appropriate +version will help you distinguish your locally built package from one +provided by your distribution. It also helps the packaging system know +when a newer version of the package is available to install. + +It is possible to skip this step, but the packages you build will have +the same version as the source distribution and will be easy to confuse +with other similarly named (but maybe not equivalent) packages. + +The basic format of the package version string to use is this:: + + <UPSTREAM VER>~<UPSTREAM PRE-VER>+<GIT-ID>-0.1+<LOCAL VER> + +.. note:: + The '+', and '-' characters have significance in determining when + one package is newer than another. The following format is believed + to do the right thing in all common situations. + +The components of the package version string are explained below: + +.. glossary:: + + <UPSTREAM VER> + This is the version of the Bcfg source code you are working + from. It will likely be something like `0.9.6` or `1.0`. + + <UPSTREAM PRE-VER> + If you are using a published pre-release of Bcfg2, it will have + a name like `pre1` or `rc1`. Use that string here, otherwise + drop this component from the package version string. + + +<GIT-ID> + If you are building from a local working copy of the git + repository, it is useful to include the revision in the package + version. If you are building from a downloaded copy of the source, + drop this component (including the preceding plus-sign (`+`) + from the package version string. + + +<LOCAL VER> + This is a locally relevant name like your last name or your + domain name, plus the digit `1`. For example, if your family + name is ''Smith'', you could use `smith1`. If you work for + ''Example Inc'', you could use `example1`. + +Here are some examples: + +* If you are building packages for revision 6c681bd from git, and the + latest published version is 1.2.0rc1, the version string should be + `1.2.0rc1+6c681bd-0.1+example1`. +* If you are building packages for the published 1.0 rc1 version, the + version string should be `1.0rc1-0.1+example1`. +* If you are building packages for the published 1.0 version, the version + string should be `1.0-0.1+example1`. + +If you are working on a git working copy of 1.0 pre5 and have the +``devscripts`` package installed, the following command is a convenient +way to create a well formatted changelog entry:: + + REV=$(git log --oneline | head -n 1 | cut -d' ' -f1) + debchange --force-bad-version --preserve --newversion "1.0~pre5+${REV}-0.1+example1" git revision $REV + +Building the package +-------------------- + +With the preliminaries out of the way, building the package is simple.:: + + cd .. # Change into the top level of the source directory + fakeroot dpkg-buildpackage -uc -us + +The freshly built packages will be deposited in the parent of the +current directory (``..``). Examine the output of ``dpkg-buildpackage`` +for details. + +External build systems +---------------------- + +This section describes how to build bcfg2 and deps via external build +systems (Currently only a PPA). Some other possibilities are: + + * #651 Look into project-builder to make more native-system bcfg2 packages available + * http://en.opensuse.org/Build_Service/Deb_builds + +Launchpad PPA +^^^^^^^^^^^^^ + +https://launchpad.net/~bcfg2 + +To upload to the PPA you need to be on the active member list of `Bcfg2 +in Launchpad`_. + +Note that **after each successful upload**, you should wait until the PPA +is built, and then **install it locally** using ``sudo aptitude update; +sudo aptitude install (packagename)`` so the next build doesn't fail on +your local machine. If you don't want to wait for a PPA binary build to +complete, you can "apt-get source (packagename)" and do a local build +before the PPA build is done. + +setup gpg-agent +""""""""""""""" + +Setting up gpg-agent and pinentry prevents you from having to type your +passphrase repeatedly.:: + + sudo aptitude install gnupg-agent pinentry-gtk2 pinentry-curses + # replace 0xAA95C349 with your GPG Key ID + export GPGKEY=0xAA95C349 + killall -q gpg-agent + eval $(gpg-agent --daemon) + +setup debuild +""""""""""""" + +Tell dpkg-buildpackage who you are, for example:: + + export DEBEMAIL="dclark@pobox.com" + export DEBFULLNAME="Daniel Joseph Barnhart Clark" + +upload bcfg2 to ppa +""""""""""""""""""" + +A ``dists`` file contains a space-separated list of all distributions +you want to build PPA packages for. + +.. code-block:: sh + + #!/bin/sh + + . ./dists + + # Replace 0xAA95C349 with your GnuPG Key ID + export GPGKEY=0xAA95C349 + + sudo apt-get build-dep bcfg2 bcfg2-server + sudo aptitude install git + + VERSION=1.3.2-1 + if [ ! -d testing ]; then + mkdir testing + fi + DATE=$(date +%F-%H%M) + ppa="testing" # "testing" or "ppa" (for stable) + + # download source + cd testing + git clone git://git.mcs.anl.gov/bcfg2 + cd bcfg2 + GITID=$(git log --oneline | head -n 1 | cut -d' ' -f1) + cp debian/changelog ../changelog.orig + + for dist in $DISTS + do + cp ../changelog.orig debian/changelog + (cd debian && dch --distribution ${dist} \ + --force-bad-version \ + --preserve \ + --force-distribution \ + --newversion "${VERSION}~${ppa}~${dist}${DATE}+${GITID}" \ + "bcfg2 backport for ${dist} release ${VERSION} git commit ${GITID}") + debuild --no-tgz-check -rfakeroot -I -S -k${GPGKEY} + done + + for dist in $DISTS + do + dput ppa:bcfg2/${dist}testing ../bcfg2_${VERSION}~${ppa}~${dist}${DATE}+${GITID}_source.changes + done + +.. _Download: http://bcfg2.org/download/ +.. _Bcfg2 in Launchpad: https://launchpad.net/~bcfg2 diff --git a/doc/installation/distributions.txt b/doc/installation/distributions.txt index 9db111682..306439485 100644 --- a/doc/installation/distributions.txt +++ b/doc/installation/distributions.txt @@ -1,4 +1,5 @@ .. -*- mode: rst -*- +.. vim: ft=rst .. _distributions: @@ -103,10 +104,12 @@ section will try and meet the dependencies using packages from EPEL_ [#f1]_. The *el5* and the *el6* package should be compatible with `CentOS`_ 5.x/6.x and `Scientific Linux`_. -EPEL_ for 5.x :: +EPEL_ for 5.x:: + [root@centos ~]# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm -EPEL_ for 6.x :: +EPEL_ for 6.x:: + [root@centos ~]# rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm Install the bcfg2-server and bcfg2 RPMs:: diff --git a/doc/installation/index.txt b/doc/installation/index.txt index 9f04d4b52..9bcf8be15 100644 --- a/doc/installation/index.txt +++ b/doc/installation/index.txt @@ -19,5 +19,5 @@ needs to be installed on any machine you plan to manage by Bcfg2. prerequisites source - packages + building-packages distributions diff --git a/doc/installation/packages.txt b/doc/installation/packages.txt deleted file mode 100644 index b23a870cf..000000000 --- a/doc/installation/packages.txt +++ /dev/null @@ -1,81 +0,0 @@ -.. -*- mode: rst -*- - -.. _packages: - -.. _CentOS: http://www.centos.org/ -.. _Red Hat/RHEL: http://www.redhat.com/rhel/ -.. _Scientific Linux: http://www.scientificlinux.org/ -.. _EPEL: http://fedoraproject.org/wiki/EPEL -.. _RPMForge: https://rpmrepo.org/RPMforge - - -Building RPM packages from source -================================= - -The Bcfg2 distribution contains two different spec files. - -Building from Tarball ---------------------- - -* Copy the tarball to ``/usr/src/packages/SOURCES/`` -* Extract another copy of it somewhere else (eg: ``/tmp``) and retrieve - the ``misc/bcfg2.spec`` file -* Run :: - - rpmbuild -ba bcfg2.spec - -* The resulting RPMs will be in ``/usr/src/packages/RPMS/`` and SRPMs - in ``/usr/src/packages/SRPMS`` - -Building from an GIT Checkout ------------------------------ - -* Change to the ``redhat/`` directory in the working copy -* Run :: - - make - -* The resulting RPMs will be in ``/usr/src/redhat/RPMS/`` and SRPMs - in ``/usr/src/redhat/SRPMS`` and will have the SVN revision appended - -Building RPM packages with ``rpmbuild`` ---------------------------------------- - -While you can go about building all these things from source, this -how to will try and meet the dependencies using packages from EPEL_. -The *el5* and the *el6* package should be compatible with CentOS 5.x. - -* Installation of the EPEL_ repository package :: - - [root@centos ~]# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-6.noarch.rpm - -* Now you can install the rest of the prerequisites :: - - [root@centos ~]# yum install python-genshi python-cheetah python-lxml - -* After installing git, check out the master branch :: - - [root@centos redhat]# git clone git://git.mcs.anl.gov/bcfg2.git - -* Install the ``fedora-packager`` package :: - - [root@centos ~]# yum install fedora-packager - -* A directory structure for the RPM build process has to be established. :: - - [you@centos ~]$ rpmdev-setuptree - -* Change to the *redhat* directory of the checked out Bcfg2 source:: - - [you@centos ~]$ cd bcfg2/redhat/ - -* In the particular directory is a ``Makefile`` which will do the job of - building the RPM packages. You can do this as root, but it's not - recommended:: - - [you@centos redhat]$ make - -* Now the new RPM package can be installed. Please adjust the path to - your RPM package :: - - [root@centos ~]# rpm -ihv /home/YOU/rpmbuild/RPMS/noarch/bcfg2-server-1.0.0-0.2r5835.noarch.rpm diff --git a/doc/installation/prerequisites.txt b/doc/installation/prerequisites.txt index e3434edd3..4121ff20a 100644 --- a/doc/installation/prerequisites.txt +++ b/doc/installation/prerequisites.txt @@ -30,6 +30,8 @@ Bcfg2 Client | debsums (if APT tool | Any | | | driver is used) | | | +----------------------------+------------------------+--------------------------------+ +| python-setuptools | Any | | ++----------------------------+------------------------+--------------------------------+ .. [#f1] python 2.5 and later works with elementtree. @@ -56,6 +58,8 @@ Bcfg2 Server +-------------------------------+----------+--------------------------------+ | python-ssl (note | Any | python, backported ssl module | +-------------------------------+----------+--------------------------------+ +| python-setuptools | Any | | ++-------------------------------+----------+--------------------------------+ Bcfg2 Reporting --------------- @@ -68,7 +72,7 @@ reporting, such as Apache + mod_wsgi or nginx. +===============================+==========+================================+ | django | 1.2.0+ | | +-------------------------------+----------+--------------------------------+ -| south | 0.7.0+ | | +| south | 0.7.5+ | | +-------------------------------+----------+--------------------------------+ Bcfg2 Reporting diff --git a/doc/installation/source.txt b/doc/installation/source.txt index 1406a5ceb..9bf023fbc 100644 --- a/doc/installation/source.txt +++ b/doc/installation/source.txt @@ -1,8 +1,9 @@ .. -*- mode: rst -*- +.. vim: ft=rst -.. _GPG1: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x75BF2C177F7D197E -.. _GPG2: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x80B8492FA88FFF4B -.. _Download: http://trac.mcs.anl.gov/projects/bcfg2/wiki/Download +.. _7F7D197E: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x75BF2C177F7D197E +.. _A88FFF4B: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x80B8492FA88FFF4B +.. _Download: http://bcfg2.org/download/ .. _source: @@ -17,8 +18,8 @@ Tarball The Bcfg2 source tarball can be grabbed from the `Download`_ page. -All tarballs are signed with GPG keys `7F7D197E <GPG1>`_ or `A88FFF4B -<GPG2>`_. You can verify your download by importing the keys and running :: +All tarballs are signed with GPG keys `7F7D197E`_ or `A88FFF4B`_. You +can verify your download by importing the keys and running :: gpg --recv-keys 0x75bf2c177f7d197e 0x80B8492FA88FFF4B gpg --verify bcfg2-<version>.tar.gz.gpg bcfg2-<version>.tar.gz diff --git a/doc/releases/1.3.4.txt b/doc/releases/1.3.4.txt new file mode 100644 index 000000000..f6bc13436 --- /dev/null +++ b/doc/releases/1.3.4.txt @@ -0,0 +1,49 @@ +.. -*- mode: rst -*- +.. vim: ft=rst + +.. _releases-1.3.4: + +1.3.4 +===== + +We are happy to announce the release of Bcfg2 1.3.4. It is available for +download at: + + ftp://ftp.mcs.anl.gov/pub/bcfg + +This is primarily a bugfix release. + +* New probes.allowed_groups option to restrict group assignments + +* Bundler fixes: + + * Fix parsing XML template output with encoding declaration + +* bcfg2-lint: + + * Resolve XIncludes when parsing XML for validation + * New TemplateAbuse plugin to detect templated scripts + * New ValidateJSON plugin + +* bcfg2-crypt fixes: + + * Fix logic + * Improve debugging/error handling with Properties files + * Fix exception handling + * Handle error when encrypting properties with multiple keys + +* Add new Augeas client tool driver: + http://docs.bcfg2.org/client/tools/augeas.html +* Restored bcfg2-admin client add functionality +* Migration tool fixes +* Schema fixes +* Add Django 1.6 support +* Use 'public' default pgsql database schema +* Refresh essential packages during Packages.Refresh +* Allow lxml.etree XML implementation to parse very large documents +* Support ACLs without a specific user/group +* Explicitly close database connections at the end of each client run +* Fix verification of symlinks + +Special thanks to the following contributors for this release: Matt Baker, +Simon Ruderich, Michael Fenn, Dan Foster, Richard Connon, John Morris. diff --git a/doc/releases/index.txt b/doc/releases/index.txt new file mode 100644 index 000000000..42a2306f6 --- /dev/null +++ b/doc/releases/index.txt @@ -0,0 +1,10 @@ +.. -*- mode: rst -*- +.. vim: ft=rst + +.. _releases-index: + +===================== +Release Announcements +===================== + +.. include:: 1.3.4.txt diff --git a/doc/server/configuration.txt b/doc/server/configuration.txt index d3fa42601..79d732f6d 100644 --- a/doc/server/configuration.txt +++ b/doc/server/configuration.txt @@ -216,3 +216,46 @@ To select which backend to use, set the ``backend`` option in the * ``best`` (the default; currently the same as ``builtin``) ``best`` may change in future releases. + +Multiprocessing core configuration +---------------------------------- + +If you use the multiprocessing core, there are other bits you may wish +to twiddle. + +By default, the server spawns as many children as the host has CPUs. +(This is determined by ``multiprocessing.cpu_count()``.) To change +this, set: + +.. code-block:: ini + + [server] + children = 4 + +The optimal number of children may vary depending on your workload. +For instance, if you are using :ref:`native yum +library support <native-yum-libraries>`, then a separate process is +spawned for each client to resolve its package dependencies, so +keeping the children at or below the CPU count is likely a good idea. +If you're not using native yum library support, though, you may wish +to oversubscribe the core slightly. It's recommended that you test +various configurations and use what works best for your workload. + +Secondly, if ``tmpwatch`` is enabled, you must either disable it or +exclude the pattern ``/tmp/pymp-\*``. For instance, on RHEL or CentOS +you may have a line like the following in +``/etc/cron.daily/tmpwatch``: + +.. code-block:: bash + + /usr/sbin/tmpwatch -x /tmp/.X11-unix -x /tmp/.XIM-unix -x /tmp/.font-unix \ + -x /tmp/.ICE-unix -x /tmp/.Test-unix 240 /tmp + +You would need to add ``-X /tmp/pymp-\*`` to it, like so: + +.. code-block:: bash + + /usr/sbin/tmpwatch -x /tmp/.X11-unix -x /tmp/.XIM-unix -x /tmp/.font-unix \ + -x /tmp/.ICE-unix -x /tmp/.Test-unix -X /tmp/pymp-\* 240 /tmp + +See https://bugzilla.redhat.com/show_bug.cgi?id=1058310 for more information. diff --git a/doc/server/plugins/generators/rules.txt b/doc/server/plugins/generators/rules.txt index c5ff699a7..86478a5ae 100644 --- a/doc/server/plugins/generators/rules.txt +++ b/doc/server/plugins/generators/rules.txt @@ -277,6 +277,7 @@ child ``<ACL>`` tags. For instance: mode="0775"> <ACL type="default" scope="user" user="foouser" perms="rw"/> <ACL type="default" scope="group" group="users" perms="rx"/> + <ACL type="default" scope="other" perms="r"/> </Path> .. xml:element:: ACL @@ -285,6 +286,9 @@ It is not currently possible to manually set an effective rights mask; the mask will be automatically calculated from the given ACLs when they are applied. +For directories either no default ACL entries or at least an entry for +the owner, owning group and other must be defined. + Note that it is possible to set ACLs that demand different permissions on a file than those specified in the ``perms`` attribute on the ``Path`` tag. For instance: diff --git a/doc/server/plugins/generators/sshbase.txt b/doc/server/plugins/generators/sshbase.txt index 641b9c598..4578d5810 100644 --- a/doc/server/plugins/generators/sshbase.txt +++ b/doc/server/plugins/generators/sshbase.txt @@ -1,4 +1,5 @@ .. -*- mode: rst -*- +.. vim: ft=rst .. _server-plugins-generators-sshbase: @@ -13,8 +14,9 @@ record for the current system. It has two functions: -* Generating new ssh keys -- When a client requests a dsa, rsa, or v1 key, - and there is no existing key in the repository, one is generated. +* Generating new ssh keys -- When a client requests a ecdsa, dsa, rsa, + or v1 key, and there is no existing key in the repository, one is + generated. * Maintaining the ``ssh_known_hosts`` file -- all current known public keys (and extra public key stores) are integrated into a single @@ -31,7 +33,7 @@ Interacting with SSHbase ``<repo>/SSHbase/<key filename>.H_<hostname>`` * Pre-seeding can also be performed using ``bcfg2-admin pull - ConfigFile /name/of/ssh/key`` + Path /name/of/ssh/key`` * Revoking existing keys -- deleting ``<repo>/SSHbase/\*.H_<hostname>`` will remove keys for an existing diff --git a/doc/unsorted/emacs_snippet.txt b/doc/unsorted/emacs_snippet.txt index b9f7fd25b..4eefb4583 100644 --- a/doc/unsorted/emacs_snippet.txt +++ b/doc/unsorted/emacs_snippet.txt @@ -31,7 +31,7 @@ More snippets are under development. ("<Group" "<Group name='${1:groupname}> $0 </Group>" nil) - ("<Config" "<ConfigFile name='${1:filename}'/> + ("<Path" "<Path name='${1:filename}'/> $0" nil) ("<Service" "<Service name='${1:svcname}'/> $0" nil) diff --git a/doc/unsorted/vim_snippet.txt b/doc/unsorted/vim_snippet.txt index e4fda7eca..4598b5c1d 100644 --- a/doc/unsorted/vim_snippet.txt +++ b/doc/unsorted/vim_snippet.txt @@ -30,9 +30,9 @@ that allow quick composition of bundles and base files. <Group name='${1:groupname}'> ${2} </Group> - # ConfigFile - snippet <Config - <ConfigFile name='${1:filename}'/> + # Path + snippet <Path + <Path name='${1:filename}'/> # Service snippet <Service <Service name='${1:svcname}'/> |