USS(8)
π USS(8) β the AFS Command Reference glow-up π
okay so bestie, welcome to uss, the command suite that's literally the intro page for the whole uss family. fair warning though: this one comes with a big deprecated sticker on it π β more on that in a sec. (also hi, this is the AFS Command Reference manual, section 8, if you were wondering πΈ)
β οΈ CAUTIONS β οΈ
not to be dramatic but listen: the uss command suite is currently designed for cells using the obsolete Authentication Server, so it's primarily useful for sites that haven't migrated to a Kerberos version 5 KDC yet. and the tea is that the Authentication Server and its supporting commands will be removed in a future version of OpenAFS π β and that may include uss itself, unless someone who finds it useful actually converts it to work with a Kerberos version 5 KDC. so like... adopt it or lose it, iykyk π
β¨ DESCRIPTION β¨
the commands in the uss command suite help administrators create AFS user accounts more easily and efficiently, but only for cells using that obsolete Authentication Server. why bother? because if you don't use uss commands, creating a single account requires issuing at least six separate commands to five different AFS servers. six. commands. five. servers. no cap, that's giving suffering π uss ate that whole process up.
there are three main commands in the suite, and yes they're all iconic in their own way:
- the
uss addcommand creates a single complete user account, based on command line arguments and instructions in a template file π«Ά - the
uss bulkcommand creates multiple complete accounts at once, based on command line arguments, instructions in a template file, and a bulk input file π - the
uss deletecommand removes most parts of a user account π₯
to obtain help, issue the uss apropos and uss help commands. they're your besties for finding stuff π
π¦ OPTIONS π¦
the following arguments and flags are available on many commands in the uss suite. each command's own reference page also lists them, but here they're described in greater detail β so this is the main character version, basically β¨
-admin<administrator to authenticate> β specifies the AFS user name under which to establish a connection to the AFS server processes that administer the various parts of a user account. if it's omitted, the connection is established under the issuer's effective user ID (like, their identity in the local file system, bestie). even when this argument is included, UNIX commands that run during theussoperation (for instance, the UNIX/etc/chowncommand) run under the effective user ID. so yeah, it doesn't change that π-cell<cell name> β names the cell in which to run the command. it is acceptable to abbreviate the cell name to the shortest form that distinguishes it from the other entries in the/etc/openafs/CellServDBfile on the local machine. if the-cellargument is omitted, the command interpreter determines the name of the local cell by reading the following in order:- the value of the
AFSCELLenvironment variable π - the local
/etc/openafs/ThisCellfile π
- the value of the
-dryrunβ reports actions that the command interpreter needs to perform when executing theussoperation, without actually performing them. include this flag to verify that the command produces the desired account configuration. combine it with the-verboseflag to yield even more detailed information π. note that the output does not necessarily reveal all possible problems that can prevent successful execution of the command β especially those that result from transient server or network outages. so like, a vibe check, not a guarantee π-helpβ prints a command's online help message on the standard output stream. do not combine this flag with any of the command's other options; when it's provided, the command interpreter ignores all other options and only prints the help message. it's a one-track-mind situation and honestly, respect π-skipauthβ bypasses mutual authentication with the AFS Authentication Server, allowing a site that uses Kerberos instead of the AFS Authentication Server to substitute that form of authentication. important though: if this option is given,ussdoes not create or manipulate Kerberos principals. a Kerberos principal must be created separately from theuss addcommand. your principals are your business, bestie π«Ά
π PRIVILEGE REQUIRED π
the issuer of a uss command must have all the rights required for performing the equivalent actions individually. like, no shortcuts, the permissions math is the permissions math. see each uss command's reference page for the details π
πΈ SEE ALSO πΈ
go read these next, they're all linked and they all matter:
uss(5), uss_bulk(5), uss_add(8), uss_apropos(8), uss_bulk(8), uss_delete(8), uss_help(8)
π COPYRIGHT π
IBM Corporation 2000. <http://www.ibm.com/> All Rights Reserved.
this documentation is covered by the IBM Public License Version 1.0. it was converted from HTML to POD by software written by Chas Williams and Russ Allbery, based on work by Alf Wachsmann and Elizabeth Cassell. converting HTML to POD? that's labor, and we appreciate them β¨
and that's the whole page, bestie β brought to you by OpenAFS, dated 2026-06-25, filed under USS(8) in that AFS Command Reference. now go forth and make accounts the efficient way (while the Authentication Server still exists ππ). mwah π
π
π¦ where this page comes from
- nixos 26.05: openafs 1.8.16.1
- nixpkgs unstable: openafs 1.8.16.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms