<li><a href="#3.48 What is a Volume Group?"> 3.48 What is a Volume Group?</a></li>
<li><a href="#3.49 What is a Clone?"> 3.49 What is a Clone?</a></li>
<li><a href="#3.50 What is a Shadow?"> 3.50 What is a Shadow?</a></li>
+ <li><a href="#3.51 Can I authenticate to my af"> 3.51 Can I authenticate to my afs cell using multiple kerberos Realms?</a></li>
+ <li><a href="#3.52 Is it a good idea to store"> 3.52 Is it a good idea to store mail in AFS?</a></li>
+ <li><a href="#3.53 How can I ensure that the"> 3.53 How can I ensure that the userids on client machines match the users' pts ids?</a></li>
+ <li><a href="#3.54 What is Fast Restart?"> 3.54 What is Fast Restart?</a></li>
+ <li><a href="#3.55 Reboot ?"> 3.55 Why does AFS reboot itself spontaneously at 4:00am every Sunday?</a></li>
</ul>
</li>
</ul>
</div>
+
- [[ResourcesFAQ]]
- [[AboutTheFAQ]]
- [[FurtherReading]]
grep 19270407 /usr/afsws/include/rx/*
/usr/afsws/include/rx/rxkad.h:#define RXKADBADTICKET (19270407L)
+Note that a common cause of this problem is the use of periods (".") in kerberos principals. If you have a kerberos principal such as my.name@REALM.COM and create the corresponding pts userid "my.name" you will get the cryptic error above. If you want to use such principal names and have OpenAFS 1.4.7 or later, you can pass the option -allow-dotted-principals to all server daemons to allow their use. See the -allow-dotted-principals option in the fileserver (or any server daemon) documentation for more information.
+
### <a name="3.45 I get tickets and tokens, b"></a> 3.45 I get tickets and tokens, but still get Permission denied.
Answer: /usr/afs/etc/UserList accepts only krb4 syntax. Use `joe.admin` instead of `joe/admin`. See `https://lists.openafs.org/pipermail/openafs-devel/2002-December/008673.html` and the rest of the thread.
You can "refresh" a shadow volume from its original with "vos shadow -incremental". This operation will first check to make sure that the target of the operation is a shadow volume, to prevent the administrator from accidentally corrupting a non-shadow volume. However, if you shadow from a readwrite volume to some shadow of **another** volume, the shadow will be corrupted and will have to be deleted. Vos shadow will only copy data which has changed, so it is very efficient.
-You can remove the shadow bit from a volume's header with "vos shadow -live". This will remove the shadow bit and create a VLDB entry for the volume, deleting any previous entry for the rw volume. However, the rw volume itself will not be deleted; it will simply exist without a VLDB entry.
+You can remove the shadow bit from a volume's header with "vos syncvldb -force". This will remove the shadow bit and create a VLDB entry for the volume, deleting any previous entry for the rw volume. However, the rw volume itself will not be deleted; it will simply exist without a VLDB entry.
Attempting to create shadows of two different rw volumes on the same partition with the same name is prohibited by the volserver. Technically it is possible to create two shadow volumes with the same name on different partitions; however, this is not advisable.
+
+### <a name="3.51 Can I authenticate to my af"></a> 3.51 Can I authenticate to my afs cell using multiple kerberos Realms?
+
+Yes. This can be usefull if your organization has multiple kerberos Realms with identical user entries: For example you might have an MIT Kerberos realm for Unix-like systems, and an Active Directory domain for windows with synchronized accounts.
+
+As long as you only need to support 2 realms, and one of them has the same name as the afs cell(or the uppercase of the name of the afs cell) you can do this without upgrading to a new version of AFS. If you need more Realms, or if neither Realm name matches your cell name, there is work to support this in the development tree.
+
+In order to make this work, you need to do 4 things.
+
+1) add a key for the afs service to the additional realm and store it in a keytab:
+
+ $ kadmin -q ank -e des-cbc-crc:v4 -kvno <new kvno> afs/your.cell.name@YOUR.SECOND.REALM.NAME
+ $ kadmin -q ktadd -e des-cbc-crc:v4 -k /path/to/afs.keytab afs/your.cell.name@YOUR.SECOND.REALM.NAME
+
+Note that a kvno must be specified for the key that is different than the kvno for your existing key(s) in the original realm. you can check on the kvno of the existing keys by running "asetkey list" on one of your servers. since keys must be in ascending order in the AFS [[KeyFile]] it will be easiest if you make the new kvno higher than any existing key's kvno.
+
+It's also worth noting that the process of adding the key to a keytab(at least with MIT krb5) actually creates a new key first, so your kvno will end up being higher than what you specified when you added the principal. you can check on the current kvno by using the "kadmin -q getprinc afs/your.cell.name@YOUR.SECOND.REALM.NAME" command.
+
+2) add the new key to the afs [[KeyFile]] on your afs servers:
+
+ $ asetkey add <kvno> /path/to/afs.keytab afs/your.cell.name@YOUR.SECOND.REALM.NAME
+
+note that the kvno here needs to be the same one as is reported by the kadmin getprinc command.
+
+3) create an afs krb.conf with your additional Realm's name in it, and place it on all of your AFS servers:
+
+ echo "YOUR.SECOND.REALM.NAME" > /usr/afs/etc/krb.conf
+
+4) restart you afs servers.
+
+at this point you should be able to run:
+
+ kinit you@YOUR.SECOND.REALM.NAME
+ aklog
+
+and recieve the same privileges as if you had run:
+
+ kinit you@YOUR.CELL.NAME
+ aklog
+
+### <a name="3.52 Is it a good idea to store"></a> 3.52 Is it a good idea to store mail in AFS?
+
+Some people have expressed the opinion that this is not a good idea. Assuming that a modern (one-file-per-message) format is being used, the concrete reasons to avoid storing mail in AFS include:
+
+1. AFS is not designed to provide good performance under the sort of concurrent accesses that occur when many mail server machines share a common space in AFS; see [this message](http://www.openafs.org/pipermail/openafs-info/2007-June/026621.html) for more information.
+ - This does not apply to situations where there is a single mail server for a particular user.
+ - This also may not apply if [Callback Extended Information](http://michigan-openafs-lists.central.org/archives/afs3-standardization/2008-May/000123.html) is implemented.
+
+### <a name="3.53 How can I ensure that the"></a><a name="3.53 How can I ensure that the "></a> 3.53 How can I ensure that the userids on client machines match the users' pts ids?
+
+You can use [libnss-afs](http://www.hcoop.net/~megacz/software/libnss-afs.html) for this.
+
+### <a name="3.54 What is Fast Restart?"></a> 3.54 What is Fast Restart?
+
+When compiled with --enable-fast-restart, the file server will start up immediately, without first salvaging any volumes which cannot be attached.
+
+Disadvantages to Fast Restart, [as noted here](http://lists.openafs.org/pipermail/openafs-info/2008-May/029386.html) include:
+
+1. Volumes in need of salvage remain offline until an administrator intervenes manually
+2. On an inode-based fileserver, salvaging a single volume crawls every inode; therefore, salvaging volumes individually (rather than partition-at-a-time) duplicates work.
+
+### <a name="#3.55 Reboot ?"></a> 3.55 Why does AFS reboot itself spontaneously at 4:00am every Sunday?
+
+Nobody's really sure why this behavior is the default, but you can disable it with
+
+ bos setrestart $SERVER_NAME never
+ bos setrestart $SERVER_NAME -newbinary never
git://git.openafs.org / openafs-wiki.git / blobdiff