[OpenAFS] documentation of unix owner/group/mode semantics (Was: chown())

[Adam Megacz]

I've made a FAQ entry on the AFSLore wiki in an attempt to
comprehensively document the complete semantics of the owner, group,
and mode bits in AFS:

  
http://www.dementia.org/twiki/bin/view/AFSLore/UsageFAQ#2_21_What_meaning_do_the_UNIX_ow

If I got anything wrong or left anything out, please let me know and I
will update it.  I'd like to try to make this as complete as possible.

  - a


Jeffrey Hutzelman <[EMAIL PROTECTED]> writes:
>>> Not true.  There are a number of subtle uses of file owners in AFS,
>>> particularly with regard to how directories work where you have 'i'
>>> but not 'w'.
>>
>> Hrm.  Are these documented anywhere (other than the source code)?
>
> The published documentation explains how dropboxes work from the
> user's point of view.  I don't believe there is a good description of
> the mechanisms that make it work, but basically, if you have 'i' on a
> directory, the fileserver will let you write to files in that
> directory which you own.
>
> -- Jeff

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Re: chown()

[David Bear]

On Thu, Mar 29, 2007 at 11:59:21PM -0400, Jeffrey Hutzelman wrote:
> 
> 
> The published documentation explains how dropboxes work from the user's 
> point of view.  I don't believe there is a good description of the 

I was just looking at openafs.org and can't seem to find this.

Do you have a url the points me to how to make a dropbox in afs?

by dropbox, I would assume something like (system:anyuser - i) but I'd
like to see more.


-- 
David Bear
phone:  602-496-0424
fax:602-496-0955
College of Public Programs/ASU
University Center Rm 622
411 N Central
Phoenix, AZ 85007-0685
 "Beware the IP portfolio, everyone will be suspect of trespassing"
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Can't get this going on Coraid CLN22 (Debian).

[Tony Shadwick]

I think what I'm going to try then today is plug a spare SATA hard drive 
into the SR1520, set it up as a raid0, let the CLN pick it up, and 
designate it as swap (or I guess I could use LVM and do the same?) and 
see if that fixes things as well.  If so, then the simplest thing to 
instruct CLN users to do is make sure they allot swap prior to 
attempting OpenAFS.


Ed L. Cashin wrote:

On Thu, Mar 29, 2007 at 08:00:49PM -0500, Tony Shadwick wrote:
I won't call it "fixed", but with much help from the guys in #openafs, 
we did get things working.


That's great!

...

The stack size is set to 8192.  We had to change that to unlimited,
then things started working, so ulimit -s unlimited.


I see.


Ed, if you see this...any thoughts on what might cause this?


Well, an OpenAFS process probably has a large array or similar data
structure on its stack (usually a function-local variable in a C
program).

The ulimit is a system setting that prevents processes from using a
large amount of memory for stack space.  On the CLN or other server,
especially one without swap space, that limit could help to prevent a
greedy user process from consuming the RAM that the system needs to
perform well.

The setting is a trade off.  By removing the limit, you give processes
greater freedom while losing the stability that the limit can provide.

In the end, user processes can usually perform a denial of service
attack somehow on the local host, whether it's with the notorious
"fork bomb" or some more insidious exploitation of a weakness in the
kernel.  Still, multi-level security is a good policy.

I've been instructed to file a bug report on openafs-bugs, and to debian 
regarding the package, as the /etc/init.d/openafs-filserver script has 
to be modified to do ulimit -s unlimited at each startup, as the setting 
is a per-session thing.  Speculation as to the cause is welcome.


A per-session setting sounds like a good solution.

Please don't think a small thing of this.  I've spent well over 40 
hours, along with the help of several people to weed this out!


Yes, it sounds like it was quite a lot of work.  I'm glad that the
OpenAFS developers were so helpful and responsive, and I hope that
your solution will be found by others in the mailing list archives.

Congrats on recruiting allies and tracking it down!


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Re: unix owner/group of files in AFS

[Jeffrey Hutzelman]

On Friday, March 30, 2007 01:25:31 PM +0200 FB <[EMAIL PROTECTED]> wrote:


I'll bet you also haven't tried it with a fileserver down.


Yes. Actually, my test cell has some fileservers and one of 3 db-servers
down-by-default. The only impact is a short delay on bootup of the
afs-client until ptdbnssd marked the db-server down.

Did I mention, that the nss-plug is just a very small piece of software,
talking to a local server process (ptdbnssd) which does the real
PTDB-stuff?


You did.  I was talking about the case where you get shells or other 
information from users' home directories, and one of the fileservers 
housing user volumes is down, so you get to wait while it times out.


-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Backup methods

[Sergio Gelato]

* Gert Burger [2007-03-30 13:52:58 +0200]:
> Brian Sebby wrote:
> >The main issue in backing up AFS is that you need to preserve the ACLs that
> >are stored in the directory structure - if you just back it up as files
> >you're going to lose that.
[...]
> >What we do (and I suspect many others) is to use the command 'vos dump' to
> >dump each volume to a disk file that contains the ACL information.  The
> >downside to this is that you don't have file backups from AFS - just volume
> >backups.  To get the names of the volumes to dump, I use the 'vos 
> >backupsys'
> >command to create .backup volumes of all of my volumes at a certain time of
> >day (usually 4am), and then have a script parse the output of the
> >'vos listvol' command to find all the backup volumes and back those up.
[...]
 
> My problem with dumping a volume and doing a backup of that is that it 
> seems difficult to do incrementals.

"vos dump" does support incrementals. As a matter of fact, I do mostly
incrementals. An incremental dump consists of a full dump of the
directory vnodes (so you have all the latest ACLs and directory
listings) plus the contents of any files modified after the starting
time you specify for the incremental.

> We only have enough space for about 3x the amount of data we on our 
> backup server and we dont use tapes at all. 

[Aside: I'd question the wisdom of not using tapes as a second stage.
Backup servers are about as likely to suffer disk failures as anything
else.]

Incremental 'vos dump's aren't that different from the file-level backups
you might do with other systems (e.g., rsync with the --link-dest option).
A common limitation is that they do not deal well with frequent small
changes to large files; if your users do a lot of those, you'll want to
apply some xdelta-like compression tricks to your backups. (Are you
doing something like this already?)

One thing one could do is post-process the dump files from vos, keeping
the dump header and the directory vnodes but splitting off the file
vnodes to individual files on the backup host's filesystem, and
compressing previous generations of a given file with xdelta. The
format of the dump files is relatively easy to parse, and there are
tools to do that. Have a look in /afs/grand.central.org/software/dumpscan/.
Whether this is worth the trouble depends on your usage patterns (and
on your budget: it may be simpler to increase your storage capacity).

> Therefore we need to 
> optimize our disk space usage so that we can keep daily incrementals for 
> up to a month(We do a full backup monthly).
> 
> Currently I am considering just to backup the files and lose the ACL's, 
> seeing as we wont have complicated ACLs in anycase.

That's usually up to the users. Make assumptions at your own risk.
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] kaserver database migration

[GABRIEL KAPITANY]

Hi,

I'm trying to migrate users from one afs server, version 1.2.11 to another one 
version, 1.4.2. Is there a way to export the kaserver user list and paswords 
and import it into the other server.

I've tried to copy kaserver.DB0 to the new server but this won't work properly.

Any suggestion ?

Thanks,
Gabriel

Re: [OpenAFS] Backup methods

[Todd M. Lewis]

On Thu, Mar 29, 2007 at 10:07:42AM +0200, Gert Burger wrote:
We are currently switching to openafs but are concerned about how to 
backup our data.
My problem with dumping a volume and doing a backup of that is that it 
seems difficult to do incrementals.
We only have enough space for about 3x the amount of data we on our 
backup server and we dont use tapes at all. Therefore we need to 
optimize our disk space usage so that we can keep daily incrementals for 
up to a month(We do a full backup monthly).


Currently I am considering just to backup the files and lose the ACL's, 
seeing as we wont have complicated ACLs in anycase.


Okay, consider it, but also consider that the big wins that AFS/OpenAFS 
gives you come from volume management and ACLs, both of which will be 
lost in your backups if you only backup files. I appreciate your dilemma 
though.


If you're going to end up scripting things, why not take the extra step 
when you backup a directory to create a file in each directory, say 
".__vol_acl_info" maybe, that contains the volume name, the path from 
the root of the volume to this directory, the owner of the root of the 
volume, the directory's owner and mode, and a dump of the directory's 
ACLs. This should give you enough information to restore a volume from 
your file-based incremental backups. Because these files would rarely 
change,  they should have minimal impact on your backup store. Plus, 
sometimes what you really need to restore isn't the files but the ACLs 
themselves, and this would let you do that.


It might be a bit of work, but it's probably worth it.
--
   +--+
  / [EMAIL PROTECTED]  919-445-9302  http://www.unc.edu/~utoddl /
 /Atheism is a non-prophet organization./
+--+
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Status of libadmin?

[Jakub Witkowski]

Hello,

I am currently working on a hybrid backup system for AFS in Python. At
the moment, my ability to interact with AFS servers is limited to
running vos and bos commands in a subshell; I would like to change that.

Therefore, I'd like to ask if:

- there is any documentation for the library, apart for the source?
While it is the most reliable documentation, source isn't exactly the
most readable form of manual.

- the library works fully in Kerberos 5 enviroinment?
I noticed someone mentioning that this library has dependencies on
kaserver, which quite worries me as we have pure krb5 enviroinment.


Jakub.


signature.asc
Description: To jest część listu	podpisana cyfrowo

Re: [OpenAFS] Backup methods

[Gert Burger]

Brian Sebby wrote:
The only software that I'm aware of that currently supports AFS backups 
natively is TIBS.  Veritas NetBackup used to support AFS, but they officially

discontinued support a couple of versions ago (although the plugin continues
to work for now).

The main issue in backing up AFS is that you need to preserve the ACLs that
are stored in the directory structure - if you just back it up as files
you're going to lose that.

What we do (and I suspect many others) is to use the command 'vos dump' to
dump each volume to a disk file that contains the ACL information.  The
downside to this is that you don't have file backups from AFS - just volume
backups.  To get the names of the volumes to dump, I use the 'vos backupsys'
command to create .backup volumes of all of my volumes at a certain time of
day (usually 4am), and then have a script parse the output of the
'vos listvol' command to find all the backup volumes and back those up.

I could send you the script if you're interested, but I'd need to clean it
up first - it contains some site-specific stuff that I'd need to remove.


Brian

On Thu, Mar 29, 2007 at 10:07:42AM +0200, Gert Burger wrote:
  

Morning

We are currently switching to openafs but are concerned about how to 
backup our data.
Our current setup uses bacula to backup all our data to a central server 
which stores incrementals/differentials and full backups for up to 2 months.


We would like to continue using it when all our users(Over 4000) have 
been moved to openafs.


Any ideas?

--
Gert Burger

TechTeam
Computer Science Department
University of Pretoria

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info



  
My problem with dumping a volume and doing a backup of that is that it 
seems difficult to do incrementals.
We only have enough space for about 3x the amount of data we on our 
backup server and we dont use tapes at all. Therefore we need to 
optimize our disk space usage so that we can keep daily incrementals for 
up to a month(We do a full backup monthly).


Currently I am considering just to backup the files and lose the ACL's, 
seeing as we wont have complicated ACLs in anycase.


Thanks for all the responses.

--
Gert Burger

TechTeam
Computer Science Department
University of Pretoria

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Setting up second AFS server

[Jeffrey Altman]

Melvin Wong wrote:
> aklog: unable to obtain tokens for cell ben.muveenet (status: 11862788).

11862788 = a pioctl failed

Do you have an AFS client on the machine?




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [OpenAFS] vicepa not detected

[Dimitris Zilaskos]

tail /usr/afs/logs/SalvageLog
@(#) OpenAFS 1.3.86 built  2005-08-05
03/29/2007 22:10:43 STARTING AFS SALVAGER 2.4 (/usr/afs/bin/salvager -f
/vicepa)
03/29/2007 22:10:43 salvage: Unknown or unmounted partition /vicepa;
salvage aborted

I tried restarting openafs many times, nothing changed.


Is /vicepa a mountpoint?  What do you get from:

 mount

If it's NOT a mountpoint then try:

 touch /vicepa/AlwaysAttach

And then restart.



That did the trick. Thnx a lot:) (it was not a mount point)



--


Dimitris Zilaskos

Department of Physics @ Aristotle University of Thessaloniki , Greece
PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc
  http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc
MD5sum  : de2bd8f73d545f0e4caf3096894ad83f  pgp_public_key.asc

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Re: unix owner/group of files in AFS

[FB]

Hi,

On Thu, Mar 29, 2007 at 11:56:56PM -0400, Jeffrey Hutzelman wrote:

> OK; so you haven't yet tried it in an environment where scalability is an
> issue.  I have at least ten times that many clients, and my site is pretty
> small.  Ask the folks at UMich or Morgan Stanley how that would work for
> them.

I actually wrote this nss-module to provide a simple way of uid-name-resolution
for Instantafs. Instantafs is a concept for interactively creating AFS-cells
which I decided to avoid ldap for.

I never intended to use it for bigger cells but when i tried it in my ~150 PC
cell, it outperformed the ldap-uid-name-resolution - so I kept using it.

> I'll bet you also haven't tried it with a fileserver down.

Yes. Actually, my test cell has some fileservers and one of 3 db-servers
down-by-default. The only impact is a short delay on bootup of the afs-client
until ptdbnssd marked the db-server down.

Did I mention, that the nss-plug is just a very small piece of software,
talking to a local server process (ptdbnssd) which does the real PTDB-stuff?

Regards,

Frank
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Setting up second AFS server

[Melvin Wong]

Hi,

I have managed to setup the 1st AFS server with MIT Kerberos 5 but is
having some problems setting the 2nd one.  Can anyone guide me in making
changes to the 2nd server for the Kerberos 5 to work? I've copied over
the krb5.conf from the 1st server but  the aklog -d shows:

 

Authenticating to cell ben.muveenet (server afs1.ben.muveenet).

We've deduced that we need to authenticate to realm BEN.MUVEENET.

Getting tickets: afs/[EMAIL PROTECTED]

Principal not found, trying alternate service name: [EMAIL PROTECTED]

Using Kerberos V5 ticket natively

About to resolve name admin to id in cell ben.muveenet.

Id 1

Set username to AFS ID 1

Setting tokens. AFS ID 1 /  @ BEN.MUVEENET

aklog: unable to obtain tokens for cell ben.muveenet (status: 11862788).

 

and there are no tokens held by the cache manager after I do a "kinit
admin".

 

Thank you.



Melvin

---
Melvin Wong
IT Operations Engineer
+65 6720 0413 tel
+65 9489 5221 cell
+65 6720 0421 fax

Unlock the feeling
   www.muvee.com  

---
133 Middle Road, Level 4 BOC Plaza, Singapore 188974
All information in this message should be treated as confidential
unless otherwise indicated 

Re: [OpenAFS] vicepa not detected

[Derek Atkins]

Dimitris Zilaskos <[EMAIL PROTECTED]> writes:

> tail /usr/afs/logs/SalvageLog
> @(#) OpenAFS 1.3.86 built  2005-08-05
> 03/29/2007 22:10:43 STARTING AFS SALVAGER 2.4 (/usr/afs/bin/salvager -f 
> /vicepa)
> 03/29/2007 22:10:43 salvage: Unknown or unmounted partition /vicepa; 
> salvage aborted
>
> I tried restarting openafs many times, nothing changed.

Is /vicepa a mountpoint?  What do you get from:

  mount

If it's NOT a mountpoint then try:

  touch /vicepa/AlwaysAttach

And then restart.

-derek
-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   [EMAIL PROTECTED]PGP key available
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info