Slightly OT: FreeBSD migration, what to do with /usr/local

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Slightly OT: FreeBSD migration, what to do with /usr/local

Ian Zimmerman-3
I think I have written here previously that I want to move my _server_
to FreeBSD.  I am still thinking about that.  But now I hit an
obstacle.  For a long time, I have put my local kiddie scripts in
/usr/local.  For better or worse, they are written in my dense style
where any code duplication is avoided, and so they call one another a
lot.

But as you know FreeBSD directory hierarchy is different: /usr/local is
for Packages and Ports.  I must move my scripts somewhere else to not
conflict with P & P.  So the first problem is to come up with a
location.  What does a typical BSD admin do in this situation?  I don't
want to put them in my home directory because they're general purpose;
at the very least I use them both as root and as an unprivileged user.

A more serious problem is how to find all the situations where
/usr/local is baked in.  It's not as simple as grep because when I
could, I relied on the implicit PATH which would be configured somewhere
else, or it might not even be configured - it might be compiled in (I
think this is the case for some programs in the shadow package, and
perhaps PAM modules).

I don't think I can expect a simple answer, but if you ever faced such
transition yourself, how did you approach it?

--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

Reply | Threaded
Open this post in threaded view
|

Re: Slightly OT: FreeBSD migration, what to do with /usr/local

Alan McKinnon-2
On 12/10/2017 08:29, Ian Zimmerman wrote:

> I think I have written here previously that I want to move my _server_
> to FreeBSD.  I am still thinking about that.  But now I hit an
> obstacle.  For a long time, I have put my local kiddie scripts in
> /usr/local.  For better or worse, they are written in my dense style
> where any code duplication is avoided, and so they call one another a
> lot.
>
> But as you know FreeBSD directory hierarchy is different: /usr/local is
> for Packages and Ports.  I must move my scripts somewhere else to not
> conflict with P & P.  So the first problem is to come up with a
> location.  What does a typical BSD admin do in this situation?  I don't
> want to put them in my home directory because they're general purpose;
> at the very least I use them both as root and as an unprivileged user.

I have a few hundred FreeBSD servers and I put my own stuff in
/usr/local/, just like I would on on Linux. I haven't yet had any
filename collisions, that's probably because I'm aware of the problem
upfront and I name my scripts in a style that no sane upstream would
ever use i.e. be verbose :-)

So far I've never had a problem. Maybe I've just been lucky - who knows?

This seems to be the norm, at least amongst the FreeBSD admins I've
talked to.

> A more serious problem is how to find all the situations where
> /usr/local is baked in.  It's not as simple as grep because when I
> could, I relied on the implicit PATH which would be configured somewhere
> else, or it might not even be configured - it might be compiled in (I
> think this is the case for some programs in the shadow package, and
> perhaps PAM modules).

Not sure what the context is here. Are you talking about packages and
ports code, or your own stuff you compiled yourself?

Either way, what problem were you asking about by writing that paragraphs?

> I don't think I can expect a simple answer, but if you ever faced such
> transition yourself, how did you approach it?

I approach these problems with backups and test staging machines. But I
have fleets of spare hypervisors at my disposal, you might not have that.


--
Alan McKinnon
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD migration, what to do with /usr/local

Thomas Mueller-2
In reply to this post by Ian Zimmerman-3
from Ian Zimmerman:

> I think I have written here previously that I want to move my _server_
> to FreeBSD.  I am still thinking about that.  But now I hit an
> obstacle.  For a long time, I have put my local kiddie scripts in
> /usr/local.  For better or worse, they are written in my dense style
> where any code duplication is avoided, and so they call one another a
> lot.
       
> But as you know FreeBSD directory hierarchy is different: /usr/local is
> for Packages and Ports.  I must move my scripts somewhere else to not
> conflict with P & P.  So the first problem is to come up with a
> location.  What does a typical BSD admin do in this situation?  I don't
> want to put them in my home directory because they're general purpose;
> at the very least I use them both as root and as an unprivileged user.

> A more serious problem is how to find all the situations where
> /usr/local is baked in.  It's not as simple as grep because when I
> could, I relied on the implicit PATH which would be configured somewhere
> else, or it might not even be configured - it might be compiled in (I
> think this is the case for some programs in the shadow package, and
> perhaps PAM modules).

> I don't think I can expect a simple answer, but if you ever faced such
> transition yourself, how did you approach it?

/usr/local is the default LOCALBASE in FreeBSD, but I believe you can set LOCALBASE to something else in your environment, which could be set in /etc/make.conf .

You could possibly copy Gentoo scripts to /usr/local/gentoo-scripts, or would that not work with your scripts as set up?

You would have to be careful setting up your PATH in .profile and /etc/profile , to make sure it includes the proper LOCALBASE.

Tom



Reply | Threaded
Open this post in threaded view
|

Re: Slightly OT: FreeBSD migration, what to do with /usr/local

Ian Zimmerman-3
In reply to this post by Alan McKinnon-2
On 2017-10-12 08:36, Alan McKinnon wrote:

> > A more serious problem is how to find all the situations where
> > /usr/local is baked in.  It's not as simple as grep because when I
> > could, I relied on the implicit PATH which would be configured
> > somewhere else, or it might not even be configured - it might be
> > compiled in (I think this is the case for some programs in the
> > shadow package, and perhaps PAM modules).
>
> Not sure what the context is here. Are you talking about packages and
> ports code, or your own stuff you compiled yourself?
>
> Either way, what problem were you asking about by writing that
> paragraphs?

GNU/Linux packages that set the PATH, on which my script stuff ends up
relying.  If I just move my scripts to, say, /opt/foobar, and edit the
all the occurences of "/usr/local", something will still break because a
script that is found now by virtue of the ambient PATH won't be found in
the new world.

--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD migration, what to do with /usr/local

Ian Zimmerman-3
In reply to this post by Ian Zimmerman-3
On 2017-10-12 07:11, Thomas Mueller wrote:

> You could possibly copy Gentoo scripts to /usr/local/gentoo-scripts,
> or would that not work with your scripts as set up?
>
> You would have to be careful setting up your PATH in .profile and
> /etc/profile , to make sure it includes the proper LOCALBASE.

But this is not enough: this is exactly what I mean in my penultimate
paragraph.  What about cron, for example?  I think the Linux crons put
/usr/local/{bin,sbin} in the PATH of the jobs.  Now I have to worry
about the new location also being included.

Similarly with ssh (when not interactive, so .profile is not read), and
so on yada yada.

--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.