Re: System initialization
On 2012-04-18 19:23, Brett Glass wrote: And then, there's the question of how to restart daemons (but not the whole system!) when configurations are changed... when this is possible. Monit can be configured to do this, as a side effect of monitoring your daemons. It also likes to be in charge of starting the daemons, which might be enough to let you run your dynamic config generator. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: System initialization
Brett Glass wrote: > I have several nearly identical servers in my network, and would > like to control their configurations entirely from one file ... You might find sysutils/puppet useful. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: System initialization
On 04/19/2012 02:32 AM, Erich Dollansky wrote: > Hi, > > I think you have had the list twice in the address list. > > On Thursday 19 April 2012 06:23:26 Brett Glass wrote: > >> Has anyone out there worked on the problem of generating >> configuration files for important daemons (e.g. mpd, dnscache from > are you sure that you really need this dynamically? > > I believed this too until I realised that a script manually run can do the > job for me. > > I created a central location for my configuration files and let a script do > the rest. Of course, it is all static. > > Erich Hi The people from pfSense have done this very nicely. Maybe you can take a look at how they did this. It has one configuration file which is in xml format. Disclaimer: http://www.ose.nl/email ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: System initialization
Hi, I think you have had the list twice in the address list. On Thursday 19 April 2012 06:23:26 Brett Glass wrote: > Has anyone out there worked on the problem of generating > configuration files for important daemons (e.g. mpd, dnscache from are you sure that you really need this dynamically? I believed this too until I realised that a script manually run can do the job for me. I created a central location for my configuration files and let a script do the rest. Of course, it is all static. Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
System initialization
Everyone: I have several nearly identical servers in my network, and would like to control their configurations entirely from one file (such as /etc/rc.conf). Unfortunately, while some flavors of embedded Linux have systems to do this, FreeBSD doesn't make it easy. A lot of files (/etc/resolv.conf, /etc/hosts, /etc/ttys, /etc/crontab, etc.) have to be set up independently of rc.conf, and since rc.conf can be run many times at boot and thereafter (for example, /etc/rc.firewall uses it to suck in environment variables), one doesn't want to generate configuration files directly from within it, but rather should edit the configuration file for each daemon -- using environment variables in rc.conf -- just each is started. Also, it may be impossible to generate configurations for some daemons or system components before they start, so it might be necessary to start with some default file, edit it, and then send a signal to force a reconfiguration. Most of the default rc scripts, in /etc/rc and in ports, don't always provide well for generation of configuration files and/or command line options and arguments prior to starting daemons. And then, there's the question of how to restart daemons (but not the whole system!) when configurations are changed... when this is possible. Has anyone out there worked on the problem of generating configuration files for important daemons (e.g. mpd, dnscache from the djbdns suite, ntpd, etc.) at boot time based on rc.conf -- and as many as possible early enough so that the daemons whose configurations are being generated won't already have been started? And has anyone attacked the problem of dynamic reconfiguration? I'm sure I could work out my own scheme for this, but don't want to reinvent the wheel if someone's already come up with a clever system to do it on FreeBSD. --Brett Glass ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
doubts regarding System Initialization working (SYSINIT)
Hello all,
I have been browsing through the FreeBSD kernel's source
code trying to understand its working .
In the mi_startup() in /sys/kern/init_main.c all the SYSINIT objects are
sorted using bubble sort and then they are executed in order.
My doubt is that we have declared the pointer to the struct sysinit as const
pointer to a const in the macro definition of SYSINIT ie when the macro
SYSINIT(kmem, SI_SUB_KMEM, SI_ORDER_FIRST, kmeminit, NULL) is expanded
completely we get the following
static struct sysinit kmem_sys_init = { SI_SUB_KMEM, SI_ORDER_FIRST,
(sysinit_cfunc_t)(sysinit_nfunc_t)kmeminit, ((void *)(((void *)0))) };
static void const * const __set_sysinit_set_sym_kmem_sys_init
__attribute__((__section__("set_" "sysinit_set"))) __attribute__((__used__))
= &kmem_sys_init;
Here we see that the pointer is of type const and to a const but when we
sort
and swap using
*sipp=*xipp;
We are trying to change the address of const pointer to a new address in
which case it should segfault but it works fine.
Why does it not segfault it seems I have not understood the concept behind
using const *const... I will be very thankful if you can help me with it.
Regards,
Mehul
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
