Am 21.06.2012, 12:56 Uhr, schrieb Wojciech Puchar <woj...@wojtek.tensor.gdynia.pl>:


 ifconfig_em0="inet ..."   ( default (or unknown) runlevel )
 ifconfig_em0_foolevel="inet ..." ( foolevel runlevel )
 ifconfig_em0_maintenance="inet ..." ( maintanence runlevel )

too ?
well - possible BUT... but well.

this will not require only changing "launcher" script for rc.d/* things but scripts itself. and extra flag so launcher at runlevel change will have to rerun network initialization script.

Can you give an example where you need that? it is a bit strange, network IP numbers are the same no matter what we do at present.

I thought that network would be more complicated.

My use case: I maintain a business application consisting of
- FreeBSD
- several ports
- my software
and I run this system:
a) for development, in a VM on my laptop on my local network;
b) for demonstration and customer guided planning, in a VM on my laptop on the customers network,
c) for production, on a machine on the customers network,
d) for production, in a VM on the laptops of the customers team.

The software is the same for all 4, but they differ in services started and in network settings. Having "service profiles" and "network profiles" would allow me to have a convenient method of delegating the whole setup to the application: System boots, no services default network, application starts, detects machine role (devel, demo, server, portable), configures the network and starts the appropriate services.

As in:
I have a configuration file for the application anyway.
This configuration file contains the machine role (devel, demo ...) anyway.
If I could send this role as a parameter to "rc mode <role>" and network and services would be configured accordingly, I could have an identical rc.conf over all roles, and I'd consider that a big plus.

Michael
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Reply via email to