Re: management
- From: "Eric W. Bates" <ericx_lists@xxxxxxxxxxxx>
- Date: Fri, 13 Jan 2006 14:15:01 -0500
mike@xxxxxxxxxxx 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@xxxxxxxxxxxx
# 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@xxxxxxxxxxx mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-isp
> To unsubscribe, send any mail to "freebsd-isp-unsubscribe@xxxxxxxxxxx"
>
>
_______________________________________________
freebsd-isp@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isp
To unsubscribe, send any mail to "freebsd-isp-unsubscribe@xxxxxxxxxxx"
- References:
- management
- From: mike
- management
- Prev by Date: Re: FreeBSD as Server
- Next by Date: Re: management
- Previous by thread: Re: management
- Next by thread: Re: management
- Index(es):
Relevant Pages
|
