[OpenAFS] Re: AFS Perl Modules and Ubuntu
Phillip Moore
w.phillip.moore@gmail.com
Thu, 11 Sep 2014 14:28:28 -0400
--20cf300fad8fbe8c100502ce5588
Content-Type: text/plain; charset=UTF-8
I will briefly crawl out from under my rock to point out the existence of
my AFS::Command CPAN modules, which provide a pretty decent OO API to those
commands, and they handle all of the ugly CLI parsing for you.
http://search.cpan.org/~wpmoore/AFS-Command-1.99/lib/AFS/Command.pod
We have built a very large quantity of enterprise-class systems management
software using this API. There's a good chance it will work for you, if
your primary goal is automating the use of bos, vos, fs, etc.
What my modules do NOT have are things like setpag(). If I ever get back
into working on OpenAFS again (probability totally indeterminate), the
first time I need setpag(), I will code up a standalone perl module that
provides that, independent of the very broken AFS.pm distribution. When
that code was written, and first presented at the AFS/Kerberos workshop, I
railed long and loud (much to the annoyance of the author) that this
cut/paste approach to implementing those modules was a strategic disaster.
The fact that we haven't had a working version since the release of 1.6
proves I was right (sorry for gloating.... can't help it... :-P)
Anyway, please consider using AFS::Command as alternative.
On Fri, Sep 5, 2014 at 8:50 PM, Russ Allbery <eagle@eyrie.org> wrote:
> Benjamin Kaduk <kaduk@MIT.EDU> writes:
>
> > I have a vague recollection that the AFS perl modules only worked with
> > openafs 1.4, but have nothing to support that at hand. Maybe someone
> > else has a better memory than me...
>
> That's correct. That's also why they're not in Debian and Ubuntu. They
> were broken by a combination of Perl switching to natively multithreading
> and some really ugly hacks that linked LWP code with pthread code no
> longer working around the 1.6 time frame.
>
> Even if you manage to get the modules to build, they'll just randomly
> segfault. At Stanford, we rewrote all the software that used them to
> parse command-line output instead.
>
> They should work again once OpenAFS is 100% pthreads, but as long as they
> require linking LWP code and pthread code together, they're probably not
> going to work.
>
> --
> Russ Allbery (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
--20cf300fad8fbe8c100502ce5588
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I will briefly crawl out from under my rock to point out t=
he existence of my AFS::Command CPAN modules, which provide a pretty decent=
OO API to those commands, and they handle all of the ugly CLI parsing for =
you. =C2=A0=C2=A0<div><br></div><div><a href=3D"http://search.cpan.org/~wpm=
oore/AFS-Command-1.99/lib/AFS/Command.pod">http://search.cpan.org/~wpmoore/=
AFS-Command-1.99/lib/AFS/Command.pod</a><br></div><div><br></div><div>We ha=
ve built a very large quantity of enterprise-class systems management softw=
are using this API. =C2=A0 =C2=A0There's a good chance it will work for=
you, if your primary goal is automating the use of bos, vos, fs, etc.</div=
><div><br></div><div>What my modules do NOT have are things like setpag(). =
=C2=A0 If I ever get back into working on OpenAFS again (probability totall=
y indeterminate), the first time I need setpag(), I will code up a standalo=
ne perl module that provides that, independent of the very broken AFS.pm di=
stribution. =C2=A0 =C2=A0When that code was written, and first presented at=
the AFS/Kerberos workshop, I railed long and loud (much to the annoyance o=
f the author) that this cut/paste approach to implementing those modules wa=
s a strategic disaster. =C2=A0 =C2=A0The fact that we haven't had a wor=
king version since the release of 1.6 proves I was right (sorry for gloatin=
g.... can't help it... :-P)</div><div><br></div><div>Anyway, please con=
sider using AFS::Command as alternative.</div></div><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote">On Fri, Sep 5, 2014 at 8:50 PM, Russ All=
bery <span dir=3D"ltr"><<a href=3D"mailto:eagle@eyrie.org" target=3D"_bl=
ank">eagle@eyrie.org</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><span class=3D"">Benjamin Kaduk <<a href=3D"mailto:kaduk@MIT.EDU">kadu=
k@MIT.EDU</a>> writes:<br>
<br>
> I have a vague recollection that the AFS perl modules only worked with=
<br>
> openafs 1.4, but have nothing to support that at hand.=C2=A0 Maybe som=
eone<br>
> else has a better memory than me...<br>
<br>
</span>That's correct.=C2=A0 That's also why they're not in Deb=
ian and Ubuntu.=C2=A0 They<br>
were broken by a combination of Perl switching to natively multithreading<b=
r>
and some really ugly hacks that linked LWP code with pthread code no<br>
longer working around the 1.6 time frame.<br>
<br>
Even if you manage to get the modules to build, they'll just randomly<b=
r>
segfault.=C2=A0 At Stanford, we rewrote all the software that used them to<=
br>
parse command-line output instead.<br>
<br>
They should work again once OpenAFS is 100% pthreads, but as long as they<b=
r>
require linking LWP code and pthread code together, they're probably no=
t<br>
going to work.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Russ Allbery (<a href=3D"mailto:eagle@eyrie.org">eagle@eyrie.org</a>)=C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"http://www.eyrie.=
org/~eagle/" target=3D"_blank">http://www.eyrie.org/~eagle/</a>><br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">_____________________=
__________________________<br>
OpenAFS-info mailing list<br>
<a href=3D"mailto:OpenAFS-info@openafs.org">OpenAFS-info@openafs.org</a><br=
>
<a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-info" target=
=3D"_blank">https://lists.openafs.org/mailman/listinfo/openafs-info</a><br>
</div></div></blockquote></div><br></div>
--20cf300fad8fbe8c100502ce5588--