need managed tools/software infrastructure

CLOSED FIXED

Status

P3
enhancement
CLOSED FIXED
20 years ago
4 years ago

People

(Reporter: friedman, Assigned: rkotalampi)

Tracking

Details

(Reporter)

Description

20 years ago
Right now each host has its own set of installed programs, which
makes updating them a hassle.  It might be nice to do something
similar to Netscape's internal lude repository.  Even if mozilla.org
doesn't use NFS to share tools, they could be rsyced from a
designated master server.

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 1

20 years ago
Noah, can you give me a few more details?
I've entered this in the IS helpdesk database as call #193648.
(Assignee)

Updated

19 years ago
Assignee: mitchell → rko
Status: ASSIGNED → NEW
(Assignee)

Updated

19 years ago
Component: Miscellaneous → Server Operations
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

19 years ago
Summary: need managedtools/software infrastructure → need managed tools/software infrastructure
(Assignee)

Comment 3

19 years ago
Maybe we can get back to this finally.

The idea here was that we would have mirrored parts of /tools/ns from Netscape's
Intranet. Problem: IS haven't had resources to maintain that area very well. For
example emacs is 19.33.1, gcc 2.7.2.1, etc.

So, what I'm suggesting here is that I will just start maintaining our own
software base. In San Mateo I used to divide programs to /opt/gnu/bin (pure GNU
software from ftp.gnu.org) and others to /opt/local/bin or /usr/local/bin - so
those will be two paths to add to your paths. We don't really need Lude
(overkill, we only have one architecture) for simple task like this and can use
Gnu's "stow" to achieve same. Those software would be mirrored identically to
each hosts (maybe not gila before we get more disk to it - or dump it).

But what I need now is list of software we should install to those hosts.

Comments?
(Assignee)

Comment 4

19 years ago
/opt/gnu can be now found from each server. Following packages are installed at
the moment. These packages are in /opt/gnu/files, and from there stowed to
/opt/gnu. Ie. adding /opt/gnu/bin to path will do the magic.

automake-1.4    cvs-1.10        lynx-2.8.2      screen-3.7.6
bash-2.03       emacs-20.5a     make-3.78.1     stow-1.3.2
binutils-2.9.1  gcc-2.95.2      perl-5.005.03   tar-1.13
bison-1.28      gzip-1.2.4a     rcs-5.7         wget-1.5.3

Master files are in /u/rko/gnu but eventually we need to find better place for
these.
(Assignee)

Comment 5

19 years ago
Ok, another PATH to add is /opt/tools/bin. I didn't want to mess with existing 
/opt/local/ or /usr/local/ but just start from scratch. 

So:

/opt/gnu - strictly GNU tools (defined as something found from ftp.gnu.org)
/opt/tools - other local add-ons

(Assignee)

Comment 6

19 years ago
Ok, I consider this done... we have two paths, /opt/gnu/bin and /opt/tools/bin 
available. Staging for these is in /share/systems/mozilla-ftp/{tools,gnu}. For 
any additional tools needed please open ticket to bugzilla. At the moment we 
have these:

tools:
gd-1.7.3      libpng-1.0.5  mutt-1.0      pgp-6.5.1i    rsync-2.3.2   zlib-1.1.3

gnu:
automake-1.4    cvs-1.10        lynx-2.8.2      screen-3.9.4    zlibc-0.9e
bash-2.03       emacs-20.5a     make-3.78.1     stow-1.3.2
binutils-2.9.1  gcc-2.95.2      perl-5.005.03   tar-1.13
bison-1.28      gzip-1.2.4a     rcs-5.7         wget-1.5.3

There are old legacy binaries in /tools/ns/bin, /usr/local/bin and such still 
but I won't be touching those because something might break. But all new scripts 
etc hopefully will start using these new tools. Sometimes if we feel brave 
enough we can start symlinking files to old paths.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
We still need this documented somewhere, along with various other stuff like
cvsup, the squid proxy, etc.

Opening bug 13687 for that.
(Assignee)

Comment 8

19 years ago
This is all going to be in the doc, 
current working version is in https://handbook.mcom.com/docs/mozilla/
Status: RESOLVED → CLOSED
(Reporter)

Comment 9

19 years ago
Why not put it on mozilla.org so outsiders can see the drafts?
(Assignee)

Comment 10

19 years ago
Because it has some confidential information - some projects with Mozilla.org 
are related to some internal changes/projects we are also working on. Stripped 
version will be fine to put publicly available (but not yet).
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.