[OpenAFS] Linux Login Cluster with AFS

[mohammed saif]

Hi list,

How are you doing?

I have to do a project related to LLC (Linux Login Cluster) and AFS
(Andrew File System). Please if you know some manuals to read about
these ideas and how to implement them together, PLEASE inform me. I'm
googling since 2 days but there is nothing appropriate till now except
some principles.

I tried to test the AFS by downloading and installing the packages
from www.openafs.org but most documentations concentrate on using the
IBM AFS CD-ROM (To have some modules that I couldn't find through the
net). If its necessary I can recommend to buy the software. but I do
need some extensive manuals for both together to get the big picture.

Please send me any ideas.

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

[OpenAFS] Automatic move of volumes

[Jacob Volstrup]

Hi,

For quite some time I've been searching for something to help me move
some volumes from a constantly failing /vicepa raid to my new /vicepb.
The reason for not doing this manually is partly that I'm lazy and
Further, I would like to have this fully automated if I would like to
move them back in the future (perhaps when the disks for /vicepa are
replaced).

So my big question is if there exists anything to help migrate volumes
from one partition to another which keeps the mount point intact?

Sincerely, Jacob Volstrup

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

Re: [OpenAFS] Automatic move of volumes

[Steve Devine]

Jacob Volstrup wrote:

Hi,

For quite some time I've been searching for something to help me move
some volumes from a constantly failing /vicepa raid to my new /vicepb.
The reason for not doing this manually is partly that I'm lazy and
Further, I would like to have this fully automated if I would like to
move them back in the future (perhaps when the disks for /vicepa are
replaced).

So my big question is if there exists anything to help migrate volumes
from one partition to another which keeps the mount point intact?

Sincerely, Jacob Volstrup

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
  
The mount point(s) are independent of volume location. Thats the beauty 
of AFS you can move volumes at will and the user is unaware.
Myself I get a root token and run vos listvol 'servername vicepX' 
>somefile and then grep out the RW vols and use a perl script to move 
em. If you have RO vols then you need to make sure you deal with them.  
But its pretty straight forward. No doubt there are more elegant ways to 
do this but I like a chance to review things as they go.

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

Re: [OpenAFS] Automatic move of volumes

[Frank Burkhardt]

On Wed, Oct 24, 2007 at 01:34:51PM +0200, Jacob Volstrup wrote:
> Hi,
> 
> For quite some time I've been searching for something to help me move
> some volumes from a constantly failing /vicepa raid to my new /vicepb.
> The reason for not doing this manually is partly that I'm lazy and
> Further, I would like to have this fully automated if I would like to
> move them back in the future (perhaps when the disks for /vicepa are
> replaced).

If you can afford some downtime, the most efficient way is to simply copy
the files from /vicepa to /vicepb on the server's filesystem:

 cd /vicepa;cp -a . /vicepb

Make sure, /vicepb is empty before that.

Warning: This worked for me lots of times but be carefull anyway.

Regards,

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

Re: [OpenAFS] Linux Login Cluster with AFS

[Derrick Brashear]

On 10/24/07, mohammed saif <[EMAIL PROTECTED]> wrote:
>
> Hi list,
>
> How are you doing?
>
> I have to do a project related to LLC (Linux Login Cluster) and AFS
> (Andrew File System). Please if you know some manuals to read about
> these ideas and how to implement them together, PLEASE inform me. I'm
> googling since 2 days but there is nothing appropriate till now except
> some principles.
>
> I tried to test the AFS by downloading and installing the packages
> from www.openafs.org but most documentations concentrate on using the
> IBM AFS CD-ROM (To have some modules that I couldn't find through the
> net). If its necessary I can recommend to buy the software. but I do
> need some extensive manuals for both together to get the big picture.
>
> Please send me any ideas.


./configure --enable-transarc-paths
make dest

and then you get something that looks like a cdrom, if that's really what
you want.

Re: [OpenAFS] Automatic move of volumes

[Steven Jenkins]

On 10/24/07, Steve Devine <[EMAIL PROTECTED]> wrote:
> Jacob Volstrup wrote:
...run vos listvol 'servername vicepX'
>  >somefile and then grep out the RW vols and use a perl script to move
> em. If you have RO vols then you need to make sure you deal with them.
> But its pretty straight forward.


Assuming your new location does not already have the ROs on it:

1 vos listvol to get the list of volumes to move; if the old location
is not empty, then, in this order:

2 For RO volumes: vos addsite to the new location, vos release, vos
remove old ROs
3 For RW volumes: vos move
4 For .backup volumes: vos backup (or backupsys, depending on how you
made them in the first place) once the RW volumes are moved
5 Goto 1

All this can be done while users are accessing their data, but if you
do this at a relatively quiet time you can avoid some potential
problems (eg, when this is done, snapshots are taken -- if the
volserver can't get a 'good' snapshot, the vos move will fail; clients
may see messages about a volume being busy; etc).

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

Re: [OpenAFS] Automatic move of volumes

[Derrick Brashear]

On 10/24/07, Steven Jenkins <[EMAIL PROTECTED]> wrote:
>
> On 10/24/07, Steve Devine <[EMAIL PROTECTED]> wrote:
> > Jacob Volstrup wrote:
> ...run vos listvol 'servername vicepX'
> >  >somefile and then grep out the RW vols and use a perl script to move
> > em. If you have RO vols then you need to make sure you deal with them.
> > But its pretty straight forward.
>
>
> Assuming your new location does not already have the ROs on it:
>
> 1 vos listvol to get the list of volumes to move; if the old location
> is not empty, then, in this order:
>
> 2 For RO volumes: vos addsite to the new location, vos release, vos
> remove old ROs
> 3 For RW volumes: vos move
> 4 For .backup volumes: vos backup (or backupsys, depending on how you
> made them in the first place) once the RW volumes are moved
> 5 Goto 1


perl scripts exist to do it and I think have been posted here in the past;
they may even deal with the "RO already exists" case.

the interesting case is where the RW has unreleased changes and you want to
recreate the ROs as they are now. i don't know of distributed tools to do
this.

Re: [OpenAFS] Automatic move of volumes

[Steve Devine]

Frank Burkhardt wrote:

On Wed, Oct 24, 2007 at 01:34:51PM +0200, Jacob Volstrup wrote:
  

Hi,

For quite some time I've been searching for something to help me move
some volumes from a constantly failing /vicepa raid to my new /vicepb.
The reason for not doing this manually is partly that I'm lazy and
Further, I would like to have this fully automated if I would like to
move them back in the future (perhaps when the disks for /vicepa are
replaced).



If you can afford some downtime, the most efficient way is to simply copy
the files from /vicepa to /vicepb on the server's filesystem:

 cd /vicepa;cp -a . /vicepb

Make sure, /vicepb is empty before that.

Warning: This worked for me lots of times but be carefull anyway.

Regards,

Frank
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
  
Wow this seems like a recipe for disaster. Do you then sync the vldb or 
rename the partiton to vicepa ?

/sd

--
Steve Devine
Network Storage and Printing
Academic Computing & Network Services
Michigan State University

506 Computer Center
East Lansing, MI 48824-1042
1-517-432-7327

Baseball is ninety percent mental; the other half is physical.
- Yogi Berra 


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

Re: [OpenAFS] Automatic move of volumes

[chas williams - CONTRACTOR]

In message <[EMAIL PROTECTED]>,Jacob Volstrup writes:
>For quite some time I've been searching for something to help me move
>some volumes from a constantly failing /vicepa raid to my new /vicepb.
>The reason for not doing this manually is partly that I'm lazy and
>Further, I would like to have this fully automated if I would like to
>move them back in the future (perhaps when the disks for /vicepa are
>replaced).

i wrote this a while back when i was migrating file servers.  it takes
4 arguments,,
and optionally the -ro flag to also move the read-only's.

it generates a list of commands that you typically run with /bin/sh (or
you could just pipe to sh), so if you want to revert your actions at a
later save this as a script and do a little sed magic on it to reverse
the actions.

it doesnt deal with the duplicate readonly problems.  that wouldnt be
hard to add or you could just live with the errors.

#!/usr/bin/perl

eval "exec perl -S $0 $*"
if $running_under_some_shell;

$from_server = "";
$from_partition = "";
$to_server = "";
$to_partition = "";

$do_ro = 0;

while ($_ = shift(@ARGV) )
{
option:
{
/^-ro$/ && (++$do_ro, last option);
/^-/ && do {print STDERR "bad option \"$_\"\n"; last option};

end:
{
$from_server eq "" && ($from_server = $_, last end);
$from_partition eq "" && ($from_partition = $_, last 
end);
$to_server eq "" && ($to_server = $_, last end);
$to_partition eq "" && ($to_partition = $_, last end);
}
}
}

open(LISTVOL, "vos listvol $from_server $from_partition|");

while()
{
chop;
($volume, $volid, $rw, $size, $k, $status) = split;

$volid =~ /[0-9]+/ && do
{
$rw eq "RW" && do
{
printf "vos move %s %s %s %s %s -verbose\n",
$volume,
$from_server, $from_partition,
$to_server, $to_partition;
};

$rw eq "RO" && $do_ro && do
{
$volume =~ s/\.readonly$//;

printf "vos remsite %s %s %s\n", $from_server, 
$from_partition, $volume;
printf "vos addsite %s %s %s\n", $to_server, 
$to_partition, $volume;
printf "vos release %s -verbose -f\n", $volume;
};
}
}

exit 0;


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

Re: [OpenAFS] Automatic move of volumes

[Steven Jenkins]

On 10/24/07, Derrick Brashear <[EMAIL PROTECTED]> wrote:
...
> perl scripts exist to do it and I think have been posted here in the past;
> they may even deal with the "RO already exists" case.
>

It would be nice if there were a repository of publically available
contrib stuff like that.

> the interesting case is where the RW has unreleased changes and you want to
> recreate the ROs as they are now. i don't know of distributed tools to do
> this.
>

I hadn't really thought about people intentionally keeping their RWs &
ROs out of sync w/each other.  I'm not clear why someone would want to
do that -- could you elaborate?

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

Re: [OpenAFS] Automatic move of volumes

[Derrick Brashear]

On 10/24/07, Steven Jenkins <[EMAIL PROTECTED]> wrote:
>
> On 10/24/07, Derrick Brashear <[EMAIL PROTECTED]> wrote:
> ...
> > perl scripts exist to do it and I think have been posted here in the
> past;
> > they may even deal with the "RO already exists" case.
> >
>
> It would be nice if there were a repository of publically available
> contrib stuff like that.
>
> > the interesting case is where the RW has unreleased changes and you want
> to
> > recreate the ROs as they are now. i don't know of distributed tools to
> do
> > this.
> >
>
> I hadn't really thought about people intentionally keeping their RWs &
> ROs out of sync w/each other.  I'm not clear why someone would want to
> do that -- could you elaborate?


using the RW as a the "beta" copy of data and releasing the changes after
testing them. i know of web backend services using AFS set up this way.

[OpenAFS] file timestamp difference

[Lars Richter]

Hi,

we have got a strange behavior with file timestamps and so with our
development environment.

Example:

A script creates 2 files "test1" and "test2" after each other. The
timestamps difference for these files is only shown in the nanoseconds.
At another client these timestamps has different nanoseconds and the
order of the file creation changed.

Client 1 ( creation host of these files )

ls -rtl --full-time *

-rw-r--r--  1 user_xyz users   25 2007-10-24 15:41:37.679114250 +0200 test1
-rw-r--r--  1 user_xyz users   25 2007-10-24 15:41:37.707112131 +0200 test2

Client 2

ls -rtl --full-time *

-rw-r--r--  1 user_xyz users   25 2007-10-24 15:41:37.447816288 +0200 test2
-rw-r--r--  1 user_xyz users   25 2007-10-24 15:41:37.781485632 +0200 test1

I also can reproduce this behavior.

We are using openafs 1.4.4 for server and clients running RHEL. 4 (
kernel 2.6.9-55)

Does anyone have any suggestions?

Regards,
Lars

-- 
Dipl.-Inf. Lars Richter
Pro Design Electronic GmbH
Europaplatz 5, 99091 Erfurt
phone: +49 361 55038-0
fax:   +49 361 78930-80
www.prodesigncad.de

Vertretungsberechtigte Geschäftsführer:
Helmut Mahr, Ulrike Angersbach, Stephan Röslmair, Heiko Mauersberger

Registergericht: Amtsgericht Traunstein
Registernummer: HRB 13 002 

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

Re: [OpenAFS] Automatic move of volumes

[Steve Brown]

On Wed, 24 Oct 2007, Steven Jenkins wrote:


I hadn't really thought about people intentionally keeping their RWs &
ROs out of sync w/each other.  I'm not clear why someone would want to
do that -- could you elaborate?


Test packages in the RO volume to make sure that stuff works as expected 
before releasing them into the wild?


Steve Brown
[EMAIL PROTECTED]
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Automatic move of volumes

[Kevin Hildebrand]

We've actually had this need a number of times...  Say for instance, 
you've installed a new version of software in volume X for testing 
purposes, or as Derrick suggests, using the volume as a web backend.


Then you run out of disk space, have a failing server, etc, and you need 
to move the RO replications - there's no easy way to do so without 
releasing the volume.


Kevin


On Wed, 24 Oct 2007, Steven Jenkins wrote:


On 10/24/07, Derrick Brashear <[EMAIL PROTECTED]> wrote:
...

perl scripts exist to do it and I think have been posted here in the past;
they may even deal with the "RO already exists" case.



It would be nice if there were a repository of publically available
contrib stuff like that.


the interesting case is where the RW has unreleased changes and you want to
recreate the ROs as they are now. i don't know of distributed tools to do
this.



I hadn't really thought about people intentionally keeping their RWs &
ROs out of sync w/each other.  I'm not clear why someone would want to
do that -- could you elaborate?

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


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

Re: [OpenAFS] Automatic move of volumes

[Brian Sebby]

On Wed, Oct 24, 2007 at 09:56:36AM -0400, Derrick Brashear wrote:
> On 10/24/07, Steven Jenkins <[EMAIL PROTECTED]> wrote:
> >
> > On 10/24/07, Derrick Brashear <[EMAIL PROTECTED]> wrote:
> > ...
> > > perl scripts exist to do it and I think have been posted here in the
> > past;
> > > they may even deal with the "RO already exists" case.
> > >
> >
> > It would be nice if there were a repository of publically available
> > contrib stuff like that.
> >
> > > the interesting case is where the RW has unreleased changes and you want
> > to
> > > recreate the ROs as they are now. i don't know of distributed tools to
> > do
> > > this.
> > >
> >
> > I hadn't really thought about people intentionally keeping their RWs &
> > ROs out of sync w/each other.  I'm not clear why someone would want to
> > do that -- could you elaborate?
> 
> 
> using the RW as a the "beta" copy of data and releasing the changes after
> testing them. i know of web backend services using AFS set up this way.

We do this with some of our web servers.  It works pretty well for letting
the developers preview data.

As for scripts, we have a series of scripts to move volumes from one
volume to another, which keep track of the RO and RW volumes, and handle
the RO already exists case.  Let me check with our admin who wrote them
to see if he's ok with me posting them to the list.  (I may also need to
make sure there's nothing specific to our cell in the scripts.)

Oh, and just another warning about directly moving files from the native
file system from /vicepa to /vicepb, not only would I consider that to be
dangerous to do in almost all cases, it also would only work if you're
using namei.  I know that most sites seem to be using namei these days,
but I'm sure there are still a number of inode servers still around.


Brian

-- 
Brian Sebby  ([EMAIL PROTECTED])  |  Unix and Operation Services
Phone: +1 630.252.9935|  Computing and Information Systems
Fax:   +1 630.252.4601|  Argonne National Laboratory
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Automatic move of volumes

[Frank Burkhardt]

Hi,

On Wed, Oct 24, 2007 at 09:31:55AM -0400, Steve Devine wrote:

[snip]

> >If you can afford some downtime, the most efficient way is to simply copy
> >the files from /vicepa to /vicepb on the server's filesystem:
> >
> > cd /vicepa;cp -a . /vicepb
> >
> >Make sure, /vicepb is empty before that.
> >
> >Warning: This worked for me lots of times but be carefull anyway.
> >
> >Regards,
> >
> >Frank
> >___
> >OpenAFS-info mailing list
> >OpenAFS-info@openafs.org
> >https://lists.openafs.org/mailman/listinfo/openafs-info
> >  

> Wow this seems like a recipe for disaster. Do you then sync the vldb or
> rename the partiton to vicepa

Sorry - I forgot. Of course the data partition name has to be the same after
the copy process. I tried it once using syncvldb and ended up having multiple
RW instances of the same volume on the server.

I mostly use cp for simple harddisk upgrades (on small machines). For
Multi-TB-servers vos move to a different server is the better choice mainly
because of the low uptime.

Regards,

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

Re: [OpenAFS] Automatic move of volumes

[Steven Jenkins]

It's great that you sent actual code.

However,

- there is no error checking in here, so there are potential issues (I
realize your script is generating the commands, not actually doing
them, but it still needs to address error checking -- if nothing else
stick a '|| exit 1' at the end of each command)
- handling RWs first will break RW/RO clones (if any exist) -- you
probably don't want to do that.
- the RO handling is not good -- what happens if the _only_ RO is on
the old server and the remsite happens?  Clients with existing
connections & callbacks are ok, but any new clients needing that data
now have no place to get it (even though the RO exists, the vldb
doesn't know about it, so clients will go against the RW instead).
Also, the actual data is left on the old fileserver ,which may (or may
not) cause a problem down the road.  Much better is to do a vos remove
(which updates both the vldb & file server) after the new clone has
been brought on line.
- in general, handling RW/RO pairs is best handled separately

I realize my 'general idea' email isn't complete enough to really
build a robust script.

Steven

On 10/24/07, chas williams - CONTRACTOR <[EMAIL PROTECTED]> wrote:
...
> $rw eq "RO" && $do_ro && do
> {
> $volume =~ s/\.readonly$//;
>
> printf "vos remsite %s %s %s\n", $from_server, 
> $from_partition, $volume;
> printf "vos addsite %s %s %s\n", $to_server, 
> $to_partition, $volume;
> printf "vos release %s -verbose -f\n", $volume;
> };
> }
>
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Automatic move of volumes

[Christopher D. Clausen]

Steven Jenkins <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Derrick Brashear <[EMAIL PROTECTED]> wrote:
>> perl scripts exist to do it and I think have been posted here in the
>> past; they may even deal with the "RO already exists" case.
>
> It would be nice if there were a repository of publically available
> contrib stuff like that.

I've offered to maintain such a thing if someone would be willing to 
grant AFS space in some part of a public cell.  I can't really host 
things at UIUC due to various campus network usage policies.

And actually, with AFS we can just create a mount point to a world 
readable volume in any public cell so that the contributor can maintain 
the most up to date version without involving someone in updating the 
content.

>> the interesting case is where the RW has unreleased changes and you
>> want to recreate the ROs as they are now. i don't know of
>> distributed tools to do this.
>
> I hadn't really thought about people intentionally keeping their RWs &
> ROs out of sync w/each other.  I'm not clear why someone would want to
> do that -- could you elaborate?

Yes, I do this.  This isn't easy to work around either as I'm pretty 
sure that vos dump and vos copy specifically prevent you from doing 
operations on an RO volume.

For instance I may pre-stage content for a website that is to be 
released next week at 10a on Monday.  I can then cron the release and 
have the data show up exactly at a specific time.  However, what usually 
happens is that some last minute change needs to be made to the current 
live website and its not easy to undo the new site, make the change, and 
then re-release.  I generally end up deleting (copying elsewhere first 
of course) the contents of the RW with rm, copying the RO, making 
changes and re-releasing.  And then putting back the pre-staged content.

Re: [OpenAFS] Automatic move of volumes

[Steven Jenkins]

On 10/24/07, Kevin Hildebrand <[EMAIL PROTECTED]> wrote:
>
> We've actually had this need a number of times...  Say for instance,
> you've installed a new version of software in volume X for testing
> purposes, or as Derrick suggests, using the volume as a web backend.
>
> Then you run out of disk space, have a failing server, etc, and you need
> to move the RO replications - there's no easy way to do so without
> releasing the volume.
>

I sort of understand this need, but I suggest that it's caused by poor
namespace management, and that the solution should be to improve that
rather than try to keep your RWs and ROs out of sync with each other.

There are several ways to have versionized trees: two are
- at the top (ie, different root volumes)
- in the middle of the filesystem space via symlinks (eg, have a
volume 'in the middle' of your hierarchy that lets you have 'dev' and
'prod' links) -- take a look at slides 15 & 16 of
http://www-conf.slac.stanford.edu/AFSBestPractices/Slides/MorganStanley.pdf
for one way to do that

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

Re: [OpenAFS] Automatic move of volumes

[Derrick Brashear]

On 10/24/07, Steven Jenkins <[EMAIL PROTECTED]> wrote:
>
> On 10/24/07, Kevin Hildebrand <[EMAIL PROTECTED]> wrote:
> >
> > We've actually had this need a number of times...  Say for instance,
> > you've installed a new version of software in volume X for testing
> > purposes, or as Derrick suggests, using the volume as a web backend.
> >
> > Then you run out of disk space, have a failing server, etc, and you need
> > to move the RO replications - there's no easy way to do so without
> > releasing the volume.
> >
>
> I sort of understand this need, but I suggest that it's caused by poor
> namespace management, and that the solution should be to improve that
> rather than try to keep your RWs and ROs out of sync with each other.


not everyone has VMS. it has nothing to do with namespace management.
nothing is as easy as "vos release" to copy data around.

Re: [OpenAFS] Automatic move of volumes

[Steven Jenkins]

On 10/24/07, anne salemme <[EMAIL PROTECTED]> wrote:
...
>- having a well-known, scheduled time for releasing certain volumes
> to ensure that files become available at an approximately-scheduled time
> (useful for website management, or for dealing with vos releases of very
> popular volumes typically near the top of an afs tree)
...

What's wrong with simply doing vos dump with the timestamp then?  And
having an name encoding rule that lets you determine the base RW
volume + timestamp.  For example,

'base' volume = mydata
'timestamp' volume is md.2007102402 (for the snapshot created via vos
dump mydata | vos restore at 2am)
you can then create RO clones of md.2007102401; RO's of 'mydata' aren't needed

cutting over from the md20071001 to md.2007102402 means an
intermediate volume  needs to exist that contains that change, but
it's contents can be programmatically determined based on the time.
You would  have 'dev' and 'prod' links in that volume that always
point to the hour-appropriate versions.

In general, I now understand some of what people are doing with the
RW/RO differences -- thanks for the explanations.  But it seems to me
that there are ways to deal with this -without- needing to keep RWs
and ROs intentionally out of sync.

It would be interesting, though, if vos addsite/release had a built-in
generational mechanism to mark ROs.  That could lead to other ways to
solve these problems.

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

Re: [OpenAFS] file timestamp difference

[Harald Barth]

> I also can reproduce this behavior.

Do all clients but the one you created the files on show identical file dates?

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

Re: [OpenAFS] Automatic move of volumes

[chas williams - CONTRACTOR]

In message <[EMAIL PROTECTED]>,"Steve
n Jenkins" writes:
>- there is no error checking in here, so there are potential issues (I
>realize your script is generating the commands, not actually doing
>them, but it still needs to address error checking -- if nothing else
>stick a '|| exit 1' at the end of each command)

you are free to add error checking.  i dont make misteaks so i dont
bother with error checking.

>- handling RWs first will break RW/RO clones (if any exist) -- you
>probably don't want to do that.

to be honest, i usually run the script in two passes.  doing the rw
first, and later run it with the -ro flag.

>- the RO handling is not good -- what happens if the _only_ RO is on
>the old server and the remsite happens?  Clients with existing

never considered that since we dont have a single readonly for any
volumes.  if i have a readonly, i have more than one site.

>- in general, handling RW/RO pairs is best handled separately

you could just change the order a bit.  it should zap the old readonly
to force the old users of the readonly to the new readonly to get them
off the sever asap.
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Automatic move of volumes

[Brandon S. Allbery KF8NH]

On Oct 24, 2007, at 9:54 , Steven Jenkins wrote:


On 10/24/07, Derrick Brashear <[EMAIL PROTECTED]> wrote:
...
the interesting case is where the RW has unreleased changes and  
you want to
recreate the ROs as they are now. i don't know of distributed  
tools to do

this.


I hadn't really thought about people intentionally keeping their RWs &
ROs out of sync w/each other.  I'm not clear why someone would want to
do that -- could you elaborate?


Version control on the cheap:  the R/O contains the publicly  
supported version, the R/W is the development/testing one.  When it's  
tested and ready for deployment, release the volume.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [OpenAFS] Automatic move of volumes

[Brandon S. Allbery KF8NH]

On Oct 24, 2007, at 10:15 , Steven Jenkins wrote:


- there is no error checking in here, so there are potential issues (I
realize your script is generating the commands, not actually doing
them, but it still needs to address error checking -- if nothing else
stick a '|| exit 1' at the end of each command)


"set -e" is your friend.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [OpenAFS] Automatic move of volumes

[Steve Simmons]

On Oct 24, 2007, at 10:22 AM, Christopher D. Clausen wrote:


Steven Jenkins <[EMAIL PROTECTED]> wrote:

On 10/24/07, Derrick Brashear <[EMAIL PROTECTED]> wrote:

perl scripts exist to do it and I think have been posted here in the
past; they may even deal with the "RO already exists" case.


It would be nice if there were a repository of publically available
contrib stuff like that.


I've offered to maintain such a thing if someone would be willing to
grant AFS space in some part of a public cell.  I can't really host
things at UIUC due to various campus network usage policies.

And actually, with AFS we can just create a mount point to a world
readable volume in any public cell so that the contributor can  
maintain

the most up to date version without involving someone in updating the
content.


I'd be happy to pitch in on this; there are a number of useful things  
out there when don't properly belong in the distribution but would be  
really nice to have in a common place. I'll check with our management  
to see if we can devote a volume.


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

Re: [OpenAFS] file timestamp difference

[Lars Richter]

Harald Barth schrieb:

  
I also can reproduce this behavior.

  
  
Do all clients but the one you created the files on show identical file dates?

Harald.
  


No.

All clients have different dates in the nanoseconds. All other values
are identical!

Lars


-- 
Dipl.-Inf. Lars Richter
Pro Design Electronic GmbH
Europaplatz 5, 99091 Erfurt
phone: +49 361 55038-25
fax:   +49 361 78930-80
www.prodesigncad.de

Vertretungsberechtigte Geschäftsführer:
Helmut Mahr, Ulrike Angersbach, Stephan Röslmair, Heiko Mauersberger

Registergericht: Amtsgericht Traunstein
Registernummer: HRB 13 002 



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

Re: [OpenAFS] Automatic move of volumes

[Brandon S. Allbery KF8NH]

On Oct 24, 2007, at 10:25 , Steven Jenkins wrote:


I sort of understand this need, but I suggest that it's caused by poor
namespace management, and that the solution should be to improve that
rather than try to keep your RWs and ROs out of sync with each other.


I think you're misunderstanding; the RO vs RW is only one component  
of such a scheme.  (Except in the case of simple htdocs staging.)


In our environment, software collections are arranged into releases;  
the vast majority of machines subscribe to the omega release, test  
machines may subscribe to alpha / beta / gamma / various custom/ 
testing release snapshots (and fall back to omega if those don't  
exist), development machines may subscribe to the RW volume instead  
of the RO to get the most up to date code instead of a snapshot.   
(Omega fallback still works here, as the RW omega release should  
always match the RO except (a) when it's a brand new package, so  
there is no RO (b) in the middle of an omega release update, which is  
typically very short because all you're doing is moving symlinks  
around.)


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [OpenAFS] Automatic move of volumes

[Brandon S. Allbery KF8NH]

On Oct 24, 2007, at 10:15 , Steven Jenkins wrote:


- the RO handling is not good -- what happens if the _only_ RO is on
the old server and the remsite happens?  Clients with existing


remsite is irrelevant:  it just informs the vlserver of where an R/O  
replica will be stored in the future, it has no impact whatsoever on  
what R/Os (if any) exist *now*.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [OpenAFS] file timestamp difference

[Brandon S. Allbery KF8NH]

On Oct 24, 2007, at 11:33 , Lars Richter wrote:


Harald Barth schrieb:

I also can reproduce this behavior.
Do all clients but the one you created the files on show identical  
file dates? Harald.


No.

All clients have different dates in the nanoseconds. All other  
values are identical!


I don't think AFS stores file timestamps with subsecond granularity.   
This might therefore be considered a client bug (perhaps it should  
just zero the nanoseconds).


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [OpenAFS] Automatic move of volumes

[Steven Jenkins]

On 10/24/07, Brandon S. Allbery KF8NH <[EMAIL PROTECTED]> wrote:
>
> On Oct 24, 2007, at 10:15 , Steven Jenkins wrote:
>
> > - the RO handling is not good -- what happens if the _only_ RO is on
> > the old server and the remsite happens?  Clients with existing
>
> remsite is irrelevant:  it just informs the vlserver of where an R/O
> replica will be stored in the future, it has no impact whatsoever on
> what R/Os (if any) exist *now*.
>
> --

remsite is _very_ relevant for clients that don't already know about
the RO that has been remsite'd -- when they ask the vlserver for the
volume, the vlserver will tell them that only the RW exists.

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

Re: [OpenAFS] Automatic move of volumes

[Christopher D. Clausen]

Steven Jenkins <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Brandon S. Allbery KF8NH <[EMAIL PROTECTED]> wrote:
>> On Oct 24, 2007, at 10:15 , Steven Jenkins wrote:
>>> - the RO handling is not good -- what happens if the _only_ RO is on
>>> the old server and the remsite happens?  Clients with existing
>>
>> remsite is irrelevant:  it just informs the vlserver of where an R/O
>> replica will be stored in the future, it has no impact whatsoever on
>> what R/Os (if any) exist *now*.
>
> remsite is _very_ relevant for clients that don't already know about
> the RO that has been remsite'd -- when they ask the vlserver for the
> volume, the vlserver will tell them that only the RW exists.

That sounds like a mis-use of the remsite command, although that is an 
interesting way to "hide" RO volumes.

I assume that a client that gets rebooted / crashes is going to start 
reading the RW when it comes back up though, right?

Re: [OpenAFS] Automatic move of volumes

[Steven Jenkins]

On 10/24/07, Derrick Brashear <[EMAIL PROTECTED]> wrote:
...
> not everyone has VMS.

*nod*, although it has been documented in public (at least some of the
pieces) for quite some time.  It seems CMU takes a similar approach,
and I suspect others out there have 'rolled their own'.  From the 'me
too's using vos release to handle versioning, it appears having a
general system more widely available would scratch a real itch.

> it has nothing to do with namespace management.
> nothing is as easy as "vos release" to copy data around.
>

It has _everything_ to do with namespace management.  In absence of
better tools, people are using vos release to do just that.  Note that
vos release isn't a bad tool; it's just being stretched beyond its
design because people need a way to do versioning of their namespaces.

I think it would be very useful if someone had the time/energy to
build a 'vms-lite' that people could adopt at their sites.  That seems
a more strategic direction than trying to extend RO capabilities.
That may be more of an openafs-devel or AFS3-standardization
discussion rather than openafs-info, though -- I don't know.

I also realize that building something like that is non-trivial.  If
people are interested in doing that, though, it seems a widely-needed
tool.

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

Re: [OpenAFS] Automatic move of volumes

[Lars Wilke]

* Steven Jenkins wrote:
> http://www-conf.slac.stanford.edu/AFSBestPractices/Slides/MorganStanley.pdf

Interesting, is there any more information available about the points
mentioned on the last 3 slides?

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

Re: [OpenAFS] file timestamp difference

[Derrick Brashear]

On 10/24/07, Harald Barth <[EMAIL PROTECTED]> wrote:
>
>
> > I also can reproduce this behavior.
>
> Do all clients but the one you created the files on show identical file
> dates?


i'll bet no.

Re: [OpenAFS] Automatic move of volumes

[Derrick Brashear]

On 10/24/07, Steven Jenkins <[EMAIL PROTECTED]> wrote:
>
> On 10/24/07, Derrick Brashear <[EMAIL PROTECTED]> wrote:
> ...
> > not everyone has VMS.
>
> *nod*, although it has been documented in public (at least some of the
> pieces) for quite some time.  It seems CMU takes a similar approach,
> and I suspect others out there have 'rolled their own'.  From the 'me
> too's using vos release to handle versioning, it appears having a
> general system more widely available would scratch a real itch.


where's Phil so I can beat him up some more?


> It has _everything_ to do with namespace management.  In absence of
> better tools, people are using vos release to do just that.  Note that
> vos release isn't a bad tool; it's just being stretched beyond its
> design because people need a way to do versioning of their namespaces.


you want to dump and restore volumes. that's ugly. it's not a namespace
issue; you want versioned volume clones.

Re: [OpenAFS] file timestamp difference

[Derrick Brashear]

On 10/24/07, Lars Richter <[EMAIL PROTECTED]> wrote:
>
>  Harald Barth schrieb:
>
>  I also can reproduce this behavior.
>
>
>  Do all clients but the one you created the files on show identical file 
> dates?
>
> Harald.
>
>
>
> No.
>
> All clients have different dates in the nanoseconds. All other values are
> identical!
>
> Lars
>
>
> --
> Dipl.-Inf. Lars Richter
> Pro Design Electronic GmbH
> Europaplatz 5, 99091 Erfurt
> phone: +49 361 55038-25
> fax:   +49 361 78930-80www.prodesigncad.de
>
> Vertretungsberechtigte Geschäftsführer:
> Helmut Mahr, Ulrike Angersbach, Stephan Röslmair, Heiko Mauersberger
>
> Registergericht: Amtsgericht Traunstein
> Registernummer: HRB 13 002
>
>  ___ OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Automatic move of volumes

[Steven Jenkins]

On 10/24/07, Derrick Brashear <[EMAIL PROTECTED]> wrote:
> ...
> where's Phil so I can beat him up some more?
>

Heh.  He's about 100 feet from where you got your most recent Mac.
But you'll have to get through Security unless you can lure him out by
offering him another tattoo or something..

And, for the record, my money is on Phil unless you bring a ranged
weapon or have the element of surprise.

> >
> > It has _everything_ to do with namespace management.  In absence of
> > better tools, people are using vos release to do just that.  Note that
> > vos release isn't a bad tool; it's just being stretched beyond its
> > design because people need a way to do versioning of their namespaces.
>
> you want to dump and restore volumes. that's ugly. it's not a namespace
> issue; you want versioned volume clones.
>

dump/restore is just a mechanism in lieu of a volume copy operation.
Versionized clones could be interesting in this context, but I would
prefer to stay away from that approach as it makes it harder to
recover & see changes in the base volume.  I think having one RW per
'generation' of ROs is reasonable.

With versionized clones, you would need to create a mechanism to have
potentially infinite numbers of clones, with arbitrary generation
identifiers (eg, some would be ok with '1', '2', ..., but some would
want 'alpha', 'beta', ..., or 'dev', 'prod', etc).  IMO, that's better
done outside of the volume itself.

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

Re: [OpenAFS] Automatic move of volumes

[Derrick Brashear]

On 10/24/07, Steven Jenkins <[EMAIL PROTECTED]> wrote:
>
> On 10/24/07, Derrick Brashear <[EMAIL PROTECTED]> wrote:
> > ...
> > where's Phil so I can beat him up some more?
> >
>
> Heh.  He's about 100 feet from where you got your most recent Mac.
> But you'll have to get through Security unless you can lure him out by
> offering him another tattoo or something..


he's on the 4th floor??

And, for the record, my money is on Phil unless you bring a ranged
> weapon or have the element of surprise.


well, if he's not reading


>
> dump/restore is just a mechanism in lieu of a volume copy operation.
> Versionized clones could be interesting in this context, but I would
> prefer to stay away from that approach as it makes it harder to
> recover & see changes in the base volume.  I think having one RW per
> 'generation' of ROs is reasonable.


this is all implementation decisions, and the ones you make that make me
wretch, well, i'm not running it so i don't matter.

Re: [OpenAFS] Automatic move of volumes

[Steven Jenkins]

On 10/24/07, Christopher D. Clausen <[EMAIL PROTECTED]> wrote:
...
> That sounds like a mis-use of the remsite command, although that is an
> interesting way to "hide" RO volumes.
>

Keep in mind the context of my comment -- I was looking at someone's
'move volumes en masse' code.  It's not how I would recommend handling
things.

> I assume that a client that gets rebooted / crashes is going to start
> reading the RW when it comes back up though, right?
>

Right.  Clients don't even have to reboot, though: vldb information
times out after 2 hrs, iirc.

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

Re: [OpenAFS] Automatic move of volumes

[Steven Jenkins]

On 10/24/07, Derrick Brashear <[EMAIL PROTECTED]> wrote:
> 
> > dump/restore is just a mechanism in lieu of a volume copy operation.
> > Versionized clones could be interesting in this context, but I would
> > prefer to stay away from that approach as it makes it harder to
> > recover & see changes in the base volume.  I think having one RW per
> > 'generation' of ROs is reasonable.
>
> this is all implementation decisions, and the ones you make that make me
> wretch, well, i'm not running it so i don't matter.
>

It's a community/gatekeeper/elder/afs3-standardization issue: if the
Road Ahead has generational clones, that's one thing.  If it doesn't,
then it would be helpful to know.

As for wretched decisions, I'm always open to hearing about better
ways to do things.

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

[OpenAFS] openafs.org downloads - Kerberos 5 or not?

[Jeff Blaine]

It's my assumption that none of the 1.5 or 1.4
builds of OpenAFS at openafs.org are built to use
Kerberos 5.

None of them say yes/no.

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

Re: [OpenAFS] file timestamp difference

[Jim Rees]

Here's an interesting nugget from LINUX/osi_vfsops.c:vattr2inode():

#if defined(AFS_LINUX26_ENV)
ip->i_atime.tv_sec = vp->va_atime.tv_sec;
ip->i_mtime.tv_sec = vp->va_mtime.tv_sec;
/* Set the mtime nanoseconds to the sysname generation number.
 * This convinces NFS clients that all directories have changed
 * any time the sysname list changes.
 */
ip->i_mtime.tv_nsec = afs_sysnamegen;
ip->i_ctime.tv_sec = vp->va_ctime.tv_sec;
#else

Seems like a bug to me.  This should be:

#if defined(AFS_LINUX26_ENV)
ip->i_atime = vp->va_atime;
ip->i_mtime = vp->va_mtime;
ip->i_ctime = vp->va_ctime;
#else

What do you get from "ls -rtlc --full-time *"?
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Using OpenAFS client with AFS Server 3.6

[Matthew1]

Hello,

I am working on a project which wants to utilize the OpenAFS client to
connect to an AFS server running version 3.6.  So far we have been unable to
find out if this will work ok.  Can anyone provide information on this, and
perhaps direct us to where we can see the compatability of OpenAFS with
other AFS products? 

Thanks,
Matt
-- 
View this message in context: 
http://www.nabble.com/Using-OpenAFS-client-with-AFS-Server-3.6-tf4683670.html#a13383657
Sent from the OpenAFS - General mailing list archive at Nabble.com.

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

Re: [OpenAFS] Automatic move of volumes

[anne salemme]

Steven Jenkins wrote:


  
I hadn't really thought about people intentionally keeping their RWs &

ROs out of sync w/each other.  I'm not clear why someone would want to
do that -- could you elaborate?

Steven
  

some examples:
  - putting in a new version of some software, and and trying it out 
before releasing it to the community
  - having a well-known, scheduled time for releasing certain volumes 
to ensure that files become available at an approximately-scheduled time 
(useful for website management, or for dealing with vos releases of very 
popular volumes typically near the top of an afs tree)


so...instead of doing random vos releases, in some sites you need to 
coordinate the vos releasing of volumes, schedule some, or do some only 
on request.

depends on the usage in the cell and what you need to accomplish.

anne

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

Re: [OpenAFS] Automatic move of volumes

[anne salemme]

and to add to what derrick says, 'vos release' when there are very large 
volumes involved and RO sites listed at geographically remote sites (ie, 
many thousands of miles away), or when there are many users involved 
(ie, all users of the cell) must be done in a purposeful, coordinated 
way. and just "always keeping the RWs and ROs in sync" simply cannot or 
should not be done.


anne



Derrick Brashear wrote:



On 10/24/07, *Steven Jenkins* <[EMAIL PROTECTED] 
> wrote:


On 10/24/07, Kevin Hildebrand <[EMAIL PROTECTED]
> wrote:
>
> We've actually had this need a number of times...  Say for instance,
> you've installed a new version of software in volume X for testing
> purposes, or as Derrick suggests, using the volume as a web backend.
>
> Then you run out of disk space, have a failing server, etc, and
you need
> to move the RO replications - there's no easy way to do so without
> releasing the volume.
>

I sort of understand this need, but I suggest that it's caused by poor
namespace management, and that the solution should be to improve that
rather than try to keep your RWs and ROs out of sync with each other. 



not everyone has VMS. it has nothing to do with namespace management. 
nothing is as easy as "vos release" to copy data around.





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

Re: [OpenAFS] file timestamp difference

[Derrick Brashear]

On 10/24/07, Jim Rees <[EMAIL PROTECTED]> wrote:
>
> Here's an interesting nugget from LINUX/osi_vfsops.c:vattr2inode():


in 1.5. look at 1.4

Re: [OpenAFS] openafs.org downloads - Kerberos 5 or not?

[Derrick Brashear]

On 10/24/07, Jeff Blaine <[EMAIL PROTECTED]> wrote:
>
> It's my assumption that none of the 1.5 or 1.4
> builds of OpenAFS at openafs.org are built to use
> Kerberos 5.


You'll have to be more specific about what you mean by that.

MacOS X certainly includes a krb5 aklog.

[OpenAFS] Re: openafs.org downloads - Kerberos 5 or not?

[Jeff Blaine]

"It's my assumption that none of the 1.5 or 1.4
 builds of OpenAFS at openafs.org are built to use
 Kerberos 5."

(More specific)

Well, building OpenAFS for Kerberos 5 support requires
headers, libraries, and certain configure options.

What, if any, releases on openafs.org were built this
way?

Or do we assume that if one is using Kerberos 5, always
build from source?
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Re: openafs.org downloads - Kerberos 5 or not?

[Derrick Brashear]

On 10/24/07, Jeff Blaine <[EMAIL PROTECTED]> wrote:
>
>  "It's my assumption that none of the 1.5 or 1.4
>   builds of OpenAFS at openafs.org are built to use
>   Kerberos 5."
>
> (More specific)
>
> Well, building OpenAFS for Kerberos 5 support requires
> headers, libraries, and certain configure options.


if the vendor provides krb5, we use it.  if not, it's hard to know which
kerberos a site will use, so we don't.

the simple test: does the vendor ship krb5?

every linux. macos. starting in 1.4.5, aix 5 and opensolaris.

Re: [OpenAFS] Re: openafs.org downloads - Kerberos 5 or not?

[Jeff Blaine]

Exactly what I needed to know.  Thanks.

if the vendor provides krb5, we use it.  if not, it's hard to know which 
kerberos a site will use, so we don't.


the simple test: does the vendor ship krb5?

every linux. macos. starting in 1.4.5, aix 5 and opensolaris.

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

Re: [OpenAFS] Using OpenAFS client with AFS Server 3.6

[Jeffrey Altman]

Matthew1 wrote:
> Hello,
> 
> I am working on a project which wants to utilize the OpenAFS client to
> connect to an AFS server running version 3.6.  So far we have been unable to
> find out if this will work ok.  Can anyone provide information on this, and
> perhaps direct us to where we can see the compatability of OpenAFS with
> other AFS products? 
> 
> Thanks,
> Matt

OpenAFS is compatible with IBM AFS 3.6 servers provided that you
restrict your client authentication to kaserver or Kerberos v4.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [OpenAFS] Automatic move of volumes

[John Hascall]

> Steven Jenkins wrote:
> > I hadn't really thought about people intentionally keeping their RWs &
> > ROs out of sync w/each other.  I'm not clear why someone would want to
> > do that -- could you elaborate?

> some examples:
>- putting in a new version of some software, and and trying it out 
> before releasing it to the community
>- having a well-known, scheduled time for releasing certain volumes 
> to ensure that files become available at an approximately-scheduled time 
> (useful for website management, or for dealing with vos releases of very 
> popular volumes typically near the top of an afs tree)

I'm with Steve on this one.  Deliberately depending on the
desynchronization of an RO copy from its RW for any significant
period of time seems like something that is going to bite you
in the ass someday.


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

Re: [OpenAFS] file timestamp difference

[Lars Richter]

Hi,

I test this patch tomorrow morning.

Lars

Jeffrey Altman schrieb:

Thread migrated from OpenAFS-Info to OpenAFS-Devel due to patch content.

Can someone please test these patches?

/afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/linux26-nsec-1_4-1.patch

/afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/linux26-nsec-1_5-1.patch

Thanks.

Jeffrey Altman

  

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

[OpenAFS] Password transition to krb5 - your methods?

[Jeff Blaine]

I realize there's not a conversion process to get AFS krb4
principal passwords into krb5-land.

What approaches have you all taken in order to make the
kaserver -> krb5 KDC transition as painless as possible
to users?

Thanks for any insight/tips.
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Server upgrade time; which is the right way?

[Mitch Collinsworth]

Greetings,

We're planning an upgrade to all of our AFS servers sometime soon.
We do this infrequently enough that it always makes us nervous.  :-)
As such we'd like to run a plan past the list to see if we're
overlooking something, either obvious or not so obvious...

All servers are currently running 1.2.13.  We're planning to upgrade
to 1.4.4.

The current draft plan goes like this:

1. Take down the database servers one at a time and upgrade the OS and
the OAFS binaries.

2. Take down the fileservers one at a time and upgrade either OS and
OAFS or just OAFS as needed.

There seems to be a conflict of opinions here on whether a rolling
upgrade like this is either a) a non-issue, people do it all the time;
or b) a huge mistake that will inflict serious pain and sleepless
nights because everyone knows we should be taking everything down at
once for a major version upgrade like this.

Comments?

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

Re: [OpenAFS] Automatic move of volumes

[Brandon S. Allbery KF8NH]

On Oct 24, 2007, at 12:21 , Steven Jenkins wrote:


I think it would be very useful if someone had the time/energy to
build a 'vms-lite' that people could adopt at their sites.  That seems
a more strategic direction than trying to extend RO capabilities.


I have to admit I've thought about what would be involved in  
developing a ClearCase-like setup based on AFS (CC uses NFS with  
snapshots to implement "views"... and seems to inherit NFS's general  
lack of structure).  At minimum it would require rather more complex  
relationships between R/O versions than AFS currently has (or has the  
ability to support without overhauling volume headers at minimum).


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [OpenAFS] Server upgrade time; which is the right way?

[Jeffrey Altman]

Mitch Collinsworth wrote:
> 
> Greetings,
> 
> We're planning an upgrade to all of our AFS servers sometime soon.
> We do this infrequently enough that it always makes us nervous.  :-)
> As such we'd like to run a plan past the list to see if we're
> overlooking something, either obvious or not so obvious...
> 
> All servers are currently running 1.2.13.  We're planning to upgrade
> to 1.4.4.
> 
> The current draft plan goes like this:
> 
> 1. Take down the database servers one at a time and upgrade the OS and
> the OAFS binaries.
> 
> 2. Take down the fileservers one at a time and upgrade either OS and
> OAFS or just OAFS as needed.
> 
> There seems to be a conflict of opinions here on whether a rolling
> upgrade like this is either a) a non-issue, people do it all the time;
> or b) a huge mistake that will inflict serious pain and sleepless
> nights because everyone knows we should be taking everything down at
> once for a major version upgrade like this.

My personal belief is that services that share databases should have all
of the servers upgraded simultaneously.

File servers on the other hand can be migrated one at a time.  Add a new
file server to the cell, migrate volumes, when an old file server is
empty it can be decommissioned.

Others with more operational experience may have other views.

Jeffrey Altman


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [OpenAFS] Password transition to krb5 - your methods?

[Alf Wachsmann]

On Wed, 24 Oct 2007, Jeff Blaine wrote:

I realize there's not a conversion process to get AFS krb4
principal passwords into krb5-land.

What approaches have you all taken in order to make the
kaserver -> krb5 KDC transition as painless as possible
to users?


Jeff,

Heimdal has an easy way of importing a kaserver DB into its K5 KDC.
It can also read MIT K5 KDC DB dumps.

Not sure whether MIT K5 can do any of this.

-- Alf.

---
  Alf Wachsmann   | e-mail: [EMAIL PROTECTED]
  SLAC - Scientific Computing | Phone:  +1-650-926-4802
  2575 Sand Hill Road, M/S 97 | FAX:+1-650-926-3329
  Menlo Park, CA 94025, USA   | Office: Bldg. 50/323
---
http://www.slac.stanford.edu/~alfw (PGP)
---
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Automatic move of volumes

[Mike Polek]

I wrote a couple perl script some time ago to move
volumes between servers. It uses the AFS::VOS
perl interface, and it handles RO volumes. It doesn't
take into account purposely unreleased volumes, as
we don't really do that here. (We use the backup volume
at times for previews and such, but we try to keep
the RW and RO in sync at all times.) I don't think it
handles the issue where there is already a RO on the
target either. Our cell is organized so that wouldn't
really happen.  It uses a support
script that attempts to distribute the volumes evenly
between the destination servers/partitions.

If you would like a copy, contact me off list. Or if
there is sufficient interest, I can publish to the
list. I don't know how many people besides us use
the perl interface.

Thanks,
Mike


chas williams - CONTRACTOR wrote:

In message <[EMAIL PROTECTED]>,Jacob Volstrup writes:


For quite some time I've been searching for something to help me move
some volumes from a constantly failing /vicepa raid to my new /vicepb.
The reason for not doing this manually is partly that I'm lazy and
Further, I would like to have this fully automated if I would like to
move them back in the future (perhaps when the disks for /vicepa are
replaced).



i wrote this a while back when i was migrating file servers.  it takes
4 arguments,,
and optionally the -ro flag to also move the read-only's.

it generates a list of commands that you typically run with /bin/sh (or
you could just pipe to sh), so if you want to revert your actions at a
later save this as a script and do a little sed magic on it to reverse
the actions.

it doesnt deal with the duplicate readonly problems.  that wouldnt be
hard to add or you could just live with the errors.



--
Mike Polek
Pictage, Inc.
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Password transition to krb5 - your methods?

[Steve Devine]

Jeff Blaine wrote:

I realize there's not a conversion process to get AFS krb4
principal passwords into krb5-land.

What approaches have you all taken in order to make the
kaserver -> krb5 KDC transition as painless as possible
to users?

Thanks for any insight/tips.
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

This is not so.
From my notes :
***
afs2k5db /usr/afs/db/kaserver.DB0 >all.out
then edit the all.out file:
Remove line for AuthServer , krbtgt, and afs
Be sure and leave in first line ( kdb5_util load_dump version 4)
Then load em all in.
kdb5_util load -update all.out
(Leave verbose switch out it will just slow you down.)


--
Steve Devine
Network Storage and Printing
Academic Computing & Network Services
Michigan State University

506 Computer Center
East Lansing, MI 48824-1042
1-517-432-7327

Baseball is ninety percent mental; the other half is physical.
- Yogi Berra 


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