management

[Eric W. Bates]

mike at lanline.com wrote:
> Hi all,
> 
> 	Sorry, I know I've asked a question similar to this in the past,
> but...  I am currently in the process of migrating from BSD/OS to
> FreeBSD.  I'm very concerned with the management of my new FreeBSD server
> farm.  There doesn't seem to be much documentation in the way of large
> scale FreeBSD management.  I posted a question recently about upgrades
> (having one server w/ the source and NFS mounting the source dirs to all
> the other machines and building that way), but I feel like some minor
> details are missing.  Like, can I or should I redirect the obj code to a
> directory on the local machine so I don't have to do a make clean as I go
> from server to server (and if so, can I do this through make.conf)?  Same
> thing with ports. Also, I know about portupgrade, but is that the best way
> to manage ports?  Is there something better?  And the port system
> itself... I know it's supposed to provide all this flexibility, but there
> doesn't seem to be any documentation about what variables can be set or
> anything (e.g. can I force the binary to get installed in a certain dir?)

You can tweak individual ports to build with separate rules.  If you
simply set a flag in /etc/make.conf, the flag is read by every port (and
the system build for that matter). This can sometimes be a problem if
(for example) you want to build sasl with ldap support and ldap with
sasl support.

If you are consistent about using portupgrade, there is a ruby struct to
do this in /usr/local/etc/pkgtools.conf :

MAKE_ARGS = {
    'net/openldap*' => 'WITH_SASL=1',
    'www/mod_php4'  => 'BATCH=1',
    'lang/php4'     => 'BATCH=1',
  }

If you think there is some reason why you can't or won't always use
portupgrade, there is an undocumented technique I use. The file
/usr/Makefile.inc (which doesn't normally exist) is sourced by the port
build process after the make variable PORTNAME is defined.

/usr/Makefile.inc

# -*- makefile -*-
# $Id: Makefile.inc,v 1.2 2002/08/28 15:51:12 ericx Exp $

# file is loaded up via what may be an oddity in the Mk configuration
# files in /usr/ports/Mk/bsd.port.mk AFTER all the variables are set
# in the various Makefiles.  Unlike /etc/make.conf, this gives an
# opportunity to override settings in port Makefiles.

.if exists(/etc/make.conf.vni)
# But the file exists, pull it in.
.include </etc/make.conf.vni>
.endif



Then in /etc/make.conf.vni I have the per-port flags:

# -*- makefile -*-
# File:         make.conf.vni
# Author:       Charlie Root, ericx at vineyard.net
# Date:         Wed Aug 28 12:46:05 2002
# Time-stamp:   <2005-07-13 10:18:55 ericx>
# Description:  Setting variable in /etc/make.conf is not optimal
#               because those variables are read very early in the
#               compilation process and anything can be overridden in
#               the various Makefiles embedded in the ports
#               system. Nor can variables in /etc/make.conf be set on
#               a per-port basis, because at the time it is read
#               ${PORTNAME} has not been set.
#
#               This file is read in at the END of makes parsing phase
#               after all other Makefiles have been
#               included. Conditional variables can be can be set
#               based on ${PORTNAME} and decisions made by the port's
#               maintainer can be overridden.
#
#               See also: /etc/make.conf, /usr/Makfile.inc, /usr/ports/Mk
#
# $Id: make.conf.vni,v 1.14 2005/06/29 21:08:43 theqblas Exp ericx $

# ${PORTNAME} should be defined whenever we are building a port, but
# not when we are building world; so enclose all our per port
# conditionals inside a single check for PORTNAME.
.if defined(PORTNAME)

.if ${PORTNAME} == apache+mod_ssl
CONFIGURE_ARGS+=        --server-uid=http \
                        --server-gid=http \
                        --disable-rule=EXPAT
# apache+mod_ssl
.endif

# PORTNAME
.endif


> I know I could look in the makefiles and stuff, but I really don't have
> that kind of time (damn sys. admining)  Is there some documentation or
> something I don't know about that answers questions like these?  I mean
> the handbook is great for general config. questions, but I'm more
> interested in server farm management and maintenance.
> 
> Thank you very much in advance for any help.
> Hopefully I won't have many more stupid questions.
> 
> -Mike
> 
> 
> _______________________________________________
> freebsd-isp at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-isp
> To unsubscribe, send any mail to "freebsd-isp-unsubscribe at freebsd.org"
> 
>