From shadow@gmail.com  Fri Jun  1 03:58:03 2018
From: shadow@gmail.com (Daria Phoebe Brashear)
Date: Thu, 31 May 2018 22:58:03 -0400
Subject: [OpenAFS] Remarks: aklog+pagsh SL7 x64
In-Reply-To: <61D7B301-E432-4980-A5B5-93E306ECC478@desy.de>
References: <b9bc00fc-d3df-93d1-c8fc-3c5825ecd5e0@t-online.de>
 <6c949633-942d-6d42-4d12-8124c9fb17bd@t-online.de> <CACxoJuWnoFQ9w03XgxfFs9bqT6gaBVAtoT9FP5VXpU=S_fHGDA@mail.gmail.com>
 <61D7B301-E432-4980-A5B5-93E306ECC478@desy.de>
Message-ID: <CAMHoRJi2_j3f5AneeMpXL5ctEgtB-iWbNO4iros5YOyPonsnWA@mail.gmail.com>

--000000000000b6f130056d8bc00a
Content-Type: text/plain; charset="UTF-8"

On Thu, May 31, 2018 at 11:39 AM, Stephan Wiesand <stephan.wiesand@desy.de>
wrote:

> Indeed. The SL packaging renames pagsh to pagsh.openafs  to avoid clashes
> with other software like heimdal providing it.
>
> Regarding aklog, I thought that -setpag was broken on Linux many years ago.
>
>
It was.

The ability to rewrite a parent's state (which is what aklog -setpag needs)
doesn't work


-- 
Daria Phoebe Brashear
AuriStor, Inc
dariaphoebe.com

--000000000000b6f130056d8bc00a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, May 31, 2018 at 11:39 AM, Stephan Wiesand <span dir=3D"ltr">&lt;<a =
href=3D"mailto:stephan.wiesand@desy.de" target=3D"_blank">stephan.wiesand@d=
esy.de</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Indeed. The =
SL packaging renames pagsh to pagsh.openafs=C2=A0 to avoid clashes with oth=
er software like heimdal providing it.<br>
<br>
Regarding aklog, I thought that -setpag was broken on Linux many years ago.=
<br>
<br></blockquote><div><br></div><div>It was.=C2=A0 <br></div></div><div cla=
ss=3D"gmail_quote"><br></div><div class=3D"gmail_quote">The ability to rewr=
ite a parent&#39;s state (which is what aklog -setpag needs) doesn&#39;t wo=
rk<br></div><br clear=3D"all"><br>-- <br><div class=3D"gmail_signature" dat=
a-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div=
><div dir=3D"ltr">Daria Phoebe Brashear<br></div><div>AuriStor, Inc<br></di=
v><div><a href=3D"http://dariaphoebe.com" target=3D"_blank">dariaphoebe.com=
</a><br><br></div></div></div></div></div></div>
</div></div>

--000000000000b6f130056d8bc00a--

From Rainer.Laatsch@t-online.de  Sat Jun  2 23:14:23 2018
From: Rainer.Laatsch@t-online.de (r.laatsch)
Date: Sun, 3 Jun 2018 00:14:23 +0200
Subject: [OpenAFS] Remarks: aklog+pagsh SL7 x64
In-Reply-To: <CAMHoRJi2_j3f5AneeMpXL5ctEgtB-iWbNO4iros5YOyPonsnWA@mail.gmail.com>
References: <b9bc00fc-d3df-93d1-c8fc-3c5825ecd5e0@t-online.de>
 <6c949633-942d-6d42-4d12-8124c9fb17bd@t-online.de>
 <CACxoJuWnoFQ9w03XgxfFs9bqT6gaBVAtoT9FP5VXpU=S_fHGDA@mail.gmail.com>
 <61D7B301-E432-4980-A5B5-93E306ECC478@desy.de>
 <CAMHoRJi2_j3f5AneeMpXL5ctEgtB-iWbNO4iros5YOyPonsnWA@mail.gmail.com>
Message-ID: <7ae10c01-7e75-05c1-149c-a9bf154e78ad@t-online.de>

This is a multi-part message in MIME format.
--------------E983AA620338E76CEF8876CC
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

The PAG's now are now done via keyctl . The configure of at least

openafss-1.6.21.1 checks this , look for KEYCTL_SESSION_TO_PARENT around 
line 23282

But the generated Makefile in src/aklog does not include -lkeyutils , 
there i change to

    AKLIBS = -L/opt/krb5/lib -lkrb5 -lk5crypto -lcom_err -lkrb5support 
-lkeyutils -lcrypt -lresolv

aklog -setpag then gets a token with a PAG (check with: keyctl show )

Best regards

Rainer




On 06/01/18 04:58, Daria Phoebe Brashear wrote:
>
> On Thu, May 31, 2018 at 11:39 AM, Stephan Wiesand 
> <stephan.wiesand@desy.de <mailto:stephan.wiesand@desy.de>> wrote:
>
>     Indeed. The SL packaging renames pagsh to pagsh.openafs  to avoid
>     clashes with other software like heimdal providing it.
>
>     Regarding aklog, I thought that -setpag was broken on Linux many
>     years ago.
>
>
> It was.
>
> The ability to rewrite a parent's state (which is what aklog -setpag 
> needs) doesn't work
>
>
> -- 
> Daria Phoebe Brashear
> AuriStor, Inc
> dariaphoebe.com <http://dariaphoebe.com>
>


--------------E983AA620338E76CEF8876CC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>The PAG's now are now done via keyctl . The configure of at least</p>
    <p>openafss-1.6.21.1 checks this , look for KEYCTL_SESSION_TO_PARENT
      around line 23282</p>
    <p>But the generated Makefile in src/aklog does not include
      -lkeyutils , there i change to</p>
    <p>   AKLIBS = -L/opt/krb5/lib -lkrb5 -lk5crypto -lcom_err
      -lkrb5support -lkeyutils -lcrypt -lresolv</p>
    <p>aklog -setpag then gets a token with a PAG (check with: keyctl
      show )</p>
    <p>Best regards</p>
    <p>Rainer</p>
    <p><br>
    </p>
    <p>  <br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 06/01/18 04:58, Daria Phoebe
      Brashear wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMHoRJi2_j3f5AneeMpXL5ctEgtB-iWbNO4iros5YOyPonsnWA@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Thu, May 31, 2018 at 11:39 AM,
            Stephan Wiesand <span dir="ltr">&lt;<a
                href="mailto:stephan.wiesand@desy.de" target="_blank"
                moz-do-not-send="true">stephan.wiesand@desy.de</a>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">Indeed.
              The SL packaging renames pagsh to pagsh.openafs  to avoid
              clashes with other software like heimdal providing it.<br>
              <br>
              Regarding aklog, I thought that -setpag was broken on
              Linux many years ago.<br>
              <br>
            </blockquote>
            <div><br>
            </div>
            <div>It was.  <br>
            </div>
          </div>
          <div class="gmail_quote"><br>
          </div>
          <div class="gmail_quote">The ability to rewrite a parent's
            state (which is what aklog -setpag needs) doesn't work<br>
          </div>
          <br clear="all">
          <br>
          -- <br>
          <div class="gmail_signature" data-smartmail="gmail_signature">
            <div dir="ltr">
              <div>
                <div dir="ltr">
                  <div>
                    <div dir="ltr">Daria Phoebe Brashear<br>
                    </div>
                    <div>AuriStor, Inc<br>
                    </div>
                    <div><a href="http://dariaphoebe.com"
                        target="_blank" moz-do-not-send="true">dariaphoebe.com</a><br>
                      <br>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------E983AA620338E76CEF8876CC--

From jon@csail.mit.edu  Mon Jun  4 18:11:40 2018
From: jon@csail.mit.edu (Jonathan Proulx)
Date: Mon, 4 Jun 2018 13:11:40 -0400
Subject: [OpenAFS] Trouble deleting server (vos changeaddr -remove)
Message-ID: <20180604171140.GE11511@csail.mit.edu>

Hi All,

I'm trying to decomission a fileserver but my last step of removign
it:

vos changeaddr -old 128.30.2.196 -remove -localauth -verbose

fails with:
Could not remove server 128.30.2.196 from the VLDB
VLDB: volume Id exists in the vldb

but I see no volumes in vldb or locally

vos listvldb -s 128.30.2.196 -localauth
VLDB entries for server 128.30.2.196 

Total entries: 0

vos listvol -s 128.30.2.196 -localauth
Total number of volumes on server 128.30.2.196 partition /vicepa: 0 

Total volumes onLine 0 ; Total volumes offLine 0 ; Total busy 0

The only reference I could find serching hte mailing list is to soeone
tryng to remove one (incorrect) IP from a (notreally) multihomed host.

but in my case `vos listaddrs -printuuid` only shows the one address
for the given uuid.

How do I make htis go away? it's always worked in the past :)

The server was behaving 'badly' prior to going out of service causing
it do periodically requiring all volumes to be salvaged.  This
probably isn't relevant, but there are definitely ghosts in this
machine & seems they've crawled into the vldb some how?

Thanks.
-Jon
-- 

From jan.iven@cern.ch  Mon Jun  4 21:17:59 2018
From: jan.iven@cern.ch (Jan Iven)
Date: Mon, 4 Jun 2018 22:17:59 +0200
Subject: [OpenAFS] Trouble deleting server (vos changeaddr -remove)
In-Reply-To: <20180604171140.GE11511@csail.mit.edu>
References: <20180604171140.GE11511@csail.mit.edu>
Message-ID: <43d14c6d-093c-99ca-4ffa-ee4f0d432fde@cern.ch>

Suggest to try "vldb_check" (on a copy of the vldb.DB0 file) or
https://github.com/openafs-contrib/afs-tools/blob/master/admin/afs-vol-check 
to figure out what is wrong.

Cheers
jan

From jaltman@auristor.com  Mon Jun  4 21:58:21 2018
From: jaltman@auristor.com (Jeffrey Altman)
Date: Mon, 4 Jun 2018 16:58:21 -0400
Subject: [OpenAFS] Trouble deleting server (vos changeaddr -remove)
In-Reply-To: <20180604171140.GE11511@csail.mit.edu>
References: <20180604171140.GE11511@csail.mit.edu>
Message-ID: <f6cf0b91-2594-65e7-83aa-44cc16b51626@auristor.com>

This is a cryptographically signed message in MIME format.

--------------ms070804050201020508030307
Content-Type: multipart/mixed;
 boundary="------------B57F0951F508A665526192BE"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------B57F0951F508A665526192BE
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 6/4/2018 1:11 PM, Jonathan Proulx wrote:
> Hi All,
>=20
> I'm trying to decomission a fileserver but my last step of removign
> it:
>=20
> vos changeaddr -old 128.30.2.196 -remove -localauth -verbose
>=20
> fails with:
> Could not remove server 128.30.2.196 from the VLDB
> VLDB: volume Id exists in the vldb

The volumes in question is

  csail-debian

vos remsite kursk.csail.mit.edu a csail-debian

Then you will be able to remove the fileserver.

BTW, the csail.mit.edu VLDB contains an entry for:

  UUID: None
  127.0.1.1

You should remove that one as well.

Jeffrey Altman




--------------B57F0951F508A665526192BE
Content-Type: text/x-vcard; charset=utf-8;
 name="jaltman.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="jaltman.vcf"

begin:vcard
fn:Jeffrey Altman
n:Altman;Jeffrey
org:AuriStor, Inc.
adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St=
ates
email;internet:jaltman@auristor.com
title:Founder and CEO
tel;work:+1-212-769-9018
note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman=
=3D0D=3D0A=3D
	Skype: jeffrey.e.altman=3D0D=3D0A=3D
=09
url:https://www.auristor.com/
version:2.1
end:vcard


--------------B57F0951F508A665526192BE--

--------------ms070804050201020508030307
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DIIwggXpMIIE0aADAgECAhBAAV7gPRitcrlGsJTzkwjvMA0GCSqGSIb3DQEBCwUAMDoxCzAJ
BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy
MB4XDTE3MTAwMzAzMTczM1oXDTE4MTEwMzAzMTczM1owgYUxLTArBgNVBAsMJFZlcmlmaWVk
IEVtYWlsOiBqYWx0bWFuQGF1cmlzdG9yLmNvbTEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBh
dXJpc3Rvci5jb20xLzAtBgoJkiaJk/IsZAEBEx9BMDE0MjdFMDAwMDAxNUVFMDNEMTg3QTAw
MDA0QUE1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqqJC89ZA1DSS7t/Ug8Dd
BQv5nBDumInWtFvHwVCORitVCvlkX4SfqKpERATq0eHOSc0zEz1PUjhAT8lgbNj8Bs92pL9t
DW/VHHpq11w06rCEmZJNxgErAIvMpRuAhGrzvBpQBLj8nDArHWw+5nRn/KnK7ZO81LEEj4TG
w0PEKGSa0aFA+JdRTJ6BZSDP2o/8AHx+Bw4JgW8VppAe4IuY/F+JoYtyQDL+fm1YMnFMtf1A
6IvlGXD7gMksPRbVIfD+QpHZbQvNXZAVVDaCWZuWQq46Vl4lSlkmW9yMlGddvFGl2zSMK7ny
f0kbWJLw9lZxXDegY0/ciJPACPsyBwuyLwIDAQABo4ICnTCCApkwDgYDVR0PAQH/BAQDAgWg
MIGEBggrBgEFBQcBAQR4MHYwMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJjaWFsLm9jc3Au
aWRlbnRydXN0LmNvbTBCBggrBgEFBQcwAoY2aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0
LmNvbS9jZXJ0cy90cnVzdGlkY2FhMTIucDdjMB8GA1UdIwQYMBaAFKRz2u9pNYp1zKAZewgy
+GuJ5ELsMAkGA1UdEwQCMAAwggEsBgNVHSAEggEjMIIBHzCCARsGC2CGSAGG+S8ABgsBMIIB
CjBKBggrBgEFBQcCARY+aHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0
ZXMvcG9saWN5L3RzL2luZGV4Lmh0bWwwgbsGCCsGAQUFBwICMIGuGoGrVGhpcyBUcnVzdElE
IENlcnRpZmljYXRlIGhhcyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdpdGggCklkZW5U
cnVzdCdzIFRydXN0SUQgQ2VydGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2Vj
dXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEUG
A1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL3Ry
dXN0aWRjYWExMi5jcmwwHwYDVR0RBBgwFoEUamFsdG1hbkBhdXJpc3Rvci5jb20wHQYDVR0O
BBYEFNefZrPaqPUvaS6V6kAmHDwFhoDiMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDANBgkqhkiG9w0BAQsFAAOCAQEAKlssrfOJ5+WwHyhFSeSsioN0qpg2QDX/uvodF38JbquO
1U0my0j3Cc/bwk48++bjzp0Fvk/Kkcmss5/6zzJMjr9rf12QCQfKkbO9nMm8Bg6IP3pYgk0W
/F1h3ZQF3OgBn3zZoOd3f1a6dF6z12MqKA/2g5GKrQFxkdzTGrNw6ISE9uY8ysvc3i2N2kas
HNi5Etk7StZ1jvFX5sQMIeNdlF+z+BU/AyT7NoBS4gCH+ggF+DG7fAYywvy42Lfu8p6kopKT
5JZpYce1cNjnOaDhzhgeR+oXxoDbekF27JinXHQSKjBxhujcZu5leAkpctFpZxnIKZJZUBiu
31Nm7xYaijCCBpEwggR5oAMCAQICEQD53lZ/yU0Md3D5YBtS2hU7MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVz
dCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAeFw0xNTAyMTgyMjI1MTlaFw0yMzAyMTgyMjI1MTla
MDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQg
Q0EgQTEyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0ZFNPM8KJzSSrkvpmtQl
a3ksT+fq1s9c+Ea3YSC/umUkygSm9UkkOoaoNjKZoCx3wef1kwC4pQQV2XHk+AKR+7uMvnOC
Iw2cAVUP0/Kuy4X6miqaXGGVDTqwVjaFuFCRVVDTQoI2BTMpwFQi+O/TjD5+E0+TAZbkzsB7
krk4YUbA6hFyT0YboxRUq9M2QHDb+80w53b1UZVO1HS2Mfk9LnINeyzjxiXU/iENK07YvjBO
xbY/ftAYPbv/9cY3wrpqZYHoXZc6B9/8+aVCNA45FP3k+YuTDC+ZrmePQBLQJWnyS/QrZEdX
saieWUqkUMxPQKTExArCiP61YRYlOIMpKwIDAQABo4ICgDCCAnwwgYkGCCsGAQUFBwEBBH0w
ezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEcG
CCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL3Jvb3RzL2NvbW1l
cmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C5yZUyI42djAPBgNV
HRMBAf8EBTADAQH/MIIBIAYDVR0gBIIBFzCCARMwggEPBgRVHSAAMIIBBTCCAQEGCCsGAQUF
BwICMIH0MEUWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3Bv
bGljeS90cy9pbmRleC5odG1sMAMCAQEagapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFz
IGJlZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENl
cnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29t
L2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBKBgNVHR8EQzBBMD+gPaA7hjlo
dHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC9jb21tZXJjaWFscm9vdGNhMS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBhjAdBgNV
HQ4EFgQUpHPa72k1inXMoBl7CDL4a4nkQuwwDQYJKoZIhvcNAQELBQADggIBAA3hgq7S+/Tr
Yxl+D7ExI1Rdgq8fC9kiT7ofWlSaK/IMjgjoDfBbPGWvzdkmbSgYgXo8GxuAon9+HLIjNv68
BgUmbIjwj/SYaVz6chA25XZdjxzKk+hUkqCmfOn/twQJeRfxHg3I+0Sfwp5xs10YF0Robhrs
CRne6OUmh9mph0fE3b21k90OVnx9Hfr+YAV4ISrTA6045zQTKGzb370whliPLFo+hNL6XzEt
y5hfdFaWKtHIfpE994CLmTJI4SEbWq40d7TpAjCmKCPIVPq/+9GqggGvtakM5K3VXNc9VtKP
U9xYGCTDIYoeVBQ65JsdsdyM4PzDzAdINsv4vaF7yE03nh2jLV7XAkcqad9vS4EB4hKjFFsm
cwxa+ACUfkVWtBaWBqN4f/o1thsFJHEAu4Q6oRB6mYkzqrPigPazF2rgYw3lp0B1gSzCRj+j
RtErIVdMPeZ2p5Fdx7SNhBtabuhqmpJkFxwW9SBg6sHvy0HpzVvEiBpApFKG1ZHXMwzQl+pR
8P27wWDsblJU7Qgb8ZzGRK9l5GOFhxtN+oXZ4CCmunLMtaZ2vSai7du/VKrg64GGZNAKerEB
evjJVNFgeSnmUK9GB4kCZ7U5NWlU+2H87scntW4Q/0Y6vqQJcJeaMHg/dQnahTQ2p+hB1xJJ
K32GWIAucTFMSOKLbQHadIOiMYIDFDCCAxACAQEwTjA6MQswCQYDVQQGEwJVUzESMBAGA1UE
ChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMgIQQAFe4D0YrXK5RrCU85MI
7zANBglghkgBZQMEAgEFAKCCAZcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTgwNjA0MjA1ODIxWjAvBgkqhkiG9w0BCQQxIgQgDja6YkHL6BKsUStpgmcW
8CC9pMHxXdYIhMuLzmiSxzkwXQYJKwYBBAGCNxAEMVAwTjA6MQswCQYDVQQGEwJVUzESMBAG
A1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMgIQQAFe4D0YrXK5RrCU
85MI7zBfBgsqhkiG9w0BCRACCzFQoE4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5U
cnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABXuA9GK1yuUawlPOTCO8wbAYJKoZI
hvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq
hkiG9w0BAQEFAASCAQA9yqluo227qrMyQMjaW43Wm6T98nsqS8IrFsxWCutuV3FaAYY6lGps
a01im7YoP5aoZ0EYHs65/FntyMalphos9AEpExzA5GAAp0bKk6ktu4U23XEqkhK6WElnivqK
rgq419BV7ZQsLxCv60l4ynBw/ohv4rIRPxImO0j3CWThgFa85K9jTpMoqMh81pBVLjU2i30u
BrT/uxSTmzljqMSPhjumgsa+rKAGmCnGpyC+fGkARKTw7K/lulXqusFdacAECvN6BD13+kpY
xhRx8SDsFjK9uk1uhQHajZcKTXa5dbuqv9XWvw8iuPu2qCPaaJBVF8W/H/+xxpRvsu/TVviZ
AAAAAAAA
--------------ms070804050201020508030307--


From jon@csail.mit.edu  Mon Jun  4 22:00:44 2018
From: jon@csail.mit.edu (Jonathan Proulx)
Date: Mon, 4 Jun 2018 17:00:44 -0400
Subject: [OpenAFS] Trouble deleting server (vos changeaddr -remove)
In-Reply-To: <43d14c6d-093c-99ca-4ffa-ee4f0d432fde@cern.ch>
References: <20180604171140.GE11511@csail.mit.edu>
 <43d14c6d-093c-99ca-4ffa-ee4f0d432fde@cern.ch>
Message-ID: <20180604210044.GG11511@csail.mit.edu>

On Mon, Jun 04, 2018 at 10:17:59PM +0200, Jan Iven wrote:
:Suggest to try "vldb_check" (on a copy of the vldb.DB0 file) or
:https://github.com/openafs-contrib/afs-tools/blob/master/admin/afs-vol-check
:to figure out what is wrong.

Interesting tool I did not know about.  Found an unreleased
volume and three more ex-servers I forgot to prune and a few "WARNING:
addsite needed"  but nothing about that IP or it's UUID.

Thanks,
-Jon

From jon@csail.mit.edu  Mon Jun  4 22:05:41 2018
From: jon@csail.mit.edu (Jonathan Proulx)
Date: Mon, 4 Jun 2018 17:05:41 -0400
Subject: [OpenAFS] Trouble deleting server (vos changeaddr -remove)
In-Reply-To: <f6cf0b91-2594-65e7-83aa-44cc16b51626@auristor.com>
References: <20180604171140.GE11511@csail.mit.edu>
 <f6cf0b91-2594-65e7-83aa-44cc16b51626@auristor.com>
Message-ID: <20180604210541.GH11511@csail.mit.edu>

On Mon, Jun 04, 2018 at 04:58:21PM -0400, Jeffrey Altman wrote:

:The volumes in question is
:
:  csail-debian
:
:vos remsite kursk.csail.mit.edu a csail-debian
:
:Then you will be able to remove the fileserver.
:
:BTW, the csail.mit.edu VLDB contains an entry for:
:
:  UUID: None
:  127.0.1.1
:
:You should remove that one as well.

That is all true.

curious how I should have looked for this since I wasn't seeing it.

still didn't see 127.0.1.1 in `vos listaddrs -printuuid` but it did
remove so clearly was there

Thanks,
-Jon

:Jeffrey Altman
:
:
:

:begin:vcard
:fn:Jeffrey Altman
:n:Altman;Jeffrey
:org:AuriStor, Inc.
:adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United States
:email;internet:jaltman@auristor.com
:title:Founder and CEO
:tel;work:+1-212-769-9018
:note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman=0D=0A=
:	Skype: jeffrey.e.altman=0D=0A=
:	
:url:https://www.auristor.com/
:version:2.1
:end:vcard
:




-- 

From jaltman@auristor.com  Mon Jun  4 22:22:32 2018
From: jaltman@auristor.com (Jeffrey Altman)
Date: Mon, 4 Jun 2018 17:22:32 -0400
Subject: [OpenAFS] Trouble deleting server (vos changeaddr -remove)
In-Reply-To: <20180604210541.GH11511@csail.mit.edu>
References: <20180604171140.GE11511@csail.mit.edu>
 <f6cf0b91-2594-65e7-83aa-44cc16b51626@auristor.com>
 <20180604210541.GH11511@csail.mit.edu>
Message-ID: <588ed325-c047-0de3-2a44-d4f725477653@auristor.com>

This is a cryptographically signed message in MIME format.

--------------ms030902090506070000050907
Content-Type: multipart/mixed;
 boundary="------------BCB8DFC3B48E77BCE79BC652"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------BCB8DFC3B48E77BCE79BC652
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 6/4/2018 5:05 PM, Jonathan Proulx wrote:
> That is all true.
>=20
> curious how I should have looked for this since I wasn't seeing it.
>
> still didn't see 127.0.1.1 in `vos listaddrs -printuuid` but it did
> remove so clearly was there

I used AuriStorFS vos tooling:

  vos eachvol
  vos listfs

I can confirm that both fileservers have now been removed from the
location database (VLDB).

Jeffrey Altman

--------------BCB8DFC3B48E77BCE79BC652
Content-Type: text/x-vcard; charset=utf-8;
 name="jaltman.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="jaltman.vcf"

begin:vcard
fn:Jeffrey Altman
n:Altman;Jeffrey
org:AuriStor, Inc.
adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St=
ates
email;internet:jaltman@auristor.com
title:Founder and CEO
tel;work:+1-212-769-9018
note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman=
=3D0D=3D0A=3D
	Skype: jeffrey.e.altman=3D0D=3D0A=3D
=09
url:https://www.auristor.com/
version:2.1
end:vcard


--------------BCB8DFC3B48E77BCE79BC652--

--------------ms030902090506070000050907
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DIIwggXpMIIE0aADAgECAhBAAV7gPRitcrlGsJTzkwjvMA0GCSqGSIb3DQEBCwUAMDoxCzAJ
BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy
MB4XDTE3MTAwMzAzMTczM1oXDTE4MTEwMzAzMTczM1owgYUxLTArBgNVBAsMJFZlcmlmaWVk
IEVtYWlsOiBqYWx0bWFuQGF1cmlzdG9yLmNvbTEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBh
dXJpc3Rvci5jb20xLzAtBgoJkiaJk/IsZAEBEx9BMDE0MjdFMDAwMDAxNUVFMDNEMTg3QTAw
MDA0QUE1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqqJC89ZA1DSS7t/Ug8Dd
BQv5nBDumInWtFvHwVCORitVCvlkX4SfqKpERATq0eHOSc0zEz1PUjhAT8lgbNj8Bs92pL9t
DW/VHHpq11w06rCEmZJNxgErAIvMpRuAhGrzvBpQBLj8nDArHWw+5nRn/KnK7ZO81LEEj4TG
w0PEKGSa0aFA+JdRTJ6BZSDP2o/8AHx+Bw4JgW8VppAe4IuY/F+JoYtyQDL+fm1YMnFMtf1A
6IvlGXD7gMksPRbVIfD+QpHZbQvNXZAVVDaCWZuWQq46Vl4lSlkmW9yMlGddvFGl2zSMK7ny
f0kbWJLw9lZxXDegY0/ciJPACPsyBwuyLwIDAQABo4ICnTCCApkwDgYDVR0PAQH/BAQDAgWg
MIGEBggrBgEFBQcBAQR4MHYwMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJjaWFsLm9jc3Au
aWRlbnRydXN0LmNvbTBCBggrBgEFBQcwAoY2aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0
LmNvbS9jZXJ0cy90cnVzdGlkY2FhMTIucDdjMB8GA1UdIwQYMBaAFKRz2u9pNYp1zKAZewgy
+GuJ5ELsMAkGA1UdEwQCMAAwggEsBgNVHSAEggEjMIIBHzCCARsGC2CGSAGG+S8ABgsBMIIB
CjBKBggrBgEFBQcCARY+aHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0
ZXMvcG9saWN5L3RzL2luZGV4Lmh0bWwwgbsGCCsGAQUFBwICMIGuGoGrVGhpcyBUcnVzdElE
IENlcnRpZmljYXRlIGhhcyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdpdGggCklkZW5U
cnVzdCdzIFRydXN0SUQgQ2VydGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2Vj
dXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEUG
A1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL3Ry
dXN0aWRjYWExMi5jcmwwHwYDVR0RBBgwFoEUamFsdG1hbkBhdXJpc3Rvci5jb20wHQYDVR0O
BBYEFNefZrPaqPUvaS6V6kAmHDwFhoDiMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDANBgkqhkiG9w0BAQsFAAOCAQEAKlssrfOJ5+WwHyhFSeSsioN0qpg2QDX/uvodF38JbquO
1U0my0j3Cc/bwk48++bjzp0Fvk/Kkcmss5/6zzJMjr9rf12QCQfKkbO9nMm8Bg6IP3pYgk0W
/F1h3ZQF3OgBn3zZoOd3f1a6dF6z12MqKA/2g5GKrQFxkdzTGrNw6ISE9uY8ysvc3i2N2kas
HNi5Etk7StZ1jvFX5sQMIeNdlF+z+BU/AyT7NoBS4gCH+ggF+DG7fAYywvy42Lfu8p6kopKT
5JZpYce1cNjnOaDhzhgeR+oXxoDbekF27JinXHQSKjBxhujcZu5leAkpctFpZxnIKZJZUBiu
31Nm7xYaijCCBpEwggR5oAMCAQICEQD53lZ/yU0Md3D5YBtS2hU7MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVz
dCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAeFw0xNTAyMTgyMjI1MTlaFw0yMzAyMTgyMjI1MTla
MDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQg
Q0EgQTEyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0ZFNPM8KJzSSrkvpmtQl
a3ksT+fq1s9c+Ea3YSC/umUkygSm9UkkOoaoNjKZoCx3wef1kwC4pQQV2XHk+AKR+7uMvnOC
Iw2cAVUP0/Kuy4X6miqaXGGVDTqwVjaFuFCRVVDTQoI2BTMpwFQi+O/TjD5+E0+TAZbkzsB7
krk4YUbA6hFyT0YboxRUq9M2QHDb+80w53b1UZVO1HS2Mfk9LnINeyzjxiXU/iENK07YvjBO
xbY/ftAYPbv/9cY3wrpqZYHoXZc6B9/8+aVCNA45FP3k+YuTDC+ZrmePQBLQJWnyS/QrZEdX
saieWUqkUMxPQKTExArCiP61YRYlOIMpKwIDAQABo4ICgDCCAnwwgYkGCCsGAQUFBwEBBH0w
ezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEcG
CCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL3Jvb3RzL2NvbW1l
cmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C5yZUyI42djAPBgNV
HRMBAf8EBTADAQH/MIIBIAYDVR0gBIIBFzCCARMwggEPBgRVHSAAMIIBBTCCAQEGCCsGAQUF
BwICMIH0MEUWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3Bv
bGljeS90cy9pbmRleC5odG1sMAMCAQEagapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFz
IGJlZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENl
cnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29t
L2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBKBgNVHR8EQzBBMD+gPaA7hjlo
dHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC9jb21tZXJjaWFscm9vdGNhMS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBhjAdBgNV
HQ4EFgQUpHPa72k1inXMoBl7CDL4a4nkQuwwDQYJKoZIhvcNAQELBQADggIBAA3hgq7S+/Tr
Yxl+D7ExI1Rdgq8fC9kiT7ofWlSaK/IMjgjoDfBbPGWvzdkmbSgYgXo8GxuAon9+HLIjNv68
BgUmbIjwj/SYaVz6chA25XZdjxzKk+hUkqCmfOn/twQJeRfxHg3I+0Sfwp5xs10YF0Robhrs
CRne6OUmh9mph0fE3b21k90OVnx9Hfr+YAV4ISrTA6045zQTKGzb370whliPLFo+hNL6XzEt
y5hfdFaWKtHIfpE994CLmTJI4SEbWq40d7TpAjCmKCPIVPq/+9GqggGvtakM5K3VXNc9VtKP
U9xYGCTDIYoeVBQ65JsdsdyM4PzDzAdINsv4vaF7yE03nh2jLV7XAkcqad9vS4EB4hKjFFsm
cwxa+ACUfkVWtBaWBqN4f/o1thsFJHEAu4Q6oRB6mYkzqrPigPazF2rgYw3lp0B1gSzCRj+j
RtErIVdMPeZ2p5Fdx7SNhBtabuhqmpJkFxwW9SBg6sHvy0HpzVvEiBpApFKG1ZHXMwzQl+pR
8P27wWDsblJU7Qgb8ZzGRK9l5GOFhxtN+oXZ4CCmunLMtaZ2vSai7du/VKrg64GGZNAKerEB
evjJVNFgeSnmUK9GB4kCZ7U5NWlU+2H87scntW4Q/0Y6vqQJcJeaMHg/dQnahTQ2p+hB1xJJ
K32GWIAucTFMSOKLbQHadIOiMYIDFDCCAxACAQEwTjA6MQswCQYDVQQGEwJVUzESMBAGA1UE
ChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMgIQQAFe4D0YrXK5RrCU85MI
7zANBglghkgBZQMEAgEFAKCCAZcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTgwNjA0MjEyMjMzWjAvBgkqhkiG9w0BCQQxIgQgdxgZzd6rf6jvAYJBxD1X
bL1+Ea/2045g/EGQ6kI2AXQwXQYJKwYBBAGCNxAEMVAwTjA6MQswCQYDVQQGEwJVUzESMBAG
A1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMgIQQAFe4D0YrXK5RrCU
85MI7zBfBgsqhkiG9w0BCRACCzFQoE4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5U
cnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABXuA9GK1yuUawlPOTCO8wbAYJKoZI
hvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq
hkiG9w0BAQEFAASCAQAkVcymytncV1irprz+g0TvWOrslJX4UNw5WZQQAH6mTUpWVwLuOyzp
DzP3SmoZ8YtJWzoisPq2MSe90o+WLYyGeCcSAPTVL8+dgoPbVKJuSoLOfegzwl6VxwndgtXM
EochQA5sTTgVqDzXpNcommIUVEa2GDRlQay2RUMQUTJKlalhp8TrWz9IStCxa5BFjcFJ0tFu
vGuXpX2vua53VuTxMnEOwQO+ECl6Ii6sQehredSvDCUjXlJCI0OwfL1tuobpbbrD4ump6rOa
En1JpzBCyNXwlKpfBXp+NpWCTXwz+JsP08swtLmNFtIVXcmdvAeqDGsREyo57lN9D7O0rqjV
AAAAAAAA
--------------ms030902090506070000050907--


From andreas.ladanyi@kit.edu  Mon Jun 11 16:44:16 2018
From: andreas.ladanyi@kit.edu (Andreas Ladanyi)
Date: Mon, 11 Jun 2018 17:44:16 +0200
Subject: [OpenAFS] Add new database server with lowest IP
Message-ID: <611c7ea9-b99d-87fd-703e-22743c893410@kit.edu>

Hi,

i red this page http://docs.openafs.org/QuickStartUnix/HDRWQ114.html

In my case the new database server has lowest ip and has no database
content.

So how is the database synchronised from the old database (old ubik)
servers which are currently running and with up to date database content ?

Do i have to backup / restore the DB0 files to the new ubik coordintor
once ? Or should i dont care about because ubik will do all magic for me ?

regards,
Andi

From kaduk@mit.edu  Mon Jun 11 22:54:23 2018
From: kaduk@mit.edu (Benjamin Kaduk)
Date: Mon, 11 Jun 2018 16:54:23 -0500
Subject: [OpenAFS] Add new database server with lowest IP
In-Reply-To: <611c7ea9-b99d-87fd-703e-22743c893410@kit.edu>
References: <611c7ea9-b99d-87fd-703e-22743c893410@kit.edu>
Message-ID: <20180611215423.GK64971@kduck.kaduk.org>

On Mon, Jun 11, 2018 at 05:44:16PM +0200, Andreas Ladanyi wrote:
> Hi,
> 
> i red this page http://docs.openafs.org/QuickStartUnix/HDRWQ114.html
> 
> In my case the new database server has lowest ip and has no database
> content.
> 
> So how is the database synchronised from the old database (old ubik)
> servers which are currently running and with up to date database content ?
> 
> Do i have to backup / restore the DB0 files to the new ubik coordintor
> once ? Or should i dont care about because ubik will do all magic for me ?

In short, "ubik will do all magic for you".

The latest database version and the sync-site election are tracked
separately.  There have been occasional bugs in edge cases where
multiple servers go down in close succession that could cause the
"magic" to fail, but adding a new server while the old one remains
running should be just fine.

-Ben

From jaltman@auristor.com  Tue Jun 12 12:28:58 2018
From: jaltman@auristor.com (Jeffrey Altman)
Date: Tue, 12 Jun 2018 07:28:58 -0400
Subject: [OpenAFS] Add new database server with lowest IP
In-Reply-To: <611c7ea9-b99d-87fd-703e-22743c893410@kit.edu>
References: <611c7ea9-b99d-87fd-703e-22743c893410@kit.edu>
Message-ID: <13a53c84-614d-6352-15da-52c78aa975e2@auristor.com>

This is a cryptographically signed message in MIME format.

--------------ms050704000101050109010904
Content-Type: multipart/mixed;
 boundary="------------09D40069366E8711C8522AEB"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------09D40069366E8711C8522AEB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 6/11/2018 11:44 AM, Andreas Ladanyi wrote:
> Hi,
>=20
> i red this page http://docs.openafs.org/QuickStartUnix/HDRWQ114.html
>=20
> In my case the new database server has lowest ip and has no database
> content.
>=20
> So how is the database synchronised from the old database (old ubik)
> servers which are currently running and with up to date database conten=
t ?
>=20
> Do i have to backup / restore the DB0 files to the new ubik coordintor
> once ? Or should i dont care about because ubik will do all magic for m=
e ?

When a coordinator (aka sync site) is elected it enters recovery mode.

The first step in recovery mode is "find the latest database".  In
OpenAFS, the coordinator queries all of the non-clone peers for their
database version.  It then decides whether it has the latest database or
another peer does.

At this point the coordinator is in recovery state "Found DB".

If another peer does, then it fetches the more recent database.

At this point the coordinator is in recovery state "Have DB".

The coordinator then ensures that all peers receive the current DB.

At this point the recovery state is "Sent DB".

The coordinator can now begin processing write requests.  After the
first write request the recovery state becomes "Modified DB".

Although there isn't any need to copy the database to the new ubik
server before it is started, it is critically important that the new
ubik server be added to the server CellServDB on all of the existing
ubik servers before the new ubik server is started.

Imagine that your existing ubik servers are B, C and D.  Since the
lowest ranked server receives an extra half vote it is extremely
important that there be agreement on which server is the lowest ranked
server.

In the current configuration all of the servers are in agreement that
the ranking is order from lowest to highest is:

  B < C < D

Therefore, B gets the extra half vote and there are a total of 3.5
votes.  To be elected coordinator requires a minimum of 2 votes.

But what happens if you add server A

  A < B < C < D

In this configuration A gets the extra half vote and there are a total
of 4.5 votes.  To be elected coordinator requires a minimum of 2.5 votes.=


When adding a new server without shutting down the cell there will be
some servers that are running with the old configuration and some with
the new one.  For example, if the knew configuration is known by servers
A and D but not B and C then A will receive 2.5 votes and it will be
elected coordinator.  However B will receive 2 votes and believe that it
has been elected coordinator.  This results in two servers accepting
write transactions which will result in data loss.

The underlying problem is that the ubik protocol variant implemented by
OpenAFS does not have a method of verifying which servers share the same
configuration and only permit votes to be cast for and accepted from
servers that share the same configuration.

In order to avoid the risk of database forking I recommend the following
procedure:

1. Update the client CellServDB and DNS SRV/AFSDB records to add the
   new server

2. Update the server CellServDB on all of the fileservers to add the
   new server and restart them (only restart if not also ubik servers)

3. Update the server CellServDB on all of the ubik servers to add the
   new server but do not restart.

4. In order from highest rank to lowest rank (D, C, B):

 a. Stop server  (bos stop <server> -all)

 b. Wait three minutes (to ensure that all other servers notice this
    server shutdown which is necessary to avoid bugs in most OpenAFS
    versions that can lead to database corruption.)

 c. Start server (bos start <server> -all)

 d. Repeat for the next lower ranked server.

5. Start the new server

This order will ensure that there is never any confusion for clients or
ubik servers.


Jeffrey Altman


--------------09D40069366E8711C8522AEB
Content-Type: text/x-vcard; charset=utf-8;
 name="jaltman.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="jaltman.vcf"

begin:vcard
fn:Jeffrey Altman
n:Altman;Jeffrey
org:AuriStor, Inc.
adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St=
ates
email;internet:jaltman@auristor.com
title:Founder and CEO
tel;work:+1-212-769-9018
note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman=
=3D0D=3D0A=3D
	Skype: jeffrey.e.altman=3D0D=3D0A=3D
=09
url:https://www.auristor.com/
version:2.1
end:vcard


--------------09D40069366E8711C8522AEB--

--------------ms050704000101050109010904
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DIIwggXpMIIE0aADAgECAhBAAV7gPRitcrlGsJTzkwjvMA0GCSqGSIb3DQEBCwUAMDoxCzAJ
BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy
MB4XDTE3MTAwMzAzMTczM1oXDTE4MTEwMzAzMTczM1owgYUxLTArBgNVBAsMJFZlcmlmaWVk
IEVtYWlsOiBqYWx0bWFuQGF1cmlzdG9yLmNvbTEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBh
dXJpc3Rvci5jb20xLzAtBgoJkiaJk/IsZAEBEx9BMDE0MjdFMDAwMDAxNUVFMDNEMTg3QTAw
MDA0QUE1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqqJC89ZA1DSS7t/Ug8Dd
BQv5nBDumInWtFvHwVCORitVCvlkX4SfqKpERATq0eHOSc0zEz1PUjhAT8lgbNj8Bs92pL9t
DW/VHHpq11w06rCEmZJNxgErAIvMpRuAhGrzvBpQBLj8nDArHWw+5nRn/KnK7ZO81LEEj4TG
w0PEKGSa0aFA+JdRTJ6BZSDP2o/8AHx+Bw4JgW8VppAe4IuY/F+JoYtyQDL+fm1YMnFMtf1A
6IvlGXD7gMksPRbVIfD+QpHZbQvNXZAVVDaCWZuWQq46Vl4lSlkmW9yMlGddvFGl2zSMK7ny
f0kbWJLw9lZxXDegY0/ciJPACPsyBwuyLwIDAQABo4ICnTCCApkwDgYDVR0PAQH/BAQDAgWg
MIGEBggrBgEFBQcBAQR4MHYwMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJjaWFsLm9jc3Au
aWRlbnRydXN0LmNvbTBCBggrBgEFBQcwAoY2aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0
LmNvbS9jZXJ0cy90cnVzdGlkY2FhMTIucDdjMB8GA1UdIwQYMBaAFKRz2u9pNYp1zKAZewgy
+GuJ5ELsMAkGA1UdEwQCMAAwggEsBgNVHSAEggEjMIIBHzCCARsGC2CGSAGG+S8ABgsBMIIB
CjBKBggrBgEFBQcCARY+aHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0
ZXMvcG9saWN5L3RzL2luZGV4Lmh0bWwwgbsGCCsGAQUFBwICMIGuGoGrVGhpcyBUcnVzdElE
IENlcnRpZmljYXRlIGhhcyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdpdGggCklkZW5U
cnVzdCdzIFRydXN0SUQgQ2VydGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2Vj
dXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEUG
A1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL3Ry
dXN0aWRjYWExMi5jcmwwHwYDVR0RBBgwFoEUamFsdG1hbkBhdXJpc3Rvci5jb20wHQYDVR0O
BBYEFNefZrPaqPUvaS6V6kAmHDwFhoDiMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDANBgkqhkiG9w0BAQsFAAOCAQEAKlssrfOJ5+WwHyhFSeSsioN0qpg2QDX/uvodF38JbquO
1U0my0j3Cc/bwk48++bjzp0Fvk/Kkcmss5/6zzJMjr9rf12QCQfKkbO9nMm8Bg6IP3pYgk0W
/F1h3ZQF3OgBn3zZoOd3f1a6dF6z12MqKA/2g5GKrQFxkdzTGrNw6ISE9uY8ysvc3i2N2kas
HNi5Etk7StZ1jvFX5sQMIeNdlF+z+BU/AyT7NoBS4gCH+ggF+DG7fAYywvy42Lfu8p6kopKT
5JZpYce1cNjnOaDhzhgeR+oXxoDbekF27JinXHQSKjBxhujcZu5leAkpctFpZxnIKZJZUBiu
31Nm7xYaijCCBpEwggR5oAMCAQICEQD53lZ/yU0Md3D5YBtS2hU7MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVz
dCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAeFw0xNTAyMTgyMjI1MTlaFw0yMzAyMTgyMjI1MTla
MDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQg
Q0EgQTEyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0ZFNPM8KJzSSrkvpmtQl
a3ksT+fq1s9c+Ea3YSC/umUkygSm9UkkOoaoNjKZoCx3wef1kwC4pQQV2XHk+AKR+7uMvnOC
Iw2cAVUP0/Kuy4X6miqaXGGVDTqwVjaFuFCRVVDTQoI2BTMpwFQi+O/TjD5+E0+TAZbkzsB7
krk4YUbA6hFyT0YboxRUq9M2QHDb+80w53b1UZVO1HS2Mfk9LnINeyzjxiXU/iENK07YvjBO
xbY/ftAYPbv/9cY3wrpqZYHoXZc6B9/8+aVCNA45FP3k+YuTDC+ZrmePQBLQJWnyS/QrZEdX
saieWUqkUMxPQKTExArCiP61YRYlOIMpKwIDAQABo4ICgDCCAnwwgYkGCCsGAQUFBwEBBH0w
ezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEcG
CCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL3Jvb3RzL2NvbW1l
cmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C5yZUyI42djAPBgNV
HRMBAf8EBTADAQH/MIIBIAYDVR0gBIIBFzCCARMwggEPBgRVHSAAMIIBBTCCAQEGCCsGAQUF
BwICMIH0MEUWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3Bv
bGljeS90cy9pbmRleC5odG1sMAMCAQEagapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFz
IGJlZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENl
cnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29t
L2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBKBgNVHR8EQzBBMD+gPaA7hjlo
dHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC9jb21tZXJjaWFscm9vdGNhMS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBhjAdBgNV
HQ4EFgQUpHPa72k1inXMoBl7CDL4a4nkQuwwDQYJKoZIhvcNAQELBQADggIBAA3hgq7S+/Tr
Yxl+D7ExI1Rdgq8fC9kiT7ofWlSaK/IMjgjoDfBbPGWvzdkmbSgYgXo8GxuAon9+HLIjNv68
BgUmbIjwj/SYaVz6chA25XZdjxzKk+hUkqCmfOn/twQJeRfxHg3I+0Sfwp5xs10YF0Robhrs
CRne6OUmh9mph0fE3b21k90OVnx9Hfr+YAV4ISrTA6045zQTKGzb370whliPLFo+hNL6XzEt
y5hfdFaWKtHIfpE994CLmTJI4SEbWq40d7TpAjCmKCPIVPq/+9GqggGvtakM5K3VXNc9VtKP
U9xYGCTDIYoeVBQ65JsdsdyM4PzDzAdINsv4vaF7yE03nh2jLV7XAkcqad9vS4EB4hKjFFsm
cwxa+ACUfkVWtBaWBqN4f/o1thsFJHEAu4Q6oRB6mYkzqrPigPazF2rgYw3lp0B1gSzCRj+j
RtErIVdMPeZ2p5Fdx7SNhBtabuhqmpJkFxwW9SBg6sHvy0HpzVvEiBpApFKG1ZHXMwzQl+pR
8P27wWDsblJU7Qgb8ZzGRK9l5GOFhxtN+oXZ4CCmunLMtaZ2vSai7du/VKrg64GGZNAKerEB
evjJVNFgeSnmUK9GB4kCZ7U5NWlU+2H87scntW4Q/0Y6vqQJcJeaMHg/dQnahTQ2p+hB1xJJ
K32GWIAucTFMSOKLbQHadIOiMYIDFDCCAxACAQEwTjA6MQswCQYDVQQGEwJVUzESMBAGA1UE
ChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMgIQQAFe4D0YrXK5RrCU85MI
7zANBglghkgBZQMEAgEFAKCCAZcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTgwNjEyMTEyODU4WjAvBgkqhkiG9w0BCQQxIgQgULHmevzungWVNywFoe1m
Vmok4N+LPJz97fs7pgJSV0wwXQYJKwYBBAGCNxAEMVAwTjA6MQswCQYDVQQGEwJVUzESMBAG
A1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMgIQQAFe4D0YrXK5RrCU
85MI7zBfBgsqhkiG9w0BCRACCzFQoE4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5U
cnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABXuA9GK1yuUawlPOTCO8wbAYJKoZI
hvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq
hkiG9w0BAQEFAASCAQATdhuZFeLQzvhgmJtcet+yxq8Gx5TDQHDl1L1tb6FVsDJYP13aja9y
7s4xepddALK38AkLmQMCJFrWg2k2VaW+a24b8SG4d0vp/vUCih7hWsVUwuFFdn4GyZ/dJv4a
ocRPcmv/0buSa+bqEuyHUhHXES5ZKmCiKcw9LMIdmwS21Fu3WaHjY3UYyavRj3mcH9KoX2o8
682rqA1GENC98Zd4Wj3D/OCXZkWBj1rb2uQh3ikWIkAxDUx2vk2qE03N2Pj9p1T5fg6EUzK6
hwXBhBIijLb95KXYFYS5goj6p9JzMH0C1+554d71n/dRWh2sk7cz8wRZaedkJDStR5cbA16Y
AAAAAAAA
--------------ms050704000101050109010904--


From andreas.ladanyi@kit.edu  Wed Jun 13 13:06:16 2018
From: andreas.ladanyi@kit.edu (Andreas Ladanyi)
Date: Wed, 13 Jun 2018 14:06:16 +0200
Subject: [OpenAFS] fs newcell / clients CellServDB / adding new db server
Message-ID: <669ae5e9-cad9-5a21-6a33-e7fcccaa3499@kit.edu>

Hi,

by reading

http://docs.openafs.org/QuickStartUnix/HDRWQ114.html

and

http://docs.openafs.org/Reference/1/fs_newcell.html

i understand that a change in CellServDB on client does have no effect
until reboot.

So i copied the CellServDB which contain a new db server (and the old db
servers) which isnt online yet to clients and detect ssh shell logins
and sudo tasks takes a long time.

When i removed the new db server from CellServDB ssh login and sudo
works great. I didnt add the new db server on client side with "fs
newcell" so kernel list wasnt recreated and shouldnt ask the new db
server because doesnt know about.

Did i understand something wrong with CellServDB / fs newcell ?

regards,
Andi

From dirk.heinrichs@altum.de  Wed Jun 13 16:35:46 2018
From: dirk.heinrichs@altum.de (Dirk Heinrichs)
Date: Wed, 13 Jun 2018 17:35:46 +0200
Subject: [OpenAFS] fs newcell / clients CellServDB / adding new db server
In-Reply-To: <669ae5e9-cad9-5a21-6a33-e7fcccaa3499@kit.edu>
References: <669ae5e9-cad9-5a21-6a33-e7fcccaa3499@kit.edu>
Message-ID: <e6d40006-706b-d8bb-57a5-989b3785209d@altum.de>

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--eDbE73lg7iNJbTC8x4HNhXJaA8GnP5RI3
Content-Type: multipart/mixed; boundary="6Rt0vQaXCgxd1qi6D0EXlA6JduaktFBZl";
 protected-headers="v1"
From: Dirk Heinrichs <dirk.heinrichs@altum.de>
To: openafs-info@openafs.org
Message-ID: <e6d40006-706b-d8bb-57a5-989b3785209d@altum.de>
Subject: Re: [OpenAFS] fs newcell / clients CellServDB / adding new db server
References: <669ae5e9-cad9-5a21-6a33-e7fcccaa3499@kit.edu>
In-Reply-To: <669ae5e9-cad9-5a21-6a33-e7fcccaa3499@kit.edu>

--6Rt0vQaXCgxd1qi6D0EXlA6JduaktFBZl
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: de-DE

Am 13.06.2018 um 14:06 schrieb Andreas Ladanyi:

> i understand that a change in CellServDB on client does have no effect
> until reboot.

Hmm, is this also true when using DNS SRV records instead of CellServDB?

Bye...

=C2=A0=C2=A0=C2=A0 Dirk

--=20
Dirk Heinrichs <dirk.heinrichs@altum.de>
GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de



--6Rt0vQaXCgxd1qi6D0EXlA6JduaktFBZl--

--eDbE73lg7iNJbTC8x4HNhXJaA8GnP5RI3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEJgWJ3LIo7zNO9tmf0p7rxfc7RqsFAlshOeUACgkQ0p7rxfc7
RqtJZw/+MhgH5jEUEmUUjr9lf057ZjI2jd3v5G2QudYhubfR3REviF9z1i0tVL/D
kAMxQvCw350wNuaHfb+jaE2Yy6Kh1wnGmaXv+iETQPEvOnALRbHGl6gx5sLYcyss
OG6rJY2DNBOZsRq4yh/Dj0irK4AUrXPgbYImWarkoFcOPsCGO1+xufPeG77xa9Zt
8YboBAIVfP83BojgCoYO+EUGqSeStKUV36OmgxxyFbGtTA51w7cOG726rQReO2eb
aYVZGW3Mioq/ALosEGTJjalP/I4EAJ94xVJweVGjpLk9XF2N6msgZErODiB7zNr5
JULbdp4/EVuydi9cBK7IGnmUcAa5HxJjZ4HgHOkPnFRfeq+UAGPpHKbmdkTGAIi+
lTixhzq0hLMlr6I+RNH5RUZCGh4JXk2VXoXHi18KAQht/DIvcneUQs2U931RNeDg
pS6Y3PpIEcoK4KPaHfDbb8pNd3v9rzmHBGB82LOFYhoUjWDJpL6p0hMLFdcw5yG/
ZXuDDluB7IP4ZSiyu+aOuEAqHawwTqjH1Yv1mpfZ1F7Cer1KPtzAqA2wzZXRCMVM
XndlQPFmkmlKKkKWa8WgqAJVTa0gcJANXLpUtGOAaLBkwFQMrMDRjCetfvleKRyT
FoZuoaJl9rMBwNh/XgEV4MGS7Zjj6ePT8PwsQD+5RTcWOMFy664=
=rOpm
-----END PGP SIGNATURE-----

--eDbE73lg7iNJbTC8x4HNhXJaA8GnP5RI3--

From jaltman@auristor.com  Wed Jun 13 17:00:20 2018
From: jaltman@auristor.com (Jeffrey Altman)
Date: Wed, 13 Jun 2018 12:00:20 -0400
Subject: [OpenAFS] fs newcell / clients CellServDB / adding new db server
In-Reply-To: <e6d40006-706b-d8bb-57a5-989b3785209d@altum.de>
References: <669ae5e9-cad9-5a21-6a33-e7fcccaa3499@kit.edu>
 <e6d40006-706b-d8bb-57a5-989b3785209d@altum.de>
Message-ID: <0e7d278d-8029-a878-ecf7-aa8c31386c1f@auristor.com>

This is a cryptographically signed message in MIME format.

--------------ms060507080002060909020009
Content-Type: multipart/mixed;
 boundary="------------39754EBC429935406AC6EB93"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------39754EBC429935406AC6EB93
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 6/13/2018 11:35 AM, Dirk Heinrichs wrote:
> Am 13.06.2018 um 14:06 schrieb Andreas Ladanyi:
>=20
>> i understand that a change in CellServDB on client does have no effect=

>> until reboot.
>=20
> Hmm, is this also true when using DNS SRV records instead of CellServDB=
?

For OpenAFS, any server lists provided by the client's CellServDB file
take precedence over DNS SRV records.

If DNS SRV records are in use, the client CellServDB file should not
list any servers.

One of the benefits of DNS SRV records is that the DNS SRV record TTL
value is used to determine the validity period for the server list by
the cache manager.

In this way, clients automatically update their server list information
and administrators can control how frequently the server lists are update=
d.

Jeffrey Altman

--------------39754EBC429935406AC6EB93
Content-Type: text/x-vcard; charset=utf-8;
 name="jaltman.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="jaltman.vcf"

begin:vcard
fn:Jeffrey Altman
n:Altman;Jeffrey
org:AuriStor, Inc.
adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St=
ates
email;internet:jaltman@auristor.com
title:Founder and CEO
tel;work:+1-212-769-9018
note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman=
=3D0D=3D0A=3D
	Skype: jeffrey.e.altman=3D0D=3D0A=3D
=09
url:https://www.auristor.com/
version:2.1
end:vcard


--------------39754EBC429935406AC6EB93--

--------------ms060507080002060909020009
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DIIwggXpMIIE0aADAgECAhBAAV7gPRitcrlGsJTzkwjvMA0GCSqGSIb3DQEBCwUAMDoxCzAJ
BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy
MB4XDTE3MTAwMzAzMTczM1oXDTE4MTEwMzAzMTczM1owgYUxLTArBgNVBAsMJFZlcmlmaWVk
IEVtYWlsOiBqYWx0bWFuQGF1cmlzdG9yLmNvbTEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBh
dXJpc3Rvci5jb20xLzAtBgoJkiaJk/IsZAEBEx9BMDE0MjdFMDAwMDAxNUVFMDNEMTg3QTAw
MDA0QUE1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqqJC89ZA1DSS7t/Ug8Dd
BQv5nBDumInWtFvHwVCORitVCvlkX4SfqKpERATq0eHOSc0zEz1PUjhAT8lgbNj8Bs92pL9t
DW/VHHpq11w06rCEmZJNxgErAIvMpRuAhGrzvBpQBLj8nDArHWw+5nRn/KnK7ZO81LEEj4TG
w0PEKGSa0aFA+JdRTJ6BZSDP2o/8AHx+Bw4JgW8VppAe4IuY/F+JoYtyQDL+fm1YMnFMtf1A
6IvlGXD7gMksPRbVIfD+QpHZbQvNXZAVVDaCWZuWQq46Vl4lSlkmW9yMlGddvFGl2zSMK7ny
f0kbWJLw9lZxXDegY0/ciJPACPsyBwuyLwIDAQABo4ICnTCCApkwDgYDVR0PAQH/BAQDAgWg
MIGEBggrBgEFBQcBAQR4MHYwMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJjaWFsLm9jc3Au
aWRlbnRydXN0LmNvbTBCBggrBgEFBQcwAoY2aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0
LmNvbS9jZXJ0cy90cnVzdGlkY2FhMTIucDdjMB8GA1UdIwQYMBaAFKRz2u9pNYp1zKAZewgy
+GuJ5ELsMAkGA1UdEwQCMAAwggEsBgNVHSAEggEjMIIBHzCCARsGC2CGSAGG+S8ABgsBMIIB
CjBKBggrBgEFBQcCARY+aHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0
ZXMvcG9saWN5L3RzL2luZGV4Lmh0bWwwgbsGCCsGAQUFBwICMIGuGoGrVGhpcyBUcnVzdElE
IENlcnRpZmljYXRlIGhhcyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdpdGggCklkZW5U
cnVzdCdzIFRydXN0SUQgQ2VydGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2Vj
dXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEUG
A1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL3Ry
dXN0aWRjYWExMi5jcmwwHwYDVR0RBBgwFoEUamFsdG1hbkBhdXJpc3Rvci5jb20wHQYDVR0O
BBYEFNefZrPaqPUvaS6V6kAmHDwFhoDiMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDANBgkqhkiG9w0BAQsFAAOCAQEAKlssrfOJ5+WwHyhFSeSsioN0qpg2QDX/uvodF38JbquO
1U0my0j3Cc/bwk48++bjzp0Fvk/Kkcmss5/6zzJMjr9rf12QCQfKkbO9nMm8Bg6IP3pYgk0W
/F1h3ZQF3OgBn3zZoOd3f1a6dF6z12MqKA/2g5GKrQFxkdzTGrNw6ISE9uY8ysvc3i2N2kas
HNi5Etk7StZ1jvFX5sQMIeNdlF+z+BU/AyT7NoBS4gCH+ggF+DG7fAYywvy42Lfu8p6kopKT
5JZpYce1cNjnOaDhzhgeR+oXxoDbekF27JinXHQSKjBxhujcZu5leAkpctFpZxnIKZJZUBiu
31Nm7xYaijCCBpEwggR5oAMCAQICEQD53lZ/yU0Md3D5YBtS2hU7MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVz
dCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAeFw0xNTAyMTgyMjI1MTlaFw0yMzAyMTgyMjI1MTla
MDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQg
Q0EgQTEyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0ZFNPM8KJzSSrkvpmtQl
a3ksT+fq1s9c+Ea3YSC/umUkygSm9UkkOoaoNjKZoCx3wef1kwC4pQQV2XHk+AKR+7uMvnOC
Iw2cAVUP0/Kuy4X6miqaXGGVDTqwVjaFuFCRVVDTQoI2BTMpwFQi+O/TjD5+E0+TAZbkzsB7
krk4YUbA6hFyT0YboxRUq9M2QHDb+80w53b1UZVO1HS2Mfk9LnINeyzjxiXU/iENK07YvjBO
xbY/ftAYPbv/9cY3wrpqZYHoXZc6B9/8+aVCNA45FP3k+YuTDC+ZrmePQBLQJWnyS/QrZEdX
saieWUqkUMxPQKTExArCiP61YRYlOIMpKwIDAQABo4ICgDCCAnwwgYkGCCsGAQUFBwEBBH0w
ezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEcG
CCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL3Jvb3RzL2NvbW1l
cmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C5yZUyI42djAPBgNV
HRMBAf8EBTADAQH/MIIBIAYDVR0gBIIBFzCCARMwggEPBgRVHSAAMIIBBTCCAQEGCCsGAQUF
BwICMIH0MEUWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3Bv
bGljeS90cy9pbmRleC5odG1sMAMCAQEagapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFz
IGJlZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENl
cnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29t
L2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBKBgNVHR8EQzBBMD+gPaA7hjlo
dHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC9jb21tZXJjaWFscm9vdGNhMS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBhjAdBgNV
HQ4EFgQUpHPa72k1inXMoBl7CDL4a4nkQuwwDQYJKoZIhvcNAQELBQADggIBAA3hgq7S+/Tr
Yxl+D7ExI1Rdgq8fC9kiT7ofWlSaK/IMjgjoDfBbPGWvzdkmbSgYgXo8GxuAon9+HLIjNv68
BgUmbIjwj/SYaVz6chA25XZdjxzKk+hUkqCmfOn/twQJeRfxHg3I+0Sfwp5xs10YF0Robhrs
CRne6OUmh9mph0fE3b21k90OVnx9Hfr+YAV4ISrTA6045zQTKGzb370whliPLFo+hNL6XzEt
y5hfdFaWKtHIfpE994CLmTJI4SEbWq40d7TpAjCmKCPIVPq/+9GqggGvtakM5K3VXNc9VtKP
U9xYGCTDIYoeVBQ65JsdsdyM4PzDzAdINsv4vaF7yE03nh2jLV7XAkcqad9vS4EB4hKjFFsm
cwxa+ACUfkVWtBaWBqN4f/o1thsFJHEAu4Q6oRB6mYkzqrPigPazF2rgYw3lp0B1gSzCRj+j
RtErIVdMPeZ2p5Fdx7SNhBtabuhqmpJkFxwW9SBg6sHvy0HpzVvEiBpApFKG1ZHXMwzQl+pR
8P27wWDsblJU7Qgb8ZzGRK9l5GOFhxtN+oXZ4CCmunLMtaZ2vSai7du/VKrg64GGZNAKerEB
evjJVNFgeSnmUK9GB4kCZ7U5NWlU+2H87scntW4Q/0Y6vqQJcJeaMHg/dQnahTQ2p+hB1xJJ
K32GWIAucTFMSOKLbQHadIOiMYIDFDCCAxACAQEwTjA6MQswCQYDVQQGEwJVUzESMBAGA1UE
ChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMgIQQAFe4D0YrXK5RrCU85MI
7zANBglghkgBZQMEAgEFAKCCAZcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTgwNjEzMTYwMDIwWjAvBgkqhkiG9w0BCQQxIgQgm/ZILQH8IiAzxd5mCGrc
LEGlTBywmIa/2D8yMy2CQ78wXQYJKwYBBAGCNxAEMVAwTjA6MQswCQYDVQQGEwJVUzESMBAG
A1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMgIQQAFe4D0YrXK5RrCU
85MI7zBfBgsqhkiG9w0BCRACCzFQoE4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5U
cnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABXuA9GK1yuUawlPOTCO8wbAYJKoZI
hvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq
hkiG9w0BAQEFAASCAQA2nbEu1iDpQmcR6NrFr0NmTA+n4vHmFqarLlibXcuBkchw2cntm4bX
sC8ry/tvHsOILBJHqx9dpD4skatire4Zto/LUQ+i3LNg8zavaWkX0WhhBmX6Mu8eOTs54eCf
wMysJzfjlRGhlizDdAXbDqE0MRmUz7BlMYclI25uwKtiDU3drw/s1AChVjzUM4aKNYa0qzKH
TtqRlnBRn65Q/yavXxs+90HFinPStNM6Y791Q+PgzmbSL1c4Ty9Smp/va6gPxxcM7VVgjtgZ
yr9zmSVacNIR7rXsL3xuyNRSnp5NtlJApkEFe5fbp2/gXqv+32JcaIougRT5EyhsQAj5XZkZ
AAAAAAAA
--------------ms060507080002060909020009--


From andreas.ladanyi@kit.edu  Thu Jun 14 07:54:00 2018
From: andreas.ladanyi@kit.edu (Andreas Ladanyi)
Date: Thu, 14 Jun 2018 08:54:00 +0200
Subject: [OpenAFS] fs newcell / clients CellServDB / adding new db server
In-Reply-To: <c1155181-af9f-5305-0629-c5f045b837d1@auristor.com>
References: <669ae5e9-cad9-5a21-6a33-e7fcccaa3499@kit.edu>
 <c1155181-af9f-5305-0629-c5f045b837d1@auristor.com>
Message-ID: <562792ce-4612-9e1b-c366-4077b1e81895@kit.edu>

> On 6/13/2018 8:06 AM, Andreas Ladanyi wrote:
>> Hi,
>>
>> by reading
>>
>> http://docs.openafs.org/QuickStartUnix/HDRWQ114.html
>>
>> and
>>
>> http://docs.openafs.org/Reference/1/fs_newcell.html
>>
>> i understand that a change in CellServDB on client does have no effect
>> until reboot.
> The OpenAFS unix cache manager populates the list of location servers
> (vlservers) at startup.  The loaded server list can be adjusted via the
> "fs newcell" command at runtime.
>
> This behavior is specific to the OpenAFS unix cache manager.
>
> It does not apply to other cache managers nor does it apply to command
> line tools such as aklog, vos, pts, etc..  Nor does it apply to PAM modules.
>
>> So i copied the CellServDB which contain a new db server (and the old db
>> servers) which isnt online yet to clients and detect ssh shell logins
>> and sudo tasks takes a long time.
>>
>> When i removed the new db server from CellServDB ssh login and sudo
>> works great. I didnt add the new db server on client side with "fs
>> newcell" so kernel list wasnt recreated and shouldnt ask the new db
>> server because doesnt know about.
> Questions:
>
> * are DNS SRV records published for your cell?
no, host -t AFSDB domain reports no AFSDB record
>
> if yes, the CellServDB cell entry should contain the name of the cell
>   and an empty server list
>
> * where in the CellServDB cell list did you insert the new server?
The new server with lowest ip is at the end of the CellServDB

Andi

From andreas.ladanyi@kit.edu  Thu Jun 14 13:44:31 2018
From: andreas.ladanyi@kit.edu (Andreas Ladanyi)
Date: Thu, 14 Jun 2018 14:44:31 +0200
Subject: [OpenAFS] Windows 10, KDC not reachable / AFS integrated login
 failed
In-Reply-To: <d8662520-1890-be9d-4caa-ff856c5fd01d@uni-hamburg.de>
References: <95033ca8-bfc4-6fa4-36d4-fd2f82db8b17@kit.edu>
 <d8662520-1890-be9d-4caa-ff856c5fd01d@uni-hamburg.de>
Message-ID: <8c98c328-8abb-25bb-011b-339047f366e1@kit.edu>

Hi Gaja,

you are great. Thank you. It works.

Andi


> Am 30.01.2018 um 14:09 schrieb Andreas Ladanyi:
>
>> Windows 10 Pro , Auristor AFS client package
>>
>> When starting the device and before login screen appears the messages
>> appears: [snip]
>>
>> AFS integrated login failed
>>
>> before it is possible to enter credentials at windows login box (display
>> manager).
>
> This is a rather late answer, but since I just happened to stumble
> again over the solution, I thought I'd post it here in case it is
> still useful for anybody.
>
>> Is it possible to start kerberos client and afs client after entering
>> the credentials at windows 10 ?
>
> Yes, that is possible. The solution is basically what is posted on
> this website:
>
> https://www.tenforums.com/tutorials/49963-use-sign-info-auto-finish-after-update-restart-windows-10-a.html
>
>
> Apparently, Windows 10 since some version is able to "remember"
> login-credentials over a reboot, and will use these internal
> credentials to sign-in to windows even before you enter the password.
> This unfortunately triggers also the "integrated login" to AFS, but
> since there is no password for it to work with, it will fail.
>
> Once this option in Windows is disabled, Windows will not try to do an
> integrated login without password and everything is ok.
>
> Greetings,
> Gaja Peters


From andreas.ladanyi@kit.edu  Fri Jun 15 14:52:24 2018
From: andreas.ladanyi@kit.edu (Andreas Ladanyi)
Date: Fri, 15 Jun 2018 15:52:24 +0200
Subject: [OpenAFS] fs newcell / clients CellServDB / adding new db server
In-Reply-To: <562792ce-4612-9e1b-c366-4077b1e81895@kit.edu>
References: <669ae5e9-cad9-5a21-6a33-e7fcccaa3499@kit.edu>
 <c1155181-af9f-5305-0629-c5f045b837d1@auristor.com>
 <562792ce-4612-9e1b-c366-4077b1e81895@kit.edu>
Message-ID: <2b7b1233-e92a-318a-f5c8-2f80d030a929@kit.edu>

Hi Jeffrey,
>>> i understand that a change in CellServDB on client does have no effect
>>> until reboot.
>> The OpenAFS unix cache manager populates the list of location servers
>> (vlservers) at startup.  The loaded server list can be adjusted via the
>> "fs newcell" command at runtime.
>>
>> This behavior is specific to the OpenAFS unix cache manager.
>>
>> It does not apply to other cache managers nor does it apply to command
>> line tools such as aklog, vos, pts, etc..  Nor does it apply to PAM modules.
ok. so the process of change CellSrvDB on db servers and bos restart AND
updating (copying) new CellServDB to clients has to be done in a very
short time to minimize timeout symptoms for users, because db servers
has to be in sync and ubik coordinator has to be elected and the afs
clients with new CellServDB with the new db server (lowest ip) asks the
new db server (ubik coordinator) first.

>>
regards,
Andi

From xmgu@royole.com  Fri Jun 15 19:53:56 2018
From: xmgu@royole.com (Ximeng Guan)
Date: Fri, 15 Jun 2018 18:53:56 +0000
Subject: [OpenAFS] Decentralized failover/backup system for RW volumes
In-Reply-To: <CALr0QzGe6_StLZhH_TBM-m9S_cJRF_=-yBHW7hFbQodqHx5G5Q@mail.gmail.com>
References: <CALr0QzHS1=XG8Zm+xSkMQau22kM=PTKZJJdT5JQefaF5vFEtRg@mail.gmail.com>
 <1b61d061-cf9c-dba5-a6e4-424c4aa32ec5@cgv.tugraz.at>
 <CALr0QzGe6_StLZhH_TBM-m9S_cJRF_=-yBHW7hFbQodqHx5G5Q@mail.gmail.com>
Message-ID: <20864089513d4bdc82026d2353f12ea3@royole.com>

T24gYW4gQWN0aXZlLURpcmVjdG9yeS1JbnRlZ3JhdGVkIFdpbmRvd3MgY2xpZW50LCB5b3UgbWF5
IHRyeQ0KYWtsb2cgLWNhY2hlIE1TTFNBOg0KDQpvciB5b3UgbWF5IHNldCB1cCBhbiBzeXN0ZW0g
ZW52aXJvbWVudCB2YXJpYWJsZSBLUkI1Q0NOQU1FPU1TTFNBOg0KDQpOb3RlIHRoZSB0cmFpbGlu
ZyBjb2xvbi4gDQoNClRoYXQgd2lsbCBtYWtlIEFGUyByZS11c2UgdGhlIEtlcmJlcm9zIHRpY2tl
dCBvYnRhaW5lZCBpbiBXaW5kb3dzIGxvZ29uLiANCg0KQmVzdCByZWdhcmRzLA0KU2ltb24NCg0K
DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogb3BlbmFmcy1pbmZvLWFkbWluQG9w
ZW5hZnMub3JnIFttYWlsdG86b3BlbmFmcy1pbmZvLWFkbWluQG9wZW5hZnMub3JnXSBPbiBCZWhh
bGYgT2YgUHJ1bmsgRHVtcA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwNCwgMjAxOCAxMToxMiBQ
TQ0KVG86IG9wZW5hZnMtaW5mb0BvcGVuYWZzLm9yZw0KU3ViamVjdDogUmU6IFtPcGVuQUZTXSBE
ZWNlbnRyYWxpemVkIGZhaWxvdmVyL2JhY2t1cCBzeXN0ZW0gZm9yIFJXIHZvbHVtZXMNCg0KMjAx
OC0wNC0wNCAxMToxMCBHTVQrMDI6MDAgTGFycyBTY2hpbW1lciA8bC5zY2hpbW1lckBjZ3YudHVn
cmF6LmF0PjoNCj4gT24gMDQvMDQvMTggMTA6MTAsIFBydW5rIER1bXAgd3JvdGU6DQo+PiBIaSBP
cGVuQUZTIFRlYW0gIQ0KPg0KPiBIaSBmcm9tIGEgKHN0aWxsKSBPcGVuQUZTIGFkbWluLg0KPg0K
Pj4gSSdtIGN1cnJlbnRseSBhZG1pbmlzdGVyaW5nIGEgaGlnaC1zY2hvb2wgbmV0d29ya3Mgd2l0
aCA1IFNhbWJhIFBEQyANCj4+IGFuZCBhcm91bmQgMTUwIExpbnV4IGV0IDMwMCBXaW5kb3dzIGNs
aWVudHMuIFRvIGJ1aWxkIG15IHVzZXIncyANCj4+IHNoYXJlcyBJIHVzZSBzaW11bHRhbmVvdXNs
eSBTYW1iYSBERlMgYW5kIE5GU3Y0ICggd2l0aCByZWZlcnJhbHMgKS4gDQo+PiBTbyBJIGhhdmUg
YSBnbG9iYWwgbmFtZXNwYWNlIGZvciBteSB3aW5kb3dzIGFuZCBMaW51eCBjbGllbnRzIGJ1dCBJ
IA0KPj4gbmVlZCB0byBtYW5hZ2VzIGFsbCBteSB2b2x1bWVzIG1hbnVhbGx5IHRvIGRpc3RyaWJ1
dGUgdGhlIGxvYWQgb24gdGhlIA0KPj4gc2VydmVycyBhbmQgbWFraW5nIHJlZHVuZGFuY3kgd2l0
aCByc3luYy4NCj4+DQo+PiBJIHdpbGwgYmUgc2hvcnRseSB1cGdyYWRpbmcgYWxsIG15IHNlcnZl
cnMuIFNvIEkgaGF2ZSBzdGFydGVkIA0KPj4gaW52ZXN0aWdhdGluZyBvbiBuZXcgc29sdXRpb25z
LiBBbmQgQUZTIHNlZW1zIHRvIGZpdCBuZWFybHkgYWxsIG15IA0KPj4gbmVlZHMgISBKdXN0IGEg
cG9pbnQgaXMgc3RpbGwgcHJvYmxlbWF0aWMuDQo+DQo+IEZpcnN0OiBrZWVwIGluIG1pbmQsIHRo
ZSBPcGVuQUZTIFdpbmRvd3MgY2xpZW50IGlzIG9sZCBhbmQgDQo+IHVubWFpbnRhaW5lZCBjdXJy
ZW50bHkuIE5lZWRzIG1vcmUgd29yayB0byBrZWVwIGl0IGN1cnJlbnQgYW5kIHVwZGF0ZWQgDQo+
IHdpdGggbGF0ZXN0IE9wZW5BRlMgMS44LnggQW4gYWx0ZXJuYXRlIGltcGxlbWVudGF0aW9uIGlz
IEF1cmlzdG9yLCBidXQgDQo+IHRoYXQgaXMgYSBjb21tZXJjaWFsIHN1aXRlLg0KDQpUaGFuayB5
b3UgdmVyeSBtdWNoIGZvciB5b3VyIGhlbHAgIQ0KDQpUaGF0J3MgdmVyeSBzYWQgLi4uIEFzIEkg
Y2FuJ3QgaGF2ZSBvbmx5IExpbnV4IHN0YXRpb25zIEkgYWJzb2x1dGVseSBuZWVkIGEgcmVsaWFi
bGUgV2luZG93cyBjbGllbnQgZm9yIG15IG5ldHdvcmsgZmlsZSBzeXN0ZW0uIEFuZCBpdCBpcyBu
b3QgYWNjZXB0YWJsZSBmb3IgbWUgdG8gdXNlIGEgY2xvc2VkIHNvdXJjZSBjbGllbnQuIFRoaXMg
aXMgcmVhbGx5IGZydXN0cmF0aW5nIGFzIG1vcmUgSSByZWFkIHRoZSBBRlMgZG9jdW1lbnRhdGlv
biBtb3JlIEkgZmluZCB0aGF0IGl0IGZpdCBwZXJmZWN0bHkgdGhlIG5lZWRzIGZvciBhIGxvY2Fs
IG5ldHdvcmsgcGFyYWxsZWxpemVkIGZpbGUgc3lzdGVtLg0KQW5kIEkgaGF2ZSBtYWRlIHNvbWUg
dGVzdHMgbGlua2luZyBBRlMgdG8gYSBTYW1iYSBBY3RpdmUgRGlyZWN0b3J5IGZvciBLZXJiZXJv
cyBzZWN1cml0eSBhbmQgaXQgd29ya3MgcGVyZmVjdGx5IGZvciBMaW51eCBzZXJ2ZXJzIGFuZCBj
bGllbnRzICEgKG9uY2UgQUVTIGVuY3J5cHRpb24gaXMgZW5hYmxlZCBvbiBBRlMpDQoNClRoZXJl
IGlzIGFsc28gYW5vdGhlciBwcm9ibGVtLiBBcyBJIHVzZSBTYW1iYSBBY3RpdmUgRGlyZWN0b3J5
IGZvciBzZWN1cml0eSwgaXQgc2VlbXMgdGhhdCB0aGUgY3VycmVudCBBRlMgd2luZG93cyBjbGll
bnRzIGRvbid0IHVzZSB0aGUgS2VyYmVyb3MgdGlja2V0IG9idGFpbmVkIGF0IGxvZ29uIHRvIG9i
dGFpbiB0aGUgQUZTIHRva2VuLiBTbyB0aGVyZSBpcyB0d28gS2VyYmVyb3MgYXV0aGVudGljYXRp
b24gYXQgbG9nb24gaW5zdGVhZCBvZiBvbmUuDQoNCkJ1dCBJIGxpa2UgdGhlIGZhY3QgdGhhdCB3
ZSBrbm93LCBpbiBBRlMsIHdoZXJlIHRoZSB2b2x1bWVzIGFyZSBzdG9yZWQuIFRoaXMgaXMgbm90
IHRoZSBjYXNlIGluIHNvbWUgb3RoZXIgZmlsZSBzeXN0ZW1zIGxpa2UgZ2x1c3RlckZTLiBTbyBJ
IGNhbiBwb3RlbnRpYWxseSBkbyBzb21lIG9wdGltaXphdGlvbnMgd2l0aCBBRlMuIEZvciBleGFt
cGxlIEkga25vdyB0aGF0IGFsbCB0aGUgc3R1ZGVudHMgb24gYSBzYW1lIGNsYXNzIHdpbGwgbW91
bnQgdGhlaXIgaG9tZSBzaGFyZSBhdCB0aGUgc2FtZSB0aW1lLiBTbyB0byBsb2FkIGJhbGFuY2Ug
bXkgc2VydmVycyBJIGp1c3QgbmVlZCB0byBkaXN0cmlidXRlIGVhY2ggY2xhc3MgaG9tZSBzaGFy
ZXMgYmV0d2VlbiBteSA1IHNlcnZlcnMuDQoNCkFuZCBhY3R1YWxseSwgU2FtYmEgZG9tYWluIERG
UyBzdXBwb3J0IGlzIG5vdCBmdWxseSBzdXBwb3J0ZWQgYW5kDQpORlN2NCBwTkZTIGZlYXR1cmUg
aXMgc3RpbGwgaW4gZGV2ZWxvcG1lbnQgLi4uDQoNCk1heWJlIGlzIHRvIHRvbyBlYXJseSB0byB1
cGRhdGUgbXkgbmV0d29yayBkZXNpZ24uDQoNClRoYW5rcyBhZ2FpbiAhDQoNCkJhcHRpc3RlLg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9wZW5BRlMt
aW5mbyBtYWlsaW5nIGxpc3QNCk9wZW5BRlMtaW5mb0BvcGVuYWZzLm9yZw0KaHR0cHM6Ly9saXN0
cy5vcGVuYWZzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wZW5hZnMtaW5mbw0K

From jaltman@auristor.com  Fri Jun 15 20:56:31 2018
From: jaltman@auristor.com (Jeffrey Altman)
Date: Fri, 15 Jun 2018 15:56:31 -0400
Subject: [OpenAFS] fs newcell / clients CellServDB / adding new db server
In-Reply-To: <2b7b1233-e92a-318a-f5c8-2f80d030a929@kit.edu>
References: <669ae5e9-cad9-5a21-6a33-e7fcccaa3499@kit.edu>
 <c1155181-af9f-5305-0629-c5f045b837d1@auristor.com>
 <562792ce-4612-9e1b-c366-4077b1e81895@kit.edu>
 <2b7b1233-e92a-318a-f5c8-2f80d030a929@kit.edu>
Message-ID: <52f733a1-3f14-86bb-8ec7-a568f84ad29d@auristor.com>

This is a cryptographically signed message in MIME format.

--------------ms020600010405050006050302
Content-Type: multipart/mixed;
 boundary="------------60BD21DD58DAAD1B2FDAE353"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------60BD21DD58DAAD1B2FDAE353
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 6/15/2018 9:52 AM, Andreas Ladanyi wrote:
> ok. so the process of change CellSrvDB on db servers and bos restart AN=
D
> updating (copying) new CellServDB to clients has to be done in a very
> short time to minimize timeout symptoms for users, because db servers
> has to be in sync and ubik coordinator has to be elected and the afs
> clients with new CellServDB with the new db server (lowest ip) asks the=

> new db server (ubik coordinator) first.

The ubik clients do not rank servers based upon IP address.  What they
do is:

1. compute the length of the ordered server list

  A B C D

2. then generate a random number from 0..<length - 1>

3. use that number as an index into the list to decide which is first

4. and reorder the list as if it were a circular queue.  So if the
random number selected was 2, then the list would become

  C D A B

The only time the coordinator must be contacted is for a write
transaction.  All read transactions are processed by the first server
contacted.

My conclusion is that there is something about your cell configuration
that results in a write transaction for each token requested.  For exampl=
e:

 1. cell name:     		example.com

 2. One of the following is true:

    a. realm name: 		AD.EXAMPLE.COM

    b. CellServDB's zeroth ubik server host domain:

   				subnet.example.com

 3. auto-registration of foreign PTS IDs enabled:

    a. pam_afs_session configuration doesn't disable it

    b. aklog executed without -noprdb

If the "realm of cell" guessing algorithm decides that the current login
is likely to be a foreign cell login, then an attempt to allocate a PTS
ID for the authentication name will be performed.  This request is a
write transaction and the ubik client will attempt to contact every ubik
server in order until the coordinator is determined.

Jeffrey Altman


--------------60BD21DD58DAAD1B2FDAE353
Content-Type: text/x-vcard; charset=utf-8;
 name="jaltman.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="jaltman.vcf"

begin:vcard
fn:Jeffrey Altman
n:Altman;Jeffrey
org:AuriStor, Inc.
adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St=
ates
email;internet:jaltman@auristor.com
title:Founder and CEO
tel;work:+1-212-769-9018
note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman=
=3D0D=3D0A=3D
	Skype: jeffrey.e.altman=3D0D=3D0A=3D
=09
url:https://www.auristor.com/
version:2.1
end:vcard


--------------60BD21DD58DAAD1B2FDAE353--

--------------ms020600010405050006050302
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DIIwggXpMIIE0aADAgECAhBAAV7gPRitcrlGsJTzkwjvMA0GCSqGSIb3DQEBCwUAMDoxCzAJ
BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy
MB4XDTE3MTAwMzAzMTczM1oXDTE4MTEwMzAzMTczM1owgYUxLTArBgNVBAsMJFZlcmlmaWVk
IEVtYWlsOiBqYWx0bWFuQGF1cmlzdG9yLmNvbTEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBh
dXJpc3Rvci5jb20xLzAtBgoJkiaJk/IsZAEBEx9BMDE0MjdFMDAwMDAxNUVFMDNEMTg3QTAw
MDA0QUE1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqqJC89ZA1DSS7t/Ug8Dd
BQv5nBDumInWtFvHwVCORitVCvlkX4SfqKpERATq0eHOSc0zEz1PUjhAT8lgbNj8Bs92pL9t
DW/VHHpq11w06rCEmZJNxgErAIvMpRuAhGrzvBpQBLj8nDArHWw+5nRn/KnK7ZO81LEEj4TG
w0PEKGSa0aFA+JdRTJ6BZSDP2o/8AHx+Bw4JgW8VppAe4IuY/F+JoYtyQDL+fm1YMnFMtf1A
6IvlGXD7gMksPRbVIfD+QpHZbQvNXZAVVDaCWZuWQq46Vl4lSlkmW9yMlGddvFGl2zSMK7ny
f0kbWJLw9lZxXDegY0/ciJPACPsyBwuyLwIDAQABo4ICnTCCApkwDgYDVR0PAQH/BAQDAgWg
MIGEBggrBgEFBQcBAQR4MHYwMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJjaWFsLm9jc3Au
aWRlbnRydXN0LmNvbTBCBggrBgEFBQcwAoY2aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0
LmNvbS9jZXJ0cy90cnVzdGlkY2FhMTIucDdjMB8GA1UdIwQYMBaAFKRz2u9pNYp1zKAZewgy
+GuJ5ELsMAkGA1UdEwQCMAAwggEsBgNVHSAEggEjMIIBHzCCARsGC2CGSAGG+S8ABgsBMIIB
CjBKBggrBgEFBQcCARY+aHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0
ZXMvcG9saWN5L3RzL2luZGV4Lmh0bWwwgbsGCCsGAQUFBwICMIGuGoGrVGhpcyBUcnVzdElE
IENlcnRpZmljYXRlIGhhcyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdpdGggCklkZW5U
cnVzdCdzIFRydXN0SUQgQ2VydGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2Vj
dXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEUG
A1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL3Ry
dXN0aWRjYWExMi5jcmwwHwYDVR0RBBgwFoEUamFsdG1hbkBhdXJpc3Rvci5jb20wHQYDVR0O
BBYEFNefZrPaqPUvaS6V6kAmHDwFhoDiMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDANBgkqhkiG9w0BAQsFAAOCAQEAKlssrfOJ5+WwHyhFSeSsioN0qpg2QDX/uvodF38JbquO
1U0my0j3Cc/bwk48++bjzp0Fvk/Kkcmss5/6zzJMjr9rf12QCQfKkbO9nMm8Bg6IP3pYgk0W
/F1h3ZQF3OgBn3zZoOd3f1a6dF6z12MqKA/2g5GKrQFxkdzTGrNw6ISE9uY8ysvc3i2N2kas
HNi5Etk7StZ1jvFX5sQMIeNdlF+z+BU/AyT7NoBS4gCH+ggF+DG7fAYywvy42Lfu8p6kopKT
5JZpYce1cNjnOaDhzhgeR+oXxoDbekF27JinXHQSKjBxhujcZu5leAkpctFpZxnIKZJZUBiu
31Nm7xYaijCCBpEwggR5oAMCAQICEQD53lZ/yU0Md3D5YBtS2hU7MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVz
dCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAeFw0xNTAyMTgyMjI1MTlaFw0yMzAyMTgyMjI1MTla
MDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQg
Q0EgQTEyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0ZFNPM8KJzSSrkvpmtQl
a3ksT+fq1s9c+Ea3YSC/umUkygSm9UkkOoaoNjKZoCx3wef1kwC4pQQV2XHk+AKR+7uMvnOC
Iw2cAVUP0/Kuy4X6miqaXGGVDTqwVjaFuFCRVVDTQoI2BTMpwFQi+O/TjD5+E0+TAZbkzsB7
krk4YUbA6hFyT0YboxRUq9M2QHDb+80w53b1UZVO1HS2Mfk9LnINeyzjxiXU/iENK07YvjBO
xbY/ftAYPbv/9cY3wrpqZYHoXZc6B9/8+aVCNA45FP3k+YuTDC+ZrmePQBLQJWnyS/QrZEdX
saieWUqkUMxPQKTExArCiP61YRYlOIMpKwIDAQABo4ICgDCCAnwwgYkGCCsGAQUFBwEBBH0w
ezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEcG
CCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL3Jvb3RzL2NvbW1l
cmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C5yZUyI42djAPBgNV
HRMBAf8EBTADAQH/MIIBIAYDVR0gBIIBFzCCARMwggEPBgRVHSAAMIIBBTCCAQEGCCsGAQUF
BwICMIH0MEUWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3Bv
bGljeS90cy9pbmRleC5odG1sMAMCAQEagapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFz
IGJlZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENl
cnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29t
L2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBKBgNVHR8EQzBBMD+gPaA7hjlo
dHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC9jb21tZXJjaWFscm9vdGNhMS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBhjAdBgNV
HQ4EFgQUpHPa72k1inXMoBl7CDL4a4nkQuwwDQYJKoZIhvcNAQELBQADggIBAA3hgq7S+/Tr
Yxl+D7ExI1Rdgq8fC9kiT7ofWlSaK/IMjgjoDfBbPGWvzdkmbSgYgXo8GxuAon9+HLIjNv68
BgUmbIjwj/SYaVz6chA25XZdjxzKk+hUkqCmfOn/twQJeRfxHg3I+0Sfwp5xs10YF0Robhrs
CRne6OUmh9mph0fE3b21k90OVnx9Hfr+YAV4ISrTA6045zQTKGzb370whliPLFo+hNL6XzEt
y5hfdFaWKtHIfpE994CLmTJI4SEbWq40d7TpAjCmKCPIVPq/+9GqggGvtakM5K3VXNc9VtKP
U9xYGCTDIYoeVBQ65JsdsdyM4PzDzAdINsv4vaF7yE03nh2jLV7XAkcqad9vS4EB4hKjFFsm
cwxa+ACUfkVWtBaWBqN4f/o1thsFJHEAu4Q6oRB6mYkzqrPigPazF2rgYw3lp0B1gSzCRj+j
RtErIVdMPeZ2p5Fdx7SNhBtabuhqmpJkFxwW9SBg6sHvy0HpzVvEiBpApFKG1ZHXMwzQl+pR
8P27wWDsblJU7Qgb8ZzGRK9l5GOFhxtN+oXZ4CCmunLMtaZ2vSai7du/VKrg64GGZNAKerEB
evjJVNFgeSnmUK9GB4kCZ7U5NWlU+2H87scntW4Q/0Y6vqQJcJeaMHg/dQnahTQ2p+hB1xJJ
K32GWIAucTFMSOKLbQHadIOiMYIDFDCCAxACAQEwTjA6MQswCQYDVQQGEwJVUzESMBAGA1UE
ChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMgIQQAFe4D0YrXK5RrCU85MI
7zANBglghkgBZQMEAgEFAKCCAZcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTgwNjE1MTk1NjMxWjAvBgkqhkiG9w0BCQQxIgQgvVYwBrN85Y9K6aEcsch0
WU5zsEt/5OKcDUE3vcV/oXgwXQYJKwYBBAGCNxAEMVAwTjA6MQswCQYDVQQGEwJVUzESMBAG
A1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMgIQQAFe4D0YrXK5RrCU
85MI7zBfBgsqhkiG9w0BCRACCzFQoE4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5U
cnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABXuA9GK1yuUawlPOTCO8wbAYJKoZI
hvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq
hkiG9w0BAQEFAASCAQB22F7kuoHyxD+3zMF8UICTR/80zpCOPBL17C5YJHMf0lv9c7WvGJdb
osEocoyMIl+lWNvezuoJD0KZ43vX1mTRHQ54Ut5EOfZGF7FgIt1ZtK5MIdyVspibKBk1jIEr
2qDHWU+fOG9SdUCP2e1lZTo4qPl1wdsmmtoohbVEe3/F9UuyGz1PymlKgZOB9XIwU779+Lnw
/TNdHo5wPnso/9Jcy8wOblythp1N2OhzMsfN3Lf0g7NkZLOQalpOqTE90wJ3Cc6TZtn+m/sX
ZT6rRWEOL/7Gffjf2xy+ha+jtASEDtbAQWbV6na7scVkL+lK91UGKJ0WVWgcVIM2awwjAkUi
AAAAAAAA
--------------ms020600010405050006050302--


From andreas.ladanyi@kit.edu  Mon Jun 18 14:07:09 2018
From: andreas.ladanyi@kit.edu (Andreas Ladanyi)
Date: Mon, 18 Jun 2018 15:07:09 +0200
Subject: [OpenAFS] fs newcell / clients CellServDB / adding new db server
In-Reply-To: <52f733a1-3f14-86bb-8ec7-a568f84ad29d@auristor.com>
References: <669ae5e9-cad9-5a21-6a33-e7fcccaa3499@kit.edu>
 <c1155181-af9f-5305-0629-c5f045b837d1@auristor.com>
 <562792ce-4612-9e1b-c366-4077b1e81895@kit.edu>
 <2b7b1233-e92a-318a-f5c8-2f80d030a929@kit.edu>
 <52f733a1-3f14-86bb-8ec7-a568f84ad29d@auristor.com>
Message-ID: <7b13b833-f753-a8ec-0243-402c55d620ff@kit.edu>

>
> The ubik clients do not rank servers based upon IP address.  What they
> do is:
ok. Then maybe i misunderstood the documentation
(http://docs.openafs.org/QuickStartUnix/HDRWQ114.html) which tells me
the machine with lowest ip is "usually"  elected as the ubik coordinator.

I followed the instruction on this paper to add a new db server machine
with lowest ip.
>
> 1. compute the length of the ordered server list
>
>   A B C D
>
> 2. then generate a random number from 0..<length - 1>
>
> 3. use that number as an index into the list to decide which is first
>
> 4. and reorder the list as if it were a circular queue.  So if the
> random number selected was 2, then the list would become
>
>   C D A B
>
> The only time the coordinator must be contacted is for a write
> transaction.  All read transactions are processed by the first server
> contacted.
ok. thanks for explanation.
>
> My conclusion is that there is something about your cell configuration
> that results in a write transaction for each token requested.  For example:
I straced aklog for some tests and could see if aklog sometimes ask the
new db server (which is offline) and then wait for a timeout (hangs
about 15 sec) and if ask the old online db servers from CellServDB
without timeout (hang).

This seems to cause the ssh login hanging symptom because pam debug
shows me hanging about 15 sec when pam_afs calls aklog.

So on summary it seems to be better to first add the new db server to
all db servers CellServDB / bos addhost and to bos restart the pt/vl
instances for ubik corrdinator election on the servers and then to
update the clients CellServDB.

The documentation tells to first update clients CellServDB (when new db
server with lowest ip) and then bring up new db server.
>
>  1. cell name:     		example.com
no, cellname a.b.c
>
>  2. One of the following is true:
>
>     a. realm name: 		AD.EXAMPLE.COM
no AD

REALM = A.B.C, MIT Kerberos
>
>     b. CellServDB's zeroth ubik server host domain:
>
>    				subnet.example.com
I dont understand this example.
>
>  3. auto-registration of foreign PTS IDs enabled:
>
>     a. pam_afs_session configuration doesn't disable it
>
>     b. aklog executed without -noprdb
yes, pam_afs_session calls aklog without -noprdb
>
> If the "realm of cell" guessing algorithm decides that the current login
> is likely to be a foreign cell login, then an attempt to allocate a PTS
> ID for the authentication name will be performed.  This request is a
> write transaction and the ubik client will attempt to contact every ubik
> server in order until the coordinator is determined.
>
> Jeffrey Altman
>
Andi

From jaltman@auristor.com  Mon Jun 18 14:34:32 2018
From: jaltman@auristor.com (Jeffrey Altman)
Date: Mon, 18 Jun 2018 09:34:32 -0400
Subject: [OpenAFS] fs newcell / clients CellServDB / adding new db server
In-Reply-To: <7b13b833-f753-a8ec-0243-402c55d620ff@kit.edu>
References: <669ae5e9-cad9-5a21-6a33-e7fcccaa3499@kit.edu>
 <c1155181-af9f-5305-0629-c5f045b837d1@auristor.com>
 <562792ce-4612-9e1b-c366-4077b1e81895@kit.edu>
 <2b7b1233-e92a-318a-f5c8-2f80d030a929@kit.edu>
 <52f733a1-3f14-86bb-8ec7-a568f84ad29d@auristor.com>
 <7b13b833-f753-a8ec-0243-402c55d620ff@kit.edu>
Message-ID: <c28c3987-636c-a457-bcc0-4393eca63b05@auristor.com>

This is a cryptographically signed message in MIME format.

--------------ms050107020501040004040302
Content-Type: multipart/mixed;
 boundary="------------98D357B1AEA9A716811EE50F"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------98D357B1AEA9A716811EE50F
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 6/18/2018 9:07 AM, Andreas Ladanyi wrote:
>>
>> The ubik clients do not rank servers based upon IP address.  What they=

>> do is:
> ok. Then maybe i misunderstood the documentation
> (http://docs.openafs.org/QuickStartUnix/HDRWQ114.html) which tells me
> the machine with lowest ip is "usually"=C2=A0 elected as the ubik coord=
inator.

The algorithm used to elect the coordinator is specific to the ubik
servers that maintain a synchronized database.  The clients (vos, pts,
cache managers, backup, aklog, pam_afs_session, etc) do not speak ubik;
they speak the application specific protocols (VL, PR, BUDB, etc.).  The
clients do not have any visibility into which ubik instances are
electable, which instances have network connectivity to elicit
sufficient votes, nor what algorithm is used to rank (order) the ubik
instances for election purposes.

AuriStorFS ubik for example permits arbitrary ranking of servers based
upon configuration.  Just because a server has a smaller numeric IPv4
address doesn't mean that it is the best server to be the read/write
copy of the database.

> I followed the instruction on this paper to add a new db server machine=

> with lowest ip.
>>
>> 1. compute the length of the ordered server list
>>
>>   A B C D
>>
>> 2. then generate a random number from 0..<length - 1>
>>
>> 3. use that number as an index into the list to decide which is first
>>
>> 4. and reorder the list as if it were a circular queue.  So if the
>> random number selected was 2, then the list would become
>>
>>   C D A B
>>
>> The only time the coordinator must be contacted is for a write
>> transaction.  All read transactions are processed by the first server
>> contacted.
> ok. thanks for explanation.
>>
>> My conclusion is that there is something about your cell configuration=

>> that results in a write transaction for each token requested.  For exa=
mple:
> I straced aklog for some tests and could see if aklog sometimes ask the=

> new db server (which is offline) and then wait for a timeout (hangs
> about 15 sec) and if ask the old online db servers from CellServDB
> without timeout (hang).
>=20
> This seems to cause the ssh login hanging symptom because pam debug
> shows me hanging about 15 sec when pam_afs calls aklog.
>=20
> So on summary it seems to be better to first add the new db server to
> all db servers CellServDB / bos addhost and to bos restart the pt/vl
> instances for ubik corrdinator election on the servers and then to
> update the clients CellServDB.

That depends on whether or not the clients need to be able to find a
writable copy of the database or not.  If the clients must be able to
find the coordinator and the coordinator is a server that is not present
in the client's configuration, then the client won't simply experience a
random timeout but a failure.

> The documentation tells to first update clients CellServDB (when new db=

> server with lowest ip) and then bring up new db server.
>>
>>  1. cell name:     		example.com
> no, cellname a.b.c
>>
>>  2. One of the following is true:
>>
>>     a. realm name: 		AD.EXAMPLE.COM
> no AD
>=20
> REALM =3D A.B.C, MIT Kerberos
>>
>>     b. CellServDB's zeroth ubik server host domain:
>>
>>    				subnet.example.com
> I dont understand this example.


If the cell name is

   foo.example.com

and the Kerberos realm is

   FOO.EXAMPLE.COM

and the host names of the ubik servers are

   afsdb1.bar.example.com
   afsdb2.bar.example.com
   afsdb3.bar.example.com

then the default host to realm mapping of afsdb1.bar.example.com will be
to realm BAR.EXAMPLE.COM not FOO.EXAMPLE.COM.  Since BAR.EXAMPLE.COM !=3D=

FOO.EXAMPLE.COM a foreign cell registration will be attempted.  However,
that doesn't appear to be the source of the delay.  If it were, the
tracing would show aklog attempting to access every protection server
until the coordinator was discovered.

>>  3. auto-registration of foreign PTS IDs enabled:
>>
>>     a. pam_afs_session configuration doesn't disable it
>>
>>     b. aklog executed without -noprdb
> yes, pam_afs_session calls aklog without -noprdb




--------------98D357B1AEA9A716811EE50F
Content-Type: text/x-vcard; charset=utf-8;
 name="jaltman.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="jaltman.vcf"

begin:vcard
fn:Jeffrey Altman
n:Altman;Jeffrey
org:AuriStor, Inc.
adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St=
ates
email;internet:jaltman@auristor.com
title:Founder and CEO
tel;work:+1-212-769-9018
note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman=
=3D0D=3D0A=3D
	Skype: jeffrey.e.altman=3D0D=3D0A=3D
=09
url:https://www.auristor.com/
version:2.1
end:vcard


--------------98D357B1AEA9A716811EE50F--

--------------ms050107020501040004040302
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DIIwggXpMIIE0aADAgECAhBAAV7gPRitcrlGsJTzkwjvMA0GCSqGSIb3DQEBCwUAMDoxCzAJ
BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy
MB4XDTE3MTAwMzAzMTczM1oXDTE4MTEwMzAzMTczM1owgYUxLTArBgNVBAsMJFZlcmlmaWVk
IEVtYWlsOiBqYWx0bWFuQGF1cmlzdG9yLmNvbTEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBh
dXJpc3Rvci5jb20xLzAtBgoJkiaJk/IsZAEBEx9BMDE0MjdFMDAwMDAxNUVFMDNEMTg3QTAw
MDA0QUE1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqqJC89ZA1DSS7t/Ug8Dd
BQv5nBDumInWtFvHwVCORitVCvlkX4SfqKpERATq0eHOSc0zEz1PUjhAT8lgbNj8Bs92pL9t
DW/VHHpq11w06rCEmZJNxgErAIvMpRuAhGrzvBpQBLj8nDArHWw+5nRn/KnK7ZO81LEEj4TG
w0PEKGSa0aFA+JdRTJ6BZSDP2o/8AHx+Bw4JgW8VppAe4IuY/F+JoYtyQDL+fm1YMnFMtf1A
6IvlGXD7gMksPRbVIfD+QpHZbQvNXZAVVDaCWZuWQq46Vl4lSlkmW9yMlGddvFGl2zSMK7ny
f0kbWJLw9lZxXDegY0/ciJPACPsyBwuyLwIDAQABo4ICnTCCApkwDgYDVR0PAQH/BAQDAgWg
MIGEBggrBgEFBQcBAQR4MHYwMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJjaWFsLm9jc3Au
aWRlbnRydXN0LmNvbTBCBggrBgEFBQcwAoY2aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0
LmNvbS9jZXJ0cy90cnVzdGlkY2FhMTIucDdjMB8GA1UdIwQYMBaAFKRz2u9pNYp1zKAZewgy
+GuJ5ELsMAkGA1UdEwQCMAAwggEsBgNVHSAEggEjMIIBHzCCARsGC2CGSAGG+S8ABgsBMIIB
CjBKBggrBgEFBQcCARY+aHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0
ZXMvcG9saWN5L3RzL2luZGV4Lmh0bWwwgbsGCCsGAQUFBwICMIGuGoGrVGhpcyBUcnVzdElE
IENlcnRpZmljYXRlIGhhcyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdpdGggCklkZW5U
cnVzdCdzIFRydXN0SUQgQ2VydGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2Vj
dXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEUG
A1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL3Ry
dXN0aWRjYWExMi5jcmwwHwYDVR0RBBgwFoEUamFsdG1hbkBhdXJpc3Rvci5jb20wHQYDVR0O
BBYEFNefZrPaqPUvaS6V6kAmHDwFhoDiMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDANBgkqhkiG9w0BAQsFAAOCAQEAKlssrfOJ5+WwHyhFSeSsioN0qpg2QDX/uvodF38JbquO
1U0my0j3Cc/bwk48++bjzp0Fvk/Kkcmss5/6zzJMjr9rf12QCQfKkbO9nMm8Bg6IP3pYgk0W
/F1h3ZQF3OgBn3zZoOd3f1a6dF6z12MqKA/2g5GKrQFxkdzTGrNw6ISE9uY8ysvc3i2N2kas
HNi5Etk7StZ1jvFX5sQMIeNdlF+z+BU/AyT7NoBS4gCH+ggF+DG7fAYywvy42Lfu8p6kopKT
5JZpYce1cNjnOaDhzhgeR+oXxoDbekF27JinXHQSKjBxhujcZu5leAkpctFpZxnIKZJZUBiu
31Nm7xYaijCCBpEwggR5oAMCAQICEQD53lZ/yU0Md3D5YBtS2hU7MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVz
dCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAeFw0xNTAyMTgyMjI1MTlaFw0yMzAyMTgyMjI1MTla
MDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQg
Q0EgQTEyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0ZFNPM8KJzSSrkvpmtQl
a3ksT+fq1s9c+Ea3YSC/umUkygSm9UkkOoaoNjKZoCx3wef1kwC4pQQV2XHk+AKR+7uMvnOC
Iw2cAVUP0/Kuy4X6miqaXGGVDTqwVjaFuFCRVVDTQoI2BTMpwFQi+O/TjD5+E0+TAZbkzsB7
krk4YUbA6hFyT0YboxRUq9M2QHDb+80w53b1UZVO1HS2Mfk9LnINeyzjxiXU/iENK07YvjBO
xbY/ftAYPbv/9cY3wrpqZYHoXZc6B9/8+aVCNA45FP3k+YuTDC+ZrmePQBLQJWnyS/QrZEdX
saieWUqkUMxPQKTExArCiP61YRYlOIMpKwIDAQABo4ICgDCCAnwwgYkGCCsGAQUFBwEBBH0w
ezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEcG
CCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL3Jvb3RzL2NvbW1l
cmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C5yZUyI42djAPBgNV
HRMBAf8EBTADAQH/MIIBIAYDVR0gBIIBFzCCARMwggEPBgRVHSAAMIIBBTCCAQEGCCsGAQUF
BwICMIH0MEUWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3Bv
bGljeS90cy9pbmRleC5odG1sMAMCAQEagapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFz
IGJlZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENl
cnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29t
L2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBKBgNVHR8EQzBBMD+gPaA7hjlo
dHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC9jb21tZXJjaWFscm9vdGNhMS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBhjAdBgNV
HQ4EFgQUpHPa72k1inXMoBl7CDL4a4nkQuwwDQYJKoZIhvcNAQELBQADggIBAA3hgq7S+/Tr
Yxl+D7ExI1Rdgq8fC9kiT7ofWlSaK/IMjgjoDfBbPGWvzdkmbSgYgXo8GxuAon9+HLIjNv68
BgUmbIjwj/SYaVz6chA25XZdjxzKk+hUkqCmfOn/twQJeRfxHg3I+0Sfwp5xs10YF0Robhrs
CRne6OUmh9mph0fE3b21k90OVnx9Hfr+YAV4ISrTA6045zQTKGzb370whliPLFo+hNL6XzEt
y5hfdFaWKtHIfpE994CLmTJI4SEbWq40d7TpAjCmKCPIVPq/+9GqggGvtakM5K3VXNc9VtKP
U9xYGCTDIYoeVBQ65JsdsdyM4PzDzAdINsv4vaF7yE03nh2jLV7XAkcqad9vS4EB4hKjFFsm
cwxa+ACUfkVWtBaWBqN4f/o1thsFJHEAu4Q6oRB6mYkzqrPigPazF2rgYw3lp0B1gSzCRj+j
RtErIVdMPeZ2p5Fdx7SNhBtabuhqmpJkFxwW9SBg6sHvy0HpzVvEiBpApFKG1ZHXMwzQl+pR
8P27wWDsblJU7Qgb8ZzGRK9l5GOFhxtN+oXZ4CCmunLMtaZ2vSai7du/VKrg64GGZNAKerEB
evjJVNFgeSnmUK9GB4kCZ7U5NWlU+2H87scntW4Q/0Y6vqQJcJeaMHg/dQnahTQ2p+hB1xJJ
K32GWIAucTFMSOKLbQHadIOiMYIDFDCCAxACAQEwTjA6MQswCQYDVQQGEwJVUzESMBAGA1UE
ChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMgIQQAFe4D0YrXK5RrCU85MI
7zANBglghkgBZQMEAgEFAKCCAZcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTgwNjE4MTMzNDMyWjAvBgkqhkiG9w0BCQQxIgQgMRlDqcdX7RWkBW59mJeV
z2MPTsRjmlYLQ0bjbvDDvKYwXQYJKwYBBAGCNxAEMVAwTjA6MQswCQYDVQQGEwJVUzESMBAG
A1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMgIQQAFe4D0YrXK5RrCU
85MI7zBfBgsqhkiG9w0BCRACCzFQoE4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5U
cnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABXuA9GK1yuUawlPOTCO8wbAYJKoZI
hvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq
hkiG9w0BAQEFAASCAQB/drkGGZAHvEYw6cHxUZJ5dE9zAX1rIP85wMETwy8rGrbyBT29vVRC
i27Kwcv7VcNYcxhewrMThfVY68LkZO9ADeuJnNifEWYp98zAlYD5eJGIkOABfoG9IsyMGHqL
Fs6q22n+g+BW/uEK0n+ZDaMA+BPkeGLabHgma8EodrXt8usyWnUcYQtYoHjf3g3JX/x9MSku
lfLjtCOzYk1gukBROxukAcBQcpZk4kps239RRJy1vBzF69JChpsos0kj5i0CH9wNt3Nb2wPr
oQaEzBVEFKEYreC3boq2CY3+S2pichoHBgCCw4hHboqm3eaRwSvOxEby8vEY5kgT19p3sR9x
AAAAAAAA
--------------ms050107020501040004040302--


From jblaine@kickflop.net  Tue Jun 19 14:40:29 2018
From: jblaine@kickflop.net (Jeff Blaine)
Date: Tue, 19 Jun 2018 09:40:29 -0400
Subject: [OpenAFS] Tired of sec tools recursively traversing /afs?
Message-ID: <668f3905-9435-3e48-86d9-209204165aa6@kickflop.net>

Hello,

df --local shows /afs in the listing.

Many security tools use 'df --local' to determine local filesystems to
traverse recursively.

If you're like me, you're tired of security tools traversing the
local-but-NOT-LOCAL /afs mountpoint.

I've opened a ticket with the Center for Internet Security (CIS, whose
"benchmark" documents are the basis for myriad security tools' check
scripts) at https://workbench.cisecurity.org/community/17/tickets/6518
but do not personally intend to follow up much on said ticket as our AFS
days are numbered less than 100 or so.

So I got the ball rolling... please consider joining said benchmark
community to add your voice on the ticket if you care about getting this
fixed at the major root of origin.

Jeff

From fmsv030@uni-hamburg.de  Thu Jun 14 10:09:33 2018
From: fmsv030@uni-hamburg.de (Gaja Sophie Peters)
Date: Thu, 14 Jun 2018 11:09:33 +0200
Subject: [OpenAFS] Windows 10, KDC not reachable / AFS integrated login
 failed
In-Reply-To: <95033ca8-bfc4-6fa4-36d4-fd2f82db8b17@kit.edu>
References: <95033ca8-bfc4-6fa4-36d4-fd2f82db8b17@kit.edu>
Message-ID: <d8662520-1890-be9d-4caa-ff856c5fd01d@uni-hamburg.de>

Am 30.01.2018 um 14:09 schrieb Andreas Ladanyi:

> Windows 10 Pro , Auristor AFS client package
> 
> When starting the device and before login screen appears the messages
> appears: [snip]
> 
> AFS integrated login failed
> 
> before it is possible to enter credentials at windows login box (display
> manager).

This is a rather late answer, but since I just happened to stumble again 
over the solution, I thought I'd post it here in case it is still useful 
for anybody.

> Is it possible to start kerberos client and afs client after entering
> the credentials at windows 10 ?

Yes, that is possible. The solution is basically what is posted on this 
website:

https://www.tenforums.com/tutorials/49963-use-sign-info-auto-finish-after-update-restart-windows-10-a.html

Apparently, Windows 10 since some version is able to "remember" 
login-credentials over a reboot, and will use these internal credentials 
to sign-in to windows even before you enter the password. This 
unfortunately triggers also the "integrated login" to AFS, but since 
there is no password for it to work with, it will fail.

Once this option in Windows is disabled, Windows will not try to do an 
integrated login without password and everything is ok.

Greetings,
Gaja Peters

From andreas.ladanyi@kit.edu  Tue Jun 26 09:33:24 2018
From: andreas.ladanyi@kit.edu (Andreas Ladanyi)
Date: Tue, 26 Jun 2018 10:33:24 +0200
Subject: [OpenAFS] fs newcell / clients CellServDB / adding new db server
In-Reply-To: <c28c3987-636c-a457-bcc0-4393eca63b05@auristor.com>
References: <669ae5e9-cad9-5a21-6a33-e7fcccaa3499@kit.edu>
 <c1155181-af9f-5305-0629-c5f045b837d1@auristor.com>
 <562792ce-4612-9e1b-c366-4077b1e81895@kit.edu>
 <2b7b1233-e92a-318a-f5c8-2f80d030a929@kit.edu>
 <52f733a1-3f14-86bb-8ec7-a568f84ad29d@auristor.com>
 <7b13b833-f753-a8ec-0243-402c55d620ff@kit.edu>
 <c28c3987-636c-a457-bcc0-4393eca63b05@auristor.com>
Message-ID: <718311ea-525d-5df8-9279-4c2db4c8673b@kit.edu>

Hi Jeffrey,

i want to give a little feedback.

We finished the job. We bos added and then restarted / startet the pt/vl
servers beginning with lowest ip. The new ubik election and syncing
works great.

We distributed the CellServDB to clients and the execution of "fs
newcell"  with ansible. This also works great.

Is there a funtion / service in afs to manage clients cellservdb ? I
understand upclient/upserver are for servers only.

regards,
Andreas

From kaduk@mit.edu  Tue Jun 26 15:37:41 2018
From: kaduk@mit.edu (Benjamin Kaduk)
Date: Tue, 26 Jun 2018 09:37:41 -0500
Subject: [OpenAFS] fs newcell / clients CellServDB / adding new db server
In-Reply-To: <718311ea-525d-5df8-9279-4c2db4c8673b@kit.edu>
References: <669ae5e9-cad9-5a21-6a33-e7fcccaa3499@kit.edu>
 <c1155181-af9f-5305-0629-c5f045b837d1@auristor.com>
 <562792ce-4612-9e1b-c366-4077b1e81895@kit.edu>
 <2b7b1233-e92a-318a-f5c8-2f80d030a929@kit.edu>
 <52f733a1-3f14-86bb-8ec7-a568f84ad29d@auristor.com>
 <7b13b833-f753-a8ec-0243-402c55d620ff@kit.edu>
 <c28c3987-636c-a457-bcc0-4393eca63b05@auristor.com>
 <718311ea-525d-5df8-9279-4c2db4c8673b@kit.edu>
Message-ID: <20180626143741.GB79565@kduck.kaduk.org>

On Tue, Jun 26, 2018 at 10:33:24AM +0200, Andreas Ladanyi wrote:
> 
> Is there a funtion / service in afs to manage clients cellservdb ? I
> understand upclient/upserver are for servers only.

The most scalable way seems to be to not use hardcoded CellServDB entries
and instead use DNS SRV records to locate the database servers.

-Ben