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 alan.mckin...@gmail.com
