Re: /etc/rc.d/jail script
Fbsd8 wrote: I have noticed that the /etc/rc.d/jail script will not start a jail that has the same ip address as a jail that is already running. But if I define 2 jails the manual way in rc.conf that have the same ip address they will start. So is this a bug in the "jail" script or is there some reason for this restriction? On deeper inspection of the /etc/rc.d/jail script, it seems the above only occurs if one or more jails are assigned the same ip address and one or more of the jails bound the shared ip address to a NIC device name. IE the auto creation and deletion of ip address aliases. ___ 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"
/etc/rc.d/jail script
I have noticed that the /etc/rc.d/jail script will not start a jail that has the same ip address as a jail that is already running. But if I define 2 jails the manual way in rc.conf that have the same ip address they will start. So is this a bug in the "jail" script or is there some reason for this restriction? ___ 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: Change in /etc/rc.d/namend script
[ Olivier Nicole wrote on Tue 25.Sep'12 at 11:39:37 +0700 ]
> Hi,
>
> Yesterday I upgraded my DNS server from 7.2 to 8.3 and has the
> unpleasant suprise to find that named would not restart after the
> upgrade.
>
> I think I traced it back to the new /etc/rc.d/named script.
>
> I am runing in named in a chrooted environment and it seems that with
> the new script the configuration file must exist in /etc/namedb as
> well as in /chroot/etc/namedb.
>
> Having to duplicate the configuration files to the not chrooted
> environment is something new. With the /etc/rc.d/named script
> 1.22.2.3.4.1 2008/10/02 that was not needed, and I don't see why it
> would be needed now.
>
> Is there a way to run the new startup script without duplicating (not
> even symlinking) the configuration?
In you /etc/namedb/named.conf have you specified your zone files using full
path names, such as:
zone "kode5.net" {
type master;
file "/etc/namedb/master/kode5.net.db";
};
Using relative paths for your zone files will not work any more. Perhaps this
could help?
___
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"
Change in /etc/rc.d/namend script
Hi, Yesterday I upgraded my DNS server from 7.2 to 8.3 and has the unpleasant suprise to find that named would not restart after the upgrade. I think I traced it back to the new /etc/rc.d/named script. I am runing in named in a chrooted environment and it seems that with the new script the configuration file must exist in /etc/namedb as well as in /chroot/etc/namedb. Having to duplicate the configuration files to the not chrooted environment is something new. With the /etc/rc.d/named script 1.22.2.3.4.1 2008/10/02 that was not needed, and I don't see why it would be needed now. Is there a way to run the new startup script without duplicating (not even symlinking) the configuration? Best regards, Olivier ___ 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: seems i cannot fully understand {/,/usr/local/}/etc/rc.d/*
> From: Wojciech Puchar > > >> But still - do you know why it is necessary? > > > > An explanation written some 80 years ago; > > 'Because that way it will work'. > if you don't have anything to say - just don't do it. practice what you preach. ___ 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: seems i cannot fully understand {/,/usr/local/}/etc/rc.d/*
On Wed, 20 Jun 2012 08:02:48 -0400 Jerry wrote: > On Wed, 20 Jun 2012 12:47:29 +0100 > RW articulated: > > > On Wed, 20 Jun 2012 09:45:07 +0100 > > Matthew Seaman wrote: > > > > > #!/bin/sh > > > # > > > # Persuade vboxheadless to start before samba. > > > > > > # PROVIDE: precedence > > > # REQUIRE: vboxheadless > > > # BEFORE: samba > > > > > > : > > > > > > Make it executable. Note -- the ':' does seem to be necessary. > > > > Why? None of the dummy scripts in the base system have a ":". > > From "man rc" > > EXAMPLES > The following is a minimal rc.d/ style script. Most scripts > require lit- tle more than the following. > >#!/bin/sh ># > ># PROVIDE: foo ># REQUIRE: bar_service_required_to_precede_foo > >. /etc/rc.subr > >name="foo" >rcvar=`set_rcvar` >command="/usr/local/bin/foo" > >load_rc_config $name >run_rc_command "$1" > > You will notice the prominent use of ":". We were talking about the null command colon at the bottom of the script, not the colons in comments at the top. ___ 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: seems i cannot fully understand {/,/usr/local/}/etc/rc.d/*
On 20/06/2012 12:47, RW wrote: > On Wed, 20 Jun 2012 09:45:07 +0100 > Matthew Seaman wrote: > >> #!/bin/sh >> # >> # Persuade vboxheadless to start before samba. >> >> # PROVIDE: precedence >> # REQUIRE: vboxheadless >> # BEFORE: samba >> >> : >> >> Make it executable. Note -- the ':' does seem to be necessary. > > Why? None of the dummy scripts in the base system have a ":". It seems I was mistaken. As far as rcorder goes, an empty script is just as good as a single null command: % cat precedence #!/bin/sh # # Persuade postgresql to start before spamassassin. # PROVIDE: precedence # REQUIRE: postgresql # BEFORE: spamd % rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | grep -E 'postgresql|precedence|sa-spamd' /usr/local/etc/rc.d/postgresql /usr/local/etc/rc.d/precedence /usr/local/etc/rc.d/sa-spamd Hey -- I saved a whole two bytes. Woohoo! Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: seems i cannot fully understand {/,/usr/local/}/etc/rc.d/*
On 6/20/12 11:09 AM, Matthew Seaman wrote: > On 20/06/2012 09:51, Wojciech Puchar wrote: >>> >>> Create a new file in /usr/local/etc/rc.d/precedence with the following >>> contents: >>> >>> #!/bin/sh >>> # >>> # Persuade vboxheadless to start before samba. >>> >>> # PROVIDE: precedence >>> # REQUIRE: vboxheadless >>> # BEFORE: samba >>> >>> : >>> >>> Make it executable. Note -- the ':' does seem to be necessary. >>> >> thank you for help. I will test it when being on place and could reboot. >> >> But still - do you know why it is necessary? >> >> cannot i just add BEFORE: samba in vboxheadless? >> > > Yes, that should work too. However any time you update vboxheadless > you'll have to remember to add that modification back to the rc script. > Using a separate file stops that being a problem. > > If you want to test that your changes are having the desired effect > without having to reboot: > ># rcorder /etc/rc.d/* /usr/local/etc/rc.d/* > > which will print out the order all the rc-scripts would be run. (It > includes all the scripts, not just the ones enabled in /etc/rc.conf, but > that shouldn't matter.) > > Cheers, > > Matthew > A very helpful post, adding to favorites. Might that, possibly, warrant a handbook entry ? ___ 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: seems i cannot fully understand {/,/usr/local/}/etc/rc.d/*
On Wed, 20 Jun 2012 12:47:29 +0100 RW articulated: > On Wed, 20 Jun 2012 09:45:07 +0100 > Matthew Seaman wrote: > > > #!/bin/sh > > # > > # Persuade vboxheadless to start before samba. > > > > # PROVIDE: precedence > > # REQUIRE: vboxheadless > > # BEFORE: samba > > > > : > > > > Make it executable. Note -- the ':' does seem to be necessary. > > Why? None of the dummy scripts in the base system have a ":". From "man rc" EXAMPLES The following is a minimal rc.d/ style script. Most scripts require lit- tle more than the following. #!/bin/sh # # PROVIDE: foo # REQUIRE: bar_service_required_to_precede_foo . /etc/rc.subr name="foo" rcvar=`set_rcvar` command="/usr/local/bin/foo" load_rc_config $name run_rc_command "$1" You will notice the prominent use of ":". If you feel that is in error, please feel free to submit a PR against it. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ 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: seems i cannot fully understand {/,/usr/local/}/etc/rc.d/*
But still - do you know why it is necessary? An explanation written some 80 years ago; 'Because that way it will work'. if you don't have anything to say - just don't do it. ___ 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: seems i cannot fully understand {/,/usr/local/}/etc/rc.d/*
On Wed, 20 Jun 2012 09:45:07 +0100 Matthew Seaman wrote: > #!/bin/sh > # > # Persuade vboxheadless to start before samba. > > # PROVIDE: precedence > # REQUIRE: vboxheadless > # BEFORE: samba > > : > > Make it executable. Note -- the ':' does seem to be necessary. Why? None of the dummy scripts in the base system have a ":". ___ 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: seems i cannot fully understand {/,/usr/local/}/etc/rc.d/*
> From owner-freebsd-questi...@freebsd.org Wed Jun 20 03:51:43 2012
> Date: Wed, 20 Jun 2012 10:51:04 +0200 (CEST)
> From: Wojciech Puchar
> To: Matthew Seaman
> Cc: freebsd-questions@freebsd.org
> Subject: Re: seems i cannot fully understand {/,/usr/local/}/etc/rc.d/*
>
> >
> > Create a new file in /usr/local/etc/rc.d/precedence with the following
> > contents:
> >
> > #!/bin/sh
> > #
> > # Persuade vboxheadless to start before samba.
> >
> > # PROVIDE: precedence
> > # REQUIRE: vboxheadless
> > # BEFORE: samba
> >
> > :
> >
> > Make it executable. Note -- the ':' does seem to be necessary.
> >
> thank you for help. I will test it when being on place and could
> reboot.
>
> But still - do you know why it is necessary?
An explanation written some 80 years ago;
'Because that way it will work'.
___
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: seems i cannot fully understand {/,/usr/local/}/etc/rc.d/*
#!/bin/sh # # Persuade vboxheadless to start before samba. # PROVIDE: precedence # REQUIRE: vboxheadless # BEFORE: samba : Make it executable. Note -- the ':' does seem to be necessary. thank you for help. I will test it when being on place and could reboot. But still - do you know why it is necessary? cannot i just add BEFORE: samba in vboxheadless? Yes, that should work too. However any time you update vboxheadless you'll have to remember to add that modification back to the rc script. Using a separate file stops that being a problem. now i understood completely. thank you ___ 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: seems i cannot fully understand {/,/usr/local/}/etc/rc.d/*
On Wed, 20 Jun 2012 10:51:04 +0200 (CEST) Wojciech Puchar articulated: > > Create a new file in /usr/local/etc/rc.d/precedence with the > > following contents: > > > > #!/bin/sh > > # > > # Persuade vboxheadless to start before samba. > > > > # PROVIDE: precedence > > # REQUIRE: vboxheadless > > # BEFORE: samba > > > > : > > > > Make it executable. Note -- the ':' does seem to be necessary. > > > thank you for help. I will test it when being on place and could > reboot. > > But still - do you know why it is necessary? > > cannot i just add BEFORE: samba in vboxheadless? I had a similar problem about two years ago. One program required program "X" to load prior to it while program "Y" wanted to load it after it. It was causing a conflict. It is slightly difficult to explain in a few words. I had to manually check every file in the /usr/local/etc/rc.d directory to straighten it out. I believe that there is a way to have all of that information displayed without going through that much intervention; however, I do not remember how to do it at the moment. Anyway, in the "samba" file, it has this notation: # PROVIDE: nmbd smbd I don't know if that makes any difference or not. I have never had to move the starting order of samba around. I do know that in other applications, they appear to have their name in the "PROVIDE" line. For example, from the Postfix script: # PROVIDE: postfix mail -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ 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: seems i cannot fully understand {/,/usr/local/}/etc/rc.d/*
On 20/06/2012 09:51, Wojciech Puchar wrote: >> >> Create a new file in /usr/local/etc/rc.d/precedence with the following >> contents: >> >> #!/bin/sh >> # >> # Persuade vboxheadless to start before samba. >> >> # PROVIDE: precedence >> # REQUIRE: vboxheadless >> # BEFORE: samba >> >> : >> >> Make it executable. Note -- the ':' does seem to be necessary. >> > thank you for help. I will test it when being on place and could reboot. > > But still - do you know why it is necessary? > > cannot i just add BEFORE: samba in vboxheadless? > Yes, that should work too. However any time you update vboxheadless you'll have to remember to add that modification back to the rc script. Using a separate file stops that being a problem. If you want to test that your changes are having the desired effect without having to reboot: # rcorder /etc/rc.d/* /usr/local/etc/rc.d/* which will print out the order all the rc-scripts would be run. (It includes all the scripts, not just the ones enabled in /etc/rc.conf, but that shouldn't matter.) Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: seems i cannot fully understand {/,/usr/local/}/etc/rc.d/*
Create a new file in /usr/local/etc/rc.d/precedence with the following contents: #!/bin/sh # # Persuade vboxheadless to start before samba. # PROVIDE: precedence # REQUIRE: vboxheadless # BEFORE: samba : Make it executable. Note -- the ':' does seem to be necessary. thank you for help. I will test it when being on place and could reboot. But still - do you know why it is necessary? cannot i just add BEFORE: samba in vboxheadless? ___ 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: seems i cannot fully understand {/,/usr/local/}/etc/rc.d/*
On 20/06/2012 09:24, Wojciech Puchar wrote: > i have samba server and few virtualbox sessions using vboxnet which is > started by /usr/local/etc/rc.d/vboxheadless > > i want samba to be started AFTER vboxheadless as the latter configures > vboxnet0 automatically when started, and samba do bind to vboxnet0. > > so i appended vboxheadless to REQUIRE: line in /usr/local/etc/rc.d/samba > because vboxheadless is a word after PROVIDE: in > /usr/local/etc/rc.d/vboxheadless script > > yet - samba still is started before vboxheadless. > > what i am missing? Create a new file in /usr/local/etc/rc.d/precedence with the following contents: #!/bin/sh # # Persuade vboxheadless to start before samba. # PROVIDE: precedence # REQUIRE: vboxheadless # BEFORE: samba : Make it executable. Note -- the ':' does seem to be necessary. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
seems i cannot fully understand {/,/usr/local/}/etc/rc.d/*
i have samba server and few virtualbox sessions using vboxnet which is started by /usr/local/etc/rc.d/vboxheadless i want samba to be started AFTER vboxheadless as the latter configures vboxnet0 automatically when started, and samba do bind to vboxnet0. so i appended vboxheadless to REQUIRE: line in /usr/local/etc/rc.d/samba because vboxheadless is a word after PROVIDE: in /usr/local/etc/rc.d/vboxheadless script yet - samba still is started before vboxheadless. what i am missing? ___ 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: /etc/rc.d/jail using new-style jail command?
> To the originator of this thread - do give qjail a try - it's very good. I'll definitely give it a look! Thanks for the suggestion/ ___ 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: /etc/rc.d/jail using new-style jail command?
On Mon, Jun 20, 2011 at 11:41:21AM -0400, Fbsd8 wrote: > Daniel Bye wrote: > >On Sun, Jun 19, 2011 at 10:16:05PM -0400, Fbsd8 wrote: > >>Give the qjail port a try. It has the ability to reference jails by name > >>and create jails without starting them. Though it does not use the > >>new-style jail command. > > > > > >zsh/2 1002 # make install > >===> Installing for qjail-1.0 > >===> Generating temporary packing list > >===> Checking if sysutils/qjail already installed > >install: > >/data/portbuild/usr/ports/sysutils/qjail/work/qjail-1.0/qjail-jail2: No > >such > >/ file or directory > >*** Error code 71 > > > >Stop in /usr/ports/sysutils/qjail. > > > > > >Any progress on getting the port fixed? I really like qjail, and find it > >pretty intuitive, but the port hasn't worked properly since it was added to > >the collection. > > > >Dan > > > > > Dan, > qjail installs fine for me. You have something mis-configured > on your system. > /data/portbuild/ is invalid path which is not part of an normal install. My system is set up just fine, thanks. My ports tree is located on a single server, and shared via NFS. To avoid hitting the rather slow disks in the host machine, each client sets WRKDIRPREFIX so that ports build locally. This is fully supported by the ports system, and should not cause a well-behaved port to break.[1] And indeed, this configuration has been working flawlessly now for well over 6 years, and it is not the source of the problem now. This is what happens when I try to install qjail on the host where the ports tree lives: zsh/3 1001 # make install ===> Installing for qjail-1.0 ===> Generating temporary packing list ===> Checking if sysutils/qjail already installed install: /usr/ports/sysutils/qjail/work/qjail-1.0/qjail-jail2: No such file or directory *** Error code 71 Stop in /usr/ports/sysutils/qjail. zsh/3 1007 # ls /usr/ports/sysutils/qjail/work/qjail-1.0/qjail-jail2 ls: /usr/ports/sysutils/qjail/work/qjail-1.0/qjail-jail2: No such file or directory The file isn't there. Bah! Scratch that. Just ran make distclean && make install and it works. My apologies, Joe, I should have tried that much sooner... I can only assume it happened because I installed the port by hand shortly after you announced its release a few months ago, before it was formally accepted as part of the tree. I guess I forgot to clean up after that manual test install and grab the latest version from the ports. To the originator of this thread - do give qjail a try - it's very good. ~runs away and hides Dan 1 http://www.freebsd.org/doc/en/books/porters-handbook/porting-wrkdirprefix.html -- Daniel Bye _ ASCII ribbon campaign ( ) - against HTML, vCards and X - proprietary attachments in e-mail / \ pgpla2mVd79lP.pgp Description: PGP signature
Re: /etc/rc.d/jail using new-style jail command?
Daniel Bye wrote: On Sun, Jun 19, 2011 at 10:16:05PM -0400, Fbsd8 wrote: Give the qjail port a try. It has the ability to reference jails by name and create jails without starting them. Though it does not use the new-style jail command. zsh/2 1002 # make install ===> Installing for qjail-1.0 ===> Generating temporary packing list ===> Checking if sysutils/qjail already installed install: /data/portbuild/usr/ports/sysutils/qjail/work/qjail-1.0/qjail-jail2: No such / file or directory *** Error code 71 Stop in /usr/ports/sysutils/qjail. Any progress on getting the port fixed? I really like qjail, and find it pretty intuitive, but the port hasn't worked properly since it was added to the collection. Dan Dan, qjail installs fine for me. You have something mis-configured on your system. /data/portbuild/ is invalid path which is not part of an normal install. ___ 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: /etc/rc.d/jail using new-style jail command?
On Sun, Jun 19, 2011 at 10:16:05PM -0400, Fbsd8 wrote: > Give the qjail port a try. It has the ability to reference jails by name > and create jails without starting them. Though it does not use the > new-style jail command. zsh/2 1002 # make install ===> Installing for qjail-1.0 ===> Generating temporary packing list ===> Checking if sysutils/qjail already installed install: /data/portbuild/usr/ports/sysutils/qjail/work/qjail-1.0/qjail-jail2: No such / file or directory *** Error code 71 Stop in /usr/ports/sysutils/qjail. Any progress on getting the port fixed? I really like qjail, and find it pretty intuitive, but the port hasn't worked properly since it was added to the collection. Dan -- Daniel Bye _ ASCII ribbon campaign ( ) - against HTML, vCards and X - proprietary attachments in e-mail / \ pgpmwu9g0nQln.pgp Description: PGP signature
Re: /etc/rc.d/jail using new-style jail command?
Lars Kellogg-Stedman wrote: Hello all, I'm curious if there's been any work done to make /etc/rc.d/jail use the new-style jail command (jail -c path=... name=..., etc)...or if there's been any work done to create a replacement? There are three features I would love to see in the stock version that I've had to implement myself: - The ability to reference jails by name. Passing the name= argument means that jails can be referenced by name when using, e.g., the jexec command, which is very convenient since jail ids aren't (normally) persistent. - The ability to create jails without starting them. The "persist" argument to the jail command is useful when attaching ZFS datasets to a jail. A ZFS dataset can't be attached until a JID has been allocated, but if with the existing implementation the jail will probably have booted by the time you complete the ZFS assignment, which impacts services that may need access to the jail. There are workarounds (such as a busy-wait loop that checks for the filesystem), but creating the jail with no processes, attaching the datasets, and then starting the jail is much cleaner. - Somewhat more flexibility in setting up jail permissions (via the enforce_statfs and allow.* arguments). Before I spend too much time making my own local changes, I was wondering if there was anything I should be looking at. I've been using ezjail recently, but since it relies on the stock /etc/rc.d/jail to actually boot and configure jails it suffers from the same limitations. Thanks, -- Lars Give the qjail port a try. It has the ability to reference jails by name and create jails without starting them. Though it does not use the new-style jail command. ___ 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"
/etc/rc.d/jail using new-style jail command?
Hello all, I'm curious if there's been any work done to make /etc/rc.d/jail use the new-style jail command (jail -c path=... name=..., etc)...or if there's been any work done to create a replacement? There are three features I would love to see in the stock version that I've had to implement myself: - The ability to reference jails by name. Passing the name= argument means that jails can be referenced by name when using, e.g., the jexec command, which is very convenient since jail ids aren't (normally) persistent. - The ability to create jails without starting them. The "persist" argument to the jail command is useful when attaching ZFS datasets to a jail. A ZFS dataset can't be attached until a JID has been allocated, but if with the existing implementation the jail will probably have booted by the time you complete the ZFS assignment, which impacts services that may need access to the jail. There are workarounds (such as a busy-wait loop that checks for the filesystem), but creating the jail with no processes, attaching the datasets, and then starting the jail is much cleaner. - Somewhat more flexibility in setting up jail permissions (via the enforce_statfs and allow.* arguments). Before I spend too much time making my own local changes, I was wondering if there was anything I should be looking at. I've been using ezjail recently, but since it relies on the stock /etc/rc.d/jail to actually boot and configure jails it suffers from the same limitations. Thanks, -- Lars ___ 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: Using "/etc/rc.d/netif start"
> In my experience, I've found it best to restart 'routing,' as well. > > /etc/rc.d/routing restart Yes indeed thank you. ___ 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: Using "/etc/rc.d/netif start"
On Tue, Mar 29, 2011 at 10:40:19AM -0700, Nerius Landys thus spake: First off, I'm on 9.0-CURRENT-i386, but I don't think that will make a difference for purposes of my question. I think the freebsd-current folks are expecting questions that are much harder than this one. I'm trying to use /etc/rc.d/netif to bring down and bring back up all network interfaces, because I'm trying to get the correct entries in /etc/rc.conf for testing some extra network cards. So right now, my /etc/rc.conf looks like this: defaultrouter="192.168.0.254" hostname="elmer.i" ifconfig_em0="inet 192.168.0.6 netmask 255.255.255.0" /etc/resolv.conf looks like this: domain i nameserver 192.168.0.254 I'm basically in a LAN. When I boot up this "elmer.i" machine, everything works well. Then, I do the following two commands: /etc/rc.d/netif stop /etc/rc.d/netif start After these, I'm still able to ping a raw IP LAN address such as 192.168.0.254. However, two problems start occurring: 1. I cannot ping an IP address that is outside of my LAN, e.g. ping 64.156.192.169 PING 64.156.192.169 (64.156.192.169): 56 data bytes ping: sendto: No route to host 2. DNS (via 192.168.0.254 nameserver) won't work at first, but starts to magically work when I for example enable sshd and log in to elmer from another host on the LAN So the nut of my question is, I think "/etc/rc.d/netif stop" stops some additional things such as packet routing that the corresponding "/etc/rc.d/netif start" command won't start back up. So what is the best way to bring down the network and bring it back up again for purposes of testing /etc/rc.conf syntax? In my experience, I've found it best to restart 'routing,' as well. /etc/rc.d/routing restart -jgh -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5 ___ 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"
Using "/etc/rc.d/netif start"
First off, I'm on 9.0-CURRENT-i386, but I don't think that will make a difference for purposes of my question. I think the freebsd-current folks are expecting questions that are much harder than this one. I'm trying to use /etc/rc.d/netif to bring down and bring back up all network interfaces, because I'm trying to get the correct entries in /etc/rc.conf for testing some extra network cards. So right now, my /etc/rc.conf looks like this: defaultrouter="192.168.0.254" hostname="elmer.i" ifconfig_em0="inet 192.168.0.6 netmask 255.255.255.0" /etc/resolv.conf looks like this: domain i nameserver 192.168.0.254 I'm basically in a LAN. When I boot up this "elmer.i" machine, everything works well. Then, I do the following two commands: /etc/rc.d/netif stop /etc/rc.d/netif start After these, I'm still able to ping a raw IP LAN address such as 192.168.0.254. However, two problems start occurring: 1. I cannot ping an IP address that is outside of my LAN, e.g. > ping 64.156.192.169 PING 64.156.192.169 (64.156.192.169): 56 data bytes ping: sendto: No route to host 2. DNS (via 192.168.0.254 nameserver) won't work at first, but starts to magically work when I for example enable sshd and log in to elmer from another host on the LAN So the nut of my question is, I think "/etc/rc.d/netif stop" stops some additional things such as packet routing that the corresponding "/etc/rc.d/netif start" command won't start back up. So what is the best way to bring down the network and bring it back up again for purposes of testing /etc/rc.conf syntax? ___ 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: xdm-options - non-bsd user needs bsd rc.d advice
On Fri, Mar 4, 2011 at 9:34 AM, Polytropon wrote: > While I found that generic > UNIX knowledge was applicable everywhere, "Linux knowledge" > was not, as you could see from file names and locations, > procedures, and configuration statements which could not > be transferred 1:1 between the systems. I find that's true even going between "true UNIX" systems, like FreeBSD and Solaris. Maybe it was different back in the SunOS days, but modern Solaris has a lot of very Solaris-specific tools that work in opaque ways; for example, you don't edit links to /etc/init.d anymore, you create an XML service description file and use svcadm to manipulate it in some hidden database. There are still BSD-ish tools in Solaris (and GNU tools, too), but Solaris purists will strongly discourage you from using them. ___ 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: xdm-options - non-bsd user needs bsd rc.d advice
Readers will surely see more and more people having similar reasons why those who happily use FreeBSD do not want to go back to Linux, or even worse, "Windows". I may include myself here, with the special case that I've never been a "Windows" user, so my mind is clean and healthy and unspoiled of MICROS~1's strange ideas of how things work. :-) On Fri, 4 Mar 2011 15:28:10 +0100, "Christopher J. Ruwe" wrote: > I started with Linux when being in high-school out of frustration of > Windows forcing me to do things their way. In my case, it happened in school, simply because of the reason that I needed a versatile typesetting system (text, formulas, graphs) to print to a laser printer. As LaTeX was already available on Linux, I started with Slackware which was a very UNIX-like system (a positive opinion!) at that time. Later on, I did use PTS-Linux (derived from DLD, a german Linux distribution, if I remember correctly), as well as S.u.S.E.-Linux (its formal name at that time). While I found that generic UNIX knowledge was applicable everywhere, "Linux knowledge" was not, as you could see from file names and locations, procedures, and configuration statements which could not be transferred 1:1 between the systems. > When at university, I tried Gentoo Linux, learned a lot and solved > problems my way. Having bought a notebook later on, I decided trying > the then very much in vogue Ubuntu with a Xubuntu installation. > Although satisfied with the very usable defaults, I was quickly > unnerved by not being able to control things. University was the time when I found out about FreeBSD. Having generic UNIX knowledge already (Linux, Solaris, IRIX) I could predict (!) where things are on a FreeBSD system, how they act, and what they do. This was my main reason to keep using this system, exlusively as a home desktop since version 4.0, without any disadvantages so far. I doubt that Linux would have delivered the quality I'm looking for: The quality of not being forced to abandon fully functional hardware simply because new defaults tell me I need a plentycore CPU and tenmelonhundred GB of RAM, just to keep doing the same things. As a developer, targetting Linux (as a family of operating systems) is not very easy, as they all do differ in some way. At least there is source code to consult if problems arise, but sometimes you're searching through header files to find out what *foo() is today. :-) > What drove me away from Gentoo apart from that GPL-flu was deteriorating > quality of system tools. You install what is world in FreeBSD from > portage in Gentoo, so when updating your portage, necessary system > tools sometimes break. Linux does not differentiate between "the system" and "everything else"; even the kernel can be seen as a package on the system. Along with different packaging systems, distributions differ in what packages they use to make their "base system" (default amount of installation). For developers, FreeBSD is an EXCELLENT operating system as it offers consistency, compatibility and interoperatbility at a good speed ratio (won't run slower after upgrading). The code quality and the availability of good documentation (man pages, handbook, FAQ), even accessible LOCALLY with no Internet connection at hand, makes it a strong partner for DURABLE solutions in software development. A friendly and intelligent community adds to the sum. The sum is SUPERIOR to what I could experience in my "career". I know this is a quite general statement and doesn't help the OP in particular, but I thought it would be worth sharing it. I hope it was. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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: xdm-options - non-bsd user needs bsd rc.d advice
On Fri, Mar 04, 2011 at 03:28:10PM +0100, Christopher J. Ruwe wrote: > > Later, I tried OpenSolaris and FreeBSD and am now using FreeBSD due to > the same reasons as Chad Perrin stated: Being a power-user, wanting to > control things and (now diverting from Chad's reasons) wanting to use > technology (most importantly ZFS) without being impeded for ideological > reasons of viral GPLishness. I'd say you diverted from what I satated -- though not from my reasons overall. That is actually among the reasons I prefer FreeBSD, even if I didn't mention it. > > So, same reasons here as with Chad Perrin, safe for an additionally and > lately aquired GPL-allergy. My GPL-allergy has been around since late 2003, but has been growing in strength. 2006 was when it finally got to the point where I stopped using Linux-based systems for my own purposes until some video issues "forced" me back to it last month. > > @ Chad: Perhaps you might be happier being coerced to use a > Linux with a GNU/Linux flavour like Gentoo or ArchLinux. I have never > tried the latter, however, with Gentoo you are very much in control. > Gentoo effectively forces you to do your own compiling via portage, so > be prepared for a very long install. ArchLinux is to my knowledge binary > based and might be quicker to install. Both Gentoo and ArchLinux have a > reputation to put the user in charge. I'm considering ArchLinux. I've played with Gentoo in the past (2004ish), and did not much find it to my liking -- mostly because of software stability issues and a community overrun with ricers. > > What drove me away from Gentoo apart from that GPL-flu was deteriorating > quality of system tools. You install what is world in FreeBSD from > portage in Gentoo, so when updating your portage, necessary system > tools sometimes break. I was driven over the edge when some network-etc > syntax changed without telling me and I lost my network connection as a > result. I had something different in mind for the weekend and was just > furious - so treat Gentoo with care. That kind of breakage is among the reasons I didn't like Gentoo. Around that time, Debian was much more stable in practice (even Debian Testing), but things have changed in the Debian world since I last used it for my own purposes five years ago; now, it's prone to breakage as well, evidently. From your description, it sounds like Gentoo wouldn't solve the kinds of problems I'm having with Debian; it would just rearrange the deck chairs on the Titanic. I've heard Arch is a tolerable substitute for FreeBSD when you "must" use Linux-based systems for some reason. I'm probably going to wipe the system and reinstall this weekend to try to solve my networking issue, and Arch looks like the option I'll try -- though I'll probably check into whether OpenBSD has support for the graphics chipset in this laptop, too (I really doubt it). . . . and then, as soon as the graphics support gets sorted out in FreeBSD, I'll probably wipe again and install FreeBSD. I had FreeBSD installed on it briefly already, and everything about it worked exactly as expected except the graphics, after all. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgptAieZrb8Kp.pgp Description: PGP signature
Re: xdm-options - non-bsd user needs bsd rc.d advice
On Thu, 03 Mar 2011 17:01:10 -0500 "John D. Hendrickson and Sara Darnell" wrote: > [snip] > If anyone would like to quickly comment I'd love to hear why bsd > would be a better choice than ubantu (for what audience it is better). > > Thanks all, > > John > > ___ > 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" Hi John, same with me as with Chad Perrin. Sadly, I cannot put my issue right and brief at the same time, so please excuse me being verbose. I started with Linux when being in high-school out of frustration of Windows forcing me to do things their way. After switching my entire environment to Suse Linux and after that to a version of RedHat, I quickly found out that I just switched to a different flavour of being forced to do things a certain way. When at university, I tried Gentoo Linux, learned a lot and solved problems my way. Having bought a notebook later on, I decided trying the then very much in vogue Ubuntu with a Xubuntu installation. Although satisfied with the very usable defaults, I was quickly unnerved by not being able to control things. Later, I tried OpenSolaris and FreeBSD and am now using FreeBSD due to the same reasons as Chad Perrin stated: Being a power-user, wanting to control things and (now diverting from Chad's reasons) wanting to use technology (most importantly ZFS) without being impeded for ideological reasons of viral GPLishness. So, same reasons here as with Chad Perrin, safe for an additionally and lately aquired GPL-allergy. @ Chad: Perhaps you might be happier being coerced to use a Linux with a GNU/Linux flavour like Gentoo or ArchLinux. I have never tried the latter, however, with Gentoo you are very much in control. Gentoo effectively forces you to do your own compiling via portage, so be prepared for a very long install. ArchLinux is to my knowledge binary based and might be quicker to install. Both Gentoo and ArchLinux have a reputation to put the user in charge. What drove me away from Gentoo apart from that GPL-flu was deteriorating quality of system tools. You install what is world in FreeBSD from portage in Gentoo, so when updating your portage, necessary system tools sometimes break. I was driven over the edge when some network-etc syntax changed without telling me and I lost my network connection as a result. I had something different in mind for the weekend and was just furious - so treat Gentoo with care. Cheers, -- Christopher J. Ruwe TZ GMT + 1 signature.asc Description: PGP signature
Re: xdm-options - non-bsd user needs bsd rc.d advice
On Thu, 03 Mar 2011 17:01:10 -0500 "John D. Hendrickson and Sara Darnell" wrote: > Hi. I'm a BSD idiot I use [Debian] linux. > > rc.d question > > I'm trying to release a project (just below) to the widest possible > unix audience. I need a line in "/etc/inittab" and to have a > start/stop in "/etc/rc.d", nothing unusual I think. I read many > freeBSD rc.d materials and it only convinced me as much as I'd > learned: if I'm not running BSD I don't know enough to talk about > it :) Usually FreeBSD rc.d scripts are maintained by the port maintainer rather than the upstream project. If you are unclear about it, I would suggest you don't bother. ___ 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: xdm-options - non-bsd user needs bsd rc.d advice
On Thu, Mar 03, 2011 at 05:01:10PM -0500, John D. Hendrickson and Sara Darnell wrote: > > Hi. I'm a BSD idiot I use [Debian] linux. [snip] > > If anyone would like to quickly comment I'd love to hear why bsd would > be a better choice than ubantu (for what audience it is better). FreeBSD is definitely a better choice for *me* than Debian, or (worse yet) Ubuntu. I'm temporarily stuck in a hell of my own making, of sorts, because I installed Debian on a laptop I bought to make up for the fact that I managed to buy a laptop for which FreeBSD does not yet have complete graphics support (Intel HD video). The end result is significant annoyance. Debian, since I used it regularly about half a decade ago, has become increasingly complicated by attempts to guess what users want and provide it. This approach tends to result in making it very difficult to do things differently if you want to. Problems I'm encountering right now mostly center around networking issues -- for some asinine reason, it will connect to my WPA encrypted wireless network at home, but not to an open wireless network at a coffee shop. It makes no reasonable sense. With FreeBSD, it would be a trivial exercise to make it work. Worst-case scenario, I could just change a couple of lines in /etc/rc.d and enter the /etc/rc.d/netif restart command. On Debian, I've tried about half a dozen different approaches to getting it to connect to the coffee shop network, including more than one GUI with a seriously suboptimal interface, with no luck; it just keeps failing to get an IP address. I'm pretty sure there's some kind of automagical DWIMmery going on behind the scenes, trying to guess what I want it to do and doing it without my permission, and getting its guesses *wrong*. The upshot is this: FreeBSD is better for people who like essentially deterministic behavior out of their OSes, where the same input produces the same output, with (little or) no chance of it blowing up in your face or just stubbornly refusing to let you do what you want to do because some developer somewhere set up automagical default management based on what *he* thinks you *really* want to do. Debian to some extent, and Ubuntu to a far greater extent, is for people who don't want to know anything about what the system is doing under the hood, to the extent that if the system doesn't get it right automatically the person will refuse to actually spend any time learning enough about the system to fix the problem. Things are getting positively Microsoftish. In case you couldn't tell, I'm frustrated. I'm beginning to wonder whether having 4:3 resolution stretched out to a 16:9 aspect ratio display might be a lesser evil than using Debian, when it is even more annoying now (relative to FreeBSD) than it was five years ago. tl;dr summary: FreeBSD is "power-user" friendly. Linux-based systems are getting increasingly "dumbed-down user" obsequious, to the detriment of people who like being able to customize the system's behavior (or, y'know, actually troubleshoot it at all). -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgp9MT6EerY3q.pgp Description: PGP signature
xdm-options - non-bsd user needs bsd rc.d advice
Hi. I'm a BSD idiot I use [Debian] linux. rc.d question I'm trying to release a project (just below) to the widest possible unix audience. I need a line in "/etc/inittab" and to have a start/stop in "/etc/rc.d", nothing unusual I think. I read many freeBSD rc.d materials and it only convinced me as much as I'd learned: if I'm not running BSD I don't know enough to talk about it :) I'm not sure how a real BSD hacker would place a "simple start stop". Not where or how, not even after reading the docs. Also I'm not sure the project is good enough to warrant further testing / if the casual user might save time / effort with it. Tell me what you think if you have time! Who doesn't want feedback? http://sourceforge.net/projects/xdm-options/ https://sourceforge.net/projects/xdm-options/ (second has httpS) (xdm sample scripts but "complete / round trip". chooser, login, desktop chooser, xdm server: by menu with no hacking required on any unix, saving the casual xdm interested person time in use or setup, is my hope) ... it uses no libs at all If anyone would like to quickly comment I'd love to hear why bsd would be a better choice than ubantu (for what audience it is better). Thanks all, John ___ 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: Running two daemon instances -- rc.d or not?
On Mon, 24 Jan 2011 13:16:29 -0500, Tom Worster wrote: > I need to set up a server with two instances of SphinxSearch searchd > (listening on different ports, of course). > > What's a good way to do it? > > Copying /usr/local/etc/rc.d/sphinxsearch to > /usr/local/etc/rc.d/sphinxsearch2 and editing that doesn't feel very > attractive. It should work, though. If it's "the simplest thing that could possible work"[1], why not go for it? [1] http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html ___ 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"
Running two daemon instances -- rc.d or not?
I need to set up a server with two instances of SphinxSearch searchd (listening on different ports, of course). What's a good way to do it? Copying /usr/local/etc/rc.d/sphinxsearch to /usr/local/etc/rc.d/sphinxsearch2 and editing that doesn't feel very attractive. tnx tom ___ 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: rc.d and environment variables
RW wrote: > > > > > > I'm not sure this will work. The initial question was about > > > > > > how to obtain an environmental variable. If the rc.d script > > > > > > of svnserve sources /etc/rc.conf and/or /etc/rc.conf.local, > > > > > > it is okay, > > > > > > > > > > They do. rc.d scripts all start by sucking in rc.subr, which in > > > > > turn pulls in the rc.conf files. > > > > > > > > So how do I make the /usr/local/etc/rc.d/svnserve script suck in > > > > KRB5_KTNAME for the "svn" user from the rc.conf* files? > > > > > > Just export it from rc.conf > > > > If exported from rc.conf, it will affect all daemons. I need to set it > > only for svnserve or for the svn user (which is equivalent in my > > case). > > [ "$name" = "svnserve" ] && export KRB5_KTNAME="/home/svn/svn.keytab" This looks really ugly. A thorough examination of /etc/rc.subr shows that a startup script sources a certain /etc/rc.conf.d/"$_name". Maybe I should try to place "export KRB5_KTNAME=/home/svn/svn.keytab" there. At least /etc/rc.conf.d/svnserve will be sourced only once at svnserve startup, and not hundreds of times like rc.conf. But anyway, I don't like the idea of placing commands (not variables) in /etc/rc.conf* There should be support for the rc.d framework to assign limits, environment variables and login classes. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: rc.d and environment variables
Da Rock wrote: [dd] > >I really don't know what the security implications will be if > >/etc/krb5.keytab is readable by anyone besides the root user? Do you > >have a clue about it? There are other services' keys stored there > >besides svn (host/*, cvs/* etc). > > > > > At the risk of getting laughed off stage, and pulling in yet another > service, what about ldap? I believe there is supposed to be a way to > store keytabs in ldap, which theoretically would mean only the > particular services would be able to access their keytabs. No matter where we store the keytabs, if it is not the default location (/etc/krb5.keytab for FreeBSD), we face the same problem of telling the server application about the alternative location of the keytab. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: rc.d and environment variables
On Fri, 24 Dec 2010 15:29:01 +0600 Victor Sudakov wrote: > RW wrote: > > > > > > > > > I'm not sure this will work. The initial question was about > > > > > how to obtain an environmental variable. If the rc.d script > > > > > of svnserve sources /etc/rc.conf and/or /etc/rc.conf.local, > > > > > it is okay, > > > > > > > > They do. rc.d scripts all start by sucking in rc.subr, which in > > > > turn pulls in the rc.conf files. > > > > > > So how do I make the /usr/local/etc/rc.d/svnserve script suck in > > > KRB5_KTNAME for the "svn" user from the rc.conf* files? > > > > Just export it from rc.conf > > If exported from rc.conf, it will affect all daemons. I need to set it > only for svnserve or for the svn user (which is equivalent in my > case). [ "$name" = "svnserve" ] && export KRB5_KTNAME="/home/svn/svn.keytab" ___ 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: rc.d and environment variables
On 12/24/10 19:37, Victor Sudakov wrote: Da Rock wrote: Doesn't the rc.d script run as root initially and then a method (default flags, etc) is used to change the owner to a nobody (restricted privilege user)? Just my 2c, but please correct me if I'm wrong. That is probably correct, rc.subr does "su -m $user", but the login class is not applied there, nor is the users's shell called. Exactly. Which means that you'd have to adapt root's env because root's shell would be called(?). In this case, how do I limit the variables's visibility only to the particular daemon (svnserve) or particular user (svn)? PITA, but as an alternative couldn't all the keytabs be stored in the same _secure_ location? Then a global env could be used. I really don't know what the security implications will be if /etc/krb5.keytab is readable by anyone besides the root user? Do you have a clue about it? There are other services' keys stored there besides svn (host/*, cvs/* etc). At the risk of getting laughed off stage, and pulling in yet another service, what about ldap? I believe there is supposed to be a way to store keytabs in ldap, which theoretically would mean only the particular services would be able to access their keytabs. ___ 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: rc.d and environment variables
Da Rock wrote: > > > > > >>Doesn't the rc.d script run as root initially and then a method (default > >>flags, etc) is used to change the owner to a nobody (restricted > >>privilege user)? Just my 2c, but please correct me if I'm wrong. > >> > > > >That is probably correct, rc.subr does "su -m $user", but the login > >class is not applied there, nor is the users's shell called. > > > > > Exactly. Which means that you'd have to adapt root's env because root's > shell would be called(?). In this case, how do I limit the variables's visibility only to the particular daemon (svnserve) or particular user (svn)? > > PITA, but as an alternative couldn't all the keytabs be stored in the > same _secure_ location? Then a global env could be used. I really don't know what the security implications will be if /etc/krb5.keytab is readable by anyone besides the root user? Do you have a clue about it? There are other services' keys stored there besides svn (host/*, cvs/* etc). -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: rc.d and environment variables
RW wrote: > > > > > > > I'm not sure this will work. The initial question was about > > > > how to obtain an environmental variable. If the rc.d script > > > > of svnserve sources /etc/rc.conf and/or /etc/rc.conf.local, > > > > it is okay, > > > > > > They do. rc.d scripts all start by sucking in rc.subr, which in > > > turn pulls in the rc.conf files. > > > > So how do I make the /usr/local/etc/rc.d/svnserve script suck in > > KRB5_KTNAME for the "svn" user from the rc.conf* files? > > Just export it from rc.conf If exported from rc.conf, it will affect all daemons. I need to set it only for svnserve or for the svn user (which is equivalent in my case). -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: rc.d and environment variables
On Fri, 24 Dec 2010 09:34:27 +0600 Victor Sudakov wrote: > Lowell Gilbert wrote: > > > > > I'm not sure this will work. The initial question was about > > > how to obtain an environmental variable. If the rc.d script > > > of svnserve sources /etc/rc.conf and/or /etc/rc.conf.local, > > > it is okay, > > > > They do. rc.d scripts all start by sucking in rc.subr, which in > > turn pulls in the rc.conf files. > > So how do I make the /usr/local/etc/rc.d/svnserve script suck in > KRB5_KTNAME for the "svn" user from the rc.conf* files? Just export it from rc.conf ___ 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: rc.d and environment variables
On 12/24/10 18:03, Victor Sudakov wrote: Da Rock wrote: [dd] Doesn't the rc.d script run as root initially and then a method (default flags, etc) is used to change the owner to a nobody (restricted privilege user)? Just my 2c, but please correct me if I'm wrong. That is probably correct, rc.subr does "su -m $user", but the login class is not applied there, nor is the users's shell called. Exactly. Which means that you'd have to adapt root's env because root's shell would be called(?). PITA, but as an alternative couldn't all the keytabs be stored in the same _secure_ location? Then a global env could be used. ___ 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: rc.d and environment variables
Da Rock wrote: [dd] > Doesn't the rc.d script run as root initially and then a method (default > flags, etc) is used to change the owner to a nobody (restricted > privilege user)? Just my 2c, but please correct me if I'm wrong. That is probably correct, rc.subr does "su -m $user", but the login class is not applied there, nor is the users's shell called. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: rc.d and environment variables
On 12/24/10 13:50, Victor Sudakov wrote: Polytropon wrote: Of course I can always write my own script or put something like su -l svn -c 'usr/local/bin/svnserve -d --listen-port=3690 bla bla' into /etc/rc.local, but the question was about the rc.d framework. Environmental variables cannot be controlled by the rc.d framework, as far as I understand. Using login classes to define them should be the correct way. > From "man login.conf": setenv listA comma-separated list of environment variables and values to which they are to be set. I thought of that, and in fact I wrote about it in the very first message: I tried to do this via a login class for the svn user, but it did not work. If I first 'su -l svn' and then start the daemon manually, the environment variable is set all right, but not when it is started from /usr/local/etc/rc.d/svnserve. What did you enter for the svnserve user in /etc/login.conf, svn:\ :setenv=KRB5_KTNAME=~/svn.keytab:\ :tc=default: and did you make sure there is no override setting in the corresponding user's ~/.login.conf? I am pretty sure because when I login interactively as svn, I see $ whoami svn $ printenv | grep KT KRB5_KTNAME=/home/svn/svn.keytab $ But it does not work for the rc.d script. Doesn't the rc.d script run as root initially and then a method (default flags, etc) is used to change the owner to a nobody (restricted privilege user)? Just my 2c, but please correct me if I'm wrong. ___ 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: rc.d and environment variables
Polytropon wrote: > > Of course I can always write my own script or put something like > > su -l svn -c 'usr/local/bin/svnserve -d --listen-port=3690 bla bla' > > into /etc/rc.local, but the question was about the rc.d framework. > > Environmental variables cannot be controlled by the rc.d > framework, as far as I understand. Using login classes to > define them should be the correct way. > > >From "man login.conf": > > setenv listA comma-separated list of > environment variables and > values to which they are to > be set. I thought of that, and in fact I wrote about it in the very first message: > > I tried to do this via a login class for the svn user, but it did > > not work. If I first 'su -l svn' and then start the daemon > > manually, the environment variable is set all right, but not when > > it is started from /usr/local/etc/rc.d/svnserve. > > What did you enter for the svnserve user in /etc/login.conf, svn:\ :setenv=KRB5_KTNAME=~/svn.keytab:\ :tc=default: > and did you make sure there is no override setting in the > corresponding user's ~/.login.conf? I am pretty sure because when I login interactively as svn, I see $ whoami svn $ printenv | grep KT KRB5_KTNAME=/home/svn/svn.keytab $ But it does not work for the rc.d script. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: rc.d and environment variables
Polytropon wrote: > > I have tried putting "setenv KRB5_KTNAME /home/svn/svn.keytab" in > > ~svn/.cshrc, it does not help. Evidently the svn user's login shell is > > not called when "/usr/local/etc/rc.d/svnserve start" is called. > > I did already assume something like that. This mechanism > relies on some kind of login that causes the shell to be > run (usually an interactive shell), which isn't the case > here. Besides, the login.conf capability database does not seem to be used by the rc.d framework either, which is sad. > > > Excuse me? What does /etc/rc.local have to do with the rc.subr > > framework? > > Nothing. The /etc/rc.local script is executed along with > the system startup. It is considered obsolete (I think), > but it should work, and therefore be able to set a system-wide > environment variable. I guess any environment variable set in the /etc/rc.local script would be available in the script itself and its children, but not system wide. Even if it were, remember, I do not need to change KRB5_KTNAME system wide, but just for one particular user. [dd] > > Anyway, did you find a way to use some _flags= setting for > /etc/rc.conf to be used by svnserve? This would be the > method most other programs handle things like configuration > flags that are not set by an own config file. To my regret, this is not a svnserve option, it is a setting used by libsasl2 with which svnserve is linked. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: rc.d and environment variables
Lowell Gilbert wrote: > > > I'm not sure this will work. The initial question was about > > how to obtain an environmental variable. If the rc.d script > > of svnserve sources /etc/rc.conf and/or /etc/rc.conf.local, > > it is okay, > > They do. rc.d scripts all start by sucking in rc.subr, which in turn > pulls in the rc.conf files. So how do I make the /usr/local/etc/rc.d/svnserve script suck in KRB5_KTNAME for the "svn" user from the rc.conf* files? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: rc.d and environment variables
Polytropon wrote: [dd] > > Anyway, if svnserve is able to be passed a command string > to, a setting like > > svnserve_flags="... -k /home/svn/svn.keytab ..." No, this is not a svnserve option, it is a setting used by libsasl2 with which svnserve is linked (or even by libkrb5.so). > > coded in /etc/rc.conf or /etc/rc.conf.local would work, > and would also be the preferred method for such things. > In fact, I've not come across the need to have an environmental > variable to store a configuration setting for an additional > program, as such kind of variables is mainly for "low level" > system use, mostly. This need is indeed rare, but not nonexistent. In fact, if cyrus-sasl implemented the keytab: configuration option, there would be no need to set KRB5_KTNAME prior to starting svnserve. I also remember a need to pass $ORACLE_HOME to apache on start for some PHP module to work correctly. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: rc.d and environment variables
On Fri, 24 Dec 2010 09:13:53 +0600, Victor Sudakov wrote: > Of course I can always write my own script or put something like > su -l svn -c 'usr/local/bin/svnserve -d --listen-port=3690 bla bla' > into /etc/rc.local, but the question was about the rc.d framework. Environmental variables cannot be controlled by the rc.d framework, as far as I understand. Using login classes to define them should be the correct way. >From "man login.conf": setenv listA comma-separated list of environment variables and values to which they are to be set. What did you enter for the svnserve user in /etc/login.conf, and did you make sure there is no override setting in the corresponding user's ~/.login.conf? A valid setting should look like this, :setenv=KRB5_KTNAME=/home/svn/svn.keytab: embedded into the proper structures. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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: rc.d and environment variables
On Fri, 24 Dec 2010 09:07:35 +0600, Victor Sudakov wrote: > I have tried putting "setenv KRB5_KTNAME /home/svn/svn.keytab" in > ~svn/.cshrc, it does not help. Evidently the svn user's login shell is > not called when "/usr/local/etc/rc.d/svnserve start" is called. I did already assume something like that. This mechanism relies on some kind of login that causes the shell to be run (usually an interactive shell), which isn't the case here. > Excuse me? What does /etc/rc.local have to do with the rc.subr > framework? Nothing. The /etc/rc.local script is executed along with the system startup. It is considered obsolete (I think), but it should work, and therefore be able to set a system-wide environment variable. This script is not in any relation with the rc.subr framework. > Of course I can abandon the standard /usr/local/etc/rc.d/svnserve > script and write my own one, or start svnserve from /etc/rc.local > (which I will do if I don't find a more graceful way), but it is not > what the question was about. Yes, I fully understand: You need to set an environmental variable that will be picked up later on by the svnserve program (in some way, not neccessarily by accessing a file). That's why I think KRB5_KTNAME=/home/svn/svn.keytab; export KRB5_KTNAME in /etc/rc.local should create the $KRB5_KTNAME environment variable at system startup. Anyway, did you find a way to use some _flags= setting for /etc/rc.conf to be used by svnserve? This would be the method most other programs handle things like configuration flags that are not set by an own config file. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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: rc.d and environment variables
Jerry McAllister wrote: > > > > > > The svnserve daemon is started from /usr/local/etc/rc.d/svnserve. I need > > > to > > > pass the environment variable KRB5_KTNAME=/home/svn/svn.keytab to the > > > daemon on start. How do I do that? > > > > If the user corresponding to the svnservice has a login > > shell, which would usually be the system's default > > dialog shell, the C shell, you could edit /etc/csh.cshrc > > and put > > > > setenv KRB5_KTNAME /home/svn/svn.keytab > > > > to make it a system-wide setting (or use the user's > > ~/.cshrc for a user-only setting). > > > > In case the user does NOT have a default shell, I think > > you should be able to also define a system-wide environmental > > variable by coding > > > > KRB5_KTNAME=/home/svn/svn.keytab; export KRB5_KTNAME > > > > into /etc/rc.local (which will be executed at system startup). > > See "man rc.local" for details. > > > > Put it in /etc/rc.conf and have your script read up rc.conf and > set any of the stuff in there it is interested in, such as KRB5_KINAME. What "my script" do you mean? The script /usr/local/etc/rc.d/svnserve is already installed by the port, how can I make the stock script read up KRB5_KTNAME from rc.conf? And besides, KRB5_KTNAME should be only defined for the svn user (the user svnserve runs from) and not any other user. > I think that is the officially sanctioned way of doing such things. Of course I can always write my own script or put something like su -l svn -c 'usr/local/bin/svnserve -d --listen-port=3690 bla bla' into /etc/rc.local, but the question was about the rc.d framework. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: rc.d and environment variables
Polytropon wrote: > > > > The svnserve daemon is started from /usr/local/etc/rc.d/svnserve. I need to > > pass the environment variable KRB5_KTNAME=/home/svn/svn.keytab to the > > daemon on start. How do I do that? > > If the user corresponding to the svnservice has a login > shell, which would usually be the system's default > dialog shell, the C shell, you could edit /etc/csh.cshrc > and put > > setenv KRB5_KTNAME /home/svn/svn.keytab > > to make it a system-wide setting (or use the user's > ~/.cshrc for a user-only setting). I have tried putting "setenv KRB5_KTNAME /home/svn/svn.keytab" in ~svn/.cshrc, it does not help. Evidently the svn user's login shell is not called when "/usr/local/etc/rc.d/svnserve start" is called. > In case the user does NOT have a default shell, I think > you should be able to also define a system-wide environmental > variable by coding > > KRB5_KTNAME=/home/svn/svn.keytab; export KRB5_KTNAME > > into /etc/rc.local (which will be executed at system startup). > See "man rc.local" for details. Excuse me? What does /etc/rc.local have to do with the rc.subr framework? Of course I can abandon the standard /usr/local/etc/rc.d/svnserve script and write my own one, or start svnserve from /etc/rc.local (which I will do if I don't find a more graceful way), but it is not what the question was about. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: rc.d and environment variables
Polytropon writes: > I'm not sure this will work. The initial question was about > how to obtain an environmental variable. If the rc.d script > of svnserve sources /etc/rc.conf and/or /etc/rc.conf.local, > it is okay, They do. rc.d scripts all start by sucking in rc.subr, which in turn pulls in the rc.conf files. ___ 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: rc.d and environment variables
On Thu, 23 Dec 2010 14:14:43 -0500, Jerry McAllister wrote: > On Thu, Dec 23, 2010 at 08:12:49PM +0100, Polytropon wrote: > > > On Thu, 23 Dec 2010 23:27:52 +0600, Victor Sudakov > > wrote: > > > Colleagues, > > > > > > The svnserve daemon is started from /usr/local/etc/rc.d/svnserve. I need > > > to > > > pass the environment variable KRB5_KTNAME=/home/svn/svn.keytab to the > > > daemon on start. How do I do that? > > > > If the user corresponding to the svnservice has a login > > shell, which would usually be the system's default > > dialog shell, the C shell, you could edit /etc/csh.cshrc > > and put > > > > setenv KRB5_KTNAME /home/svn/svn.keytab > > > > to make it a system-wide setting (or use the user's > > ~/.cshrc for a user-only setting). > > > > In case the user does NOT have a default shell, I think > > you should be able to also define a system-wide environmental > > variable by coding > > > > KRB5_KTNAME=/home/svn/svn.keytab; export KRB5_KTNAME > > > > into /etc/rc.local (which will be executed at system startup). > > See "man rc.local" for details. > > > > Put it in /etc/rc.conf and have your script read up rc.conf and > set any of the stuff in there it is interested in, such as KRB5_KINAME. > > I think that is the officially sanctioned way of doing such things. I'm not sure this will work. The initial question was about how to obtain an environmental variable. If the rc.d script of svnserve sources /etc/rc.conf and/or /etc/rc.conf.local, it is okay, but what if a binary wants to read the variable by the standard way, i. e. int main(int argc, char *argv[], char *envp[]) then there will be no access to files like /etc/rc.conf. This means the variable will have to be a validly set environmental variable that can be output by % env or a similar program (or mechanism). Settings from /etc/rc.conf do NOT show up as environmental variables. Anyway, if svnserve is able to be passed a command string to, a setting like svnserve_flags="... -k /home/svn/svn.keytab ..." coded in /etc/rc.conf or /etc/rc.conf.local would work, and would also be the preferred method for such things. In fact, I've not come across the need to have an environmental variable to store a configuration setting for an additional program, as such kind of variables is mainly for "low level" system use, mostly. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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: rc.d and environment variables
On Thu, Dec 23, 2010 at 08:12:49PM +0100, Polytropon wrote: > On Thu, 23 Dec 2010 23:27:52 +0600, Victor Sudakov > wrote: > > Colleagues, > > > > The svnserve daemon is started from /usr/local/etc/rc.d/svnserve. I need to > > pass the environment variable KRB5_KTNAME=/home/svn/svn.keytab to the > > daemon on start. How do I do that? > > If the user corresponding to the svnservice has a login > shell, which would usually be the system's default > dialog shell, the C shell, you could edit /etc/csh.cshrc > and put > > setenv KRB5_KTNAME /home/svn/svn.keytab > > to make it a system-wide setting (or use the user's > ~/.cshrc for a user-only setting). > > In case the user does NOT have a default shell, I think > you should be able to also define a system-wide environmental > variable by coding > > KRB5_KTNAME=/home/svn/svn.keytab; export KRB5_KTNAME > > into /etc/rc.local (which will be executed at system startup). > See "man rc.local" for details. > Put it in /etc/rc.conf and have your script read up rc.conf and set any of the stuff in there it is interested in, such as KRB5_KINAME. I think that is the officially sanctioned way of doing such things. jerry > > -- > Polytropon > Magdeburg, Germany > Happy FreeBSD user since 4.0 > Andra moi ennepe, Mousa, ... > ___ > 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" ___ 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: rc.d and environment variables
On Thu, 23 Dec 2010 23:27:52 +0600, Victor Sudakov wrote: > Colleagues, > > The svnserve daemon is started from /usr/local/etc/rc.d/svnserve. I need to > pass the environment variable KRB5_KTNAME=/home/svn/svn.keytab to the > daemon on start. How do I do that? If the user corresponding to the svnservice has a login shell, which would usually be the system's default dialog shell, the C shell, you could edit /etc/csh.cshrc and put setenv KRB5_KTNAME /home/svn/svn.keytab to make it a system-wide setting (or use the user's ~/.cshrc for a user-only setting). In case the user does NOT have a default shell, I think you should be able to also define a system-wide environmental variable by coding KRB5_KTNAME=/home/svn/svn.keytab; export KRB5_KTNAME into /etc/rc.local (which will be executed at system startup). See "man rc.local" for details. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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"
rc.d and environment variables
Colleagues, The svnserve daemon is started from /usr/local/etc/rc.d/svnserve. I need to pass the environment variable KRB5_KTNAME=/home/svn/svn.keytab to the daemon on start. How do I do that? I tried to do this via a login class for the svn user, but it did not work. If I first 'su -l svn' and then start the daemon manually, the environment variable is set all right, but not when it is started from /usr/local/etc/rc.d/svnserve. All this is happening on 8.1-RELEASE-p2. Thanks in advance for any help. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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"
rc.d and environment variables
Colleagues, The svnserve daemon is started from /usr/local/etc/rc.d/svnserve. I need to pass the environment variable KRB5_KTNAME=/home/svn/svn.keytab to the daemon on start. How do I do that? I tried to do this via a login class for the svn user, but it did not work. If I first 'su -l svn' and then start the daemon manually, the environment variable is set all right, but not when it is started from /usr/local/etc/rc.d/svnserve. All this is happening on 8.1-RELEASE-p2. Thanks in advance for any help. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: /etc/rc.d/netif & em interfaces
On Wed, Dec 1, 2010 at 11:15 AM, Brian McCann wrote: > On Wed, Dec 1, 2010 at 10:51 AM, Brian McCann wrote: > >> >> This isn't a Dell PoweEdge, but at least this is two platforms it's >> happening on now. Strangely, my VMWare virtual machines that use the >> em driver do not have this problem. >> >> TSO is disabled. >> >> I just tried adding "up" to the $ifconfig_emX lines in rc.conf, and it >> didn't help. >> >> What I discovered (and I'm still playing with a bit), is that it has >> to do with checksum offloading. If you run "ifconfig emX -rxcsum", >> the interface comes back to life. I just added "-rxcsum" to the >> $ifconfig_emX lines in rc.conf, and I can run "/etc/rc.d/netif >> restart" now, and the NIC continues to work fine. >> >> I tried emailing the folks @ Intel that are mentioned in the man page >> for the em driver, but the mail bounced... >> >> --Brian >> >> -- > > Brian (and everyone else reading the thread), > > I just found this...the patch was submitted some time ago, but somehow > didn't make it into 8.1. > http://www.freebsd.org/cgi/query-pr.cgi?pr=141843 . I'm trying it > now. I'll keep you posted. > > --Brian > So, the patch didn't work against 8.1-RELEASE...it wouldn't compile since there were some new files in the driver package. So, I checked out the e1000 driver from HEAD and put it in my src tree (in addition to some supporting files that were necessary), and compiled that. I went through the SVN notes for the e1000 files, found the SVN version number, and updated all the files listed in the commit. Here's the link: http://svn.freebsd.org/viewvc/base?view=revision&revision=209616 . Once I installed the new kernel module, all was well...no more problems. Hopefully this will be included in 8.2-RELEASE. Thanks, and good luck to all! --Brian -- _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ Brian McCann "I don't have to take this abuse from you -- I've got hundreds of people waiting to abuse me." -- Bill Murray, "Ghostbusters" ___ 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: /etc/rc.d/netif & em interfaces
On Wed, Dec 1, 2010 at 10:51 AM, Brian McCann wrote: > > This isn't a Dell PoweEdge, but at least this is two platforms it's > happening on now. Strangely, my VMWare virtual machines that use the > em driver do not have this problem. > > TSO is disabled. > > I just tried adding "up" to the $ifconfig_emX lines in rc.conf, and it > didn't help. > > What I discovered (and I'm still playing with a bit), is that it has > to do with checksum offloading. If you run "ifconfig emX -rxcsum", > the interface comes back to life. I just added "-rxcsum" to the > $ifconfig_emX lines in rc.conf, and I can run "/etc/rc.d/netif > restart" now, and the NIC continues to work fine. > > I tried emailing the folks @ Intel that are mentioned in the man page > for the em driver, but the mail bounced... > > --Brian > > -- Brian (and everyone else reading the thread), I just found this...the patch was submitted some time ago, but somehow didn't make it into 8.1. http://www.freebsd.org/cgi/query-pr.cgi?pr=141843 . I'm trying it now. I'll keep you posted. --Brian -- _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ Brian McCann "I don't have to take this abuse from you -- I've got hundreds of people waiting to abuse me." -- Bill Murray, "Ghostbusters" ___ 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: /etc/rc.d/netif & em interfaces
On Wed, Dec 1, 2010 at 9:29 AM, Brian A. Seklecki (CFI NOC) wrote: > >> To make this problem even stranger, I can make a connection from the >> server to a workstation without issue. It appears to only be incoming > > We've seen something very similar to this; we assumed it was > EEPROM corruption. > > Is this a Dell PowerEdge by chance? > > Do you have TSO enabled? (-tso or tso flag in $ifconfig_emX) > > Does appending "up" to the end of if $ifconfig_emX solve the problem? > > ~BAS > This isn't a Dell PoweEdge, but at least this is two platforms it's happening on now. Strangely, my VMWare virtual machines that use the em driver do not have this problem. TSO is disabled. I just tried adding "up" to the $ifconfig_emX lines in rc.conf, and it didn't help. What I discovered (and I'm still playing with a bit), is that it has to do with checksum offloading. If you run "ifconfig emX -rxcsum", the interface comes back to life. I just added "-rxcsum" to the $ifconfig_emX lines in rc.conf, and I can run "/etc/rc.d/netif restart" now, and the NIC continues to work fine. I tried emailing the folks @ Intel that are mentioned in the man page for the em driver, but the mail bounced... --Brian -- _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ Brian McCann "I don't have to take this abuse from you -- I've got hundreds of people waiting to abuse me." -- Bill Murray, "Ghostbusters" ___ 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: /etc/rc.d/netif & em interfaces
To make this problem even stranger, I can make a connection from the server to a workstation without issue. It appears to only be incoming We've seen something very similar to this; we assumed it was EEPROM corruption. Is this a Dell PowerEdge by chance? Do you have TSO enabled? (-tso or tso flag in $ifconfig_emX) Does appending "up" to the end of if $ifconfig_emX solve the problem? ~BAS connections. Thanks again, --Brian ___ 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: /etc/rc.d/netif & em interfaces
On Wed, Dec 1, 2010 at 8:42 AM, Brian McCann wrote: > I'm having an interesting problem on a fresh 8.1-RELEASE1 install. > I'll start by saying this didn't happen on 7.1 on the same exact > machine. I've been fighting with this for 2 days now and have come up > with no answers on my own, so I'm hoping one of you guys can have some > insight here. > > When I run "/etc/rc.d/netif restart" (also happens with a stop / > start) , I can no longer get to the server over the network. When I > do a packet capture on my workstation, it looks like it's MAC address > changed somehow. The first two bytes of the address are different. > For example, the real MAC is 00:15:17:1b:cf:7a , but I'll see the > replies from a MAC of "02:67:17:1b:cf:7a". After each run of > "/etc/rc.d/netif restart", the first two bytes will change again. I > have to reboot the server to get it working again. The "em" cards in > question are: > > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.0.5 > dev.em.0.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x8086 > subdevice=0x348d class=0x02 > dev.em.1.%desc: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 > dev.em.1.%pnpinfo: vendor=0x8086 device=0x1076 subvendor=0x8086 > subdevice=0x348d class=0x02 > > FWIW, this is on an Intel 1530 series server. > > Thanks in advance, > --Brian I botched the problem description slightly. In the packet capture on the workstation, the server's MAC is always correct. The response (SYN/ACK packet) from the server is destined to the wrong MAC address. The first two bytes are wrong somehow. The arp table on the server is correct. If I run "arp -ad", the problem remains. I've also produced this problem by doing "ifconfig em1 down" then "ifconfig em1 up". To make this problem even stranger, I can make a connection from the server to a workstation without issue. It appears to only be incoming connections. Thanks again, --Brian -- _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ Brian McCann "I don't have to take this abuse from you -- I've got hundreds of people waiting to abuse me." -- Bill Murray, "Ghostbusters" ___ 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"
/etc/rc.d/netif & em interfaces
I'm having an interesting problem on a fresh 8.1-RELEASE1 install. I'll start by saying this didn't happen on 7.1 on the same exact machine. I've been fighting with this for 2 days now and have come up with no answers on my own, so I'm hoping one of you guys can have some insight here. When I run "/etc/rc.d/netif restart" (also happens with a stop / start) , I can no longer get to the server over the network. When I do a packet capture on my workstation, it looks like it's MAC address changed somehow. The first two bytes of the address are different. For example, the real MAC is 00:15:17:1b:cf:7a , but I'll see the replies from a MAC of "02:67:17:1b:cf:7a". After each run of "/etc/rc.d/netif restart", the first two bytes will change again. I have to reboot the server to get it working again. The "em" cards in question are: dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.0.5 dev.em.0.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x8086 subdevice=0x348d class=0x02 dev.em.1.%desc: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 dev.em.1.%pnpinfo: vendor=0x8086 device=0x1076 subvendor=0x8086 subdevice=0x348d class=0x02 FWIW, this is on an Intel 1530 series server. Thanks in advance, --Brian -- _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ Brian McCann "I don't have to take this abuse from you -- I've got hundreds of people waiting to abuse me." -- Bill Murray, "Ghostbusters" ___ 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: /usr/local/etc/rc.d/imapproxyd start
On Fri, Sep 17, 2010 at 01:02:03PM +0200, n dhert wrote: > There seems to be a problem with starting up the IMAP proxy server > imapproxyd: > # /usr/local/etc/rc.d/imapproxyd start > says > Starting imapproxyd. > but doesn't return the # prompt ... > # ps -jawx | grep imap > root 21490 21426 21490 64248 1 S+ 3 0:00.01 /bin/sh > /usr/local/etc/rc.d/imapproxyd start > root 21496 21490 21490 64218 1 S+ 3 0:00.01 /usr/local/sbin/in.imapproxyd > > I would expect the /bin/sh line to disappear and the # prompt to come back. And so it should. I have just installed and tested it, and it works fine. The only way I can replicate the behaviour you report is if I misspell the name of the backend IMAP server - so start checking there. If it's not a typo, it is likely some other variety of DNS error. > > If (from another terminal window) I do > # /usr/local/etc/rc.d/imapproxyd stop > is says > Stopping imapproxyd. > # (returns the prompt) > > If the first window, it says: > Terminated > /usr/local/etc/rc.d/imapproxyd: WARNING: failed to start imapproxyd > ?? > > 1. what is wrong here and how to correct it ? > > 2. also, although I do have a user nobody and a group nobody in FreeBSD 8 > and the config file /usr/local/etc/imapproxyd.conf specifies (default > setting) > proc_username nobody > proc_groupname nobody > I wonder why the processes (ps -jawx) show root as the process owner ? It will need to start as root in order to bind all the resources it needs, before dropping privileges. Remember that only root can bind ports below 1024. It works fine here. Dan -- Daniel Bye _ ASCII ribbon campaign ( ) - against HTML, vCards and X - proprietary attachments in e-mail / \ pgp4BlcxyfoWN.pgp Description: PGP signature
/usr/local/etc/rc.d/imapproxyd start
There seems to be a problem with starting up the IMAP proxy server imapproxyd: # /usr/local/etc/rc.d/imapproxyd start says Starting imapproxyd. but doesn't return the # prompt ... # ps -jawx | grep imap root 21490 21426 21490 64248 1 S+ 3 0:00.01 /bin/sh /usr/local/etc/rc.d/imapproxyd start root 21496 21490 21490 64218 1 S+ 3 0:00.01 /usr/local/sbin/in.imapproxyd I would expect the /bin/sh line to disappear and the # prompt to come back. If (from another terminal window) I do # /usr/local/etc/rc.d/imapproxyd stop is says Stopping imapproxyd. # (returns the prompt) If the first window, it says: Terminated /usr/local/etc/rc.d/imapproxyd: WARNING: failed to start imapproxyd ?? 1. what is wrong here and how to correct it ? 2. also, although I do have a user nobody and a group nobody in FreeBSD 8 and the config file /usr/local/etc/imapproxyd.conf specifies (default setting) proc_username nobody proc_groupname nobody I wonder why the processes (ps -jawx) show root as the process owner ? ___ 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"
quasselcore rc.d
Does anyone have a rc.d script to start quasselcore? A search of the web didn't produce any hits that I saw. If not, do I understand that using tje daemon command is the way to go? Thanks Kurt Hindenburg kurt.hindenb...@gmail.com ___ 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: iwi0 and spontaneous reboot on /etc/rc.d/netif restart
Hello, I just upgraded to 8.0-RELEASE-p2 from 7.2 and I'm also seeing kernel crashes and reboots after running /etc/rc.d/netif restart, which didn't occur with 7.2. This is reproducible on demand. After writing this email I found the following PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/144755 % /etc/rc.d/netif restart Apr 30 08:57:04 met wpa_supplicant[1785]: CTRL-EVENT-SCAN-RESULTS Apr 30 08:57:04 met wpa_supplicant[1719]: CTRL-EVENT-SCAN-RESULTS Apr 30 08:57:04 met wpa_supplicant[1719]: Trying to associate with 0:xxx:aa (SSID='blah' freq=2447 MHz) Apr 30 08:57:04 met wpa_supplicant[1785]: Trying to associate with 00:xx:aa (SSID='blah' freq=2447 MHz) Apr 30 08:57:04 met wpa_supplicant[1785]: Associated with 00:xx:aa Apr 30 08:57:04 met kernel: wlan0: link state changed to UP Apr 30 08:57:05 met kernel: iwi0: firmware error Apr 30 08:57:04 met wpa_supplicant[1719]: Associated with 00:xx:aa Apr 30 08:57:05 met kernel: iwi0: need multicast update callback Apr 30 08:57:10 met kernel: iwi0: device timeout Apr 30 08:57:15 met wpa_supplicant[1719]: Authentication with 00:xx:aa timed out. Apr 30 08:57:15 met wpa_supplicant[1785]: Authentication with 00:xx:aa timed out. Apr 30 08:57:15 met kernel: wlan0: link state changed to DOWN Apr 30 08:57:15 met wpa_supplicant[1719]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Apr 30 08:57:15 met wpa_supplicant[1785]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Apr 30 08:57:24 met dhclient[1876]: send_packet: Network is down Apr 30 08:58:01 met last message repeated 2 times ...crash and reboot... % kgdb kernel /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. ... This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: wlan0: ieee80211_new_state_locked: pending SCAN -> AUTH transition lost Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc49331d5 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0ad5b0c stack pointer = 0x28:0xc43bbb7c frame pointer = 0x28:0xc43bbc34 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (iwi0 taskq) trap number = 12 panic: page fault Uptime: 1m42s Physical memory: 1518 MB Dumping 69 MB: 54 38 22 6 % kldstat Id Refs AddressSize Name 1 95 0xc040 656394 kernel 21 0xc0a57000 b69c if_fxp.ko 32 0xc0a63000 2698cmiibus.ko 41 0xc0a8a000 f528 if_iwi.ko 56 0xc0a9a000 3fc40wlan.ko 61 0xc0ada000 7194 snd_ich.ko 72 0xc0ae2000 567b0sound.ko 81 0xc0b39000 87d8 atapicd.ko 91 0xc0b42000 4f6c atapicam.ko 101 0xc0b47000 d87c cpufreq.ko 111 0xc0b55000 30228iwi_bss.ko 121 0xc0b86000 2f2b0iwi_ibss.ko 131 0xc0bb6000 2f578iwi_monitor.ko 141 0xc0be6000 2ee0 wlan_acl.ko 151 0xc4858000 8000 linprocfs.ko 161 0xc4895000 26000linux.ko 171 0xc48f6000 3000 wlan_wep.ko 181 0xc48f9000 4000 wlan_tkip.ko 191 0xc48fe000 7000 wlan_ccmp.ko 201 0xc4cae000 9000 i915.ko % less /boot/loader.conf hw.ata.ata_dma="1" hw.ata.atapi_dma="1" kern.maxdsiz="734003200" kern.ipc.semmni=256 kern.ipc.semmns=512 kern.ipc.semmnu=256 sem_load="YES" atapicd_load="YES" atapicam_load="YES" cpufreq_load="YES" if_fxp_load="YES" snd_ich_load="YES" # stuff for wireless legal.intel_iwi.license_ack=1 if_iwi_load="YES" iwi_bss_load="YES" iwi_ibss_load="YES" iwi_monitor_load="YES" wlan_acl_load="YES" Here are the relevant parts from /etc/rc.conf wlans_iwi0="wlan0" ifconfig_wlan0="WPA DHCP" % cat /usr/src/sys/i386/conf/MY_KERNEL_CONFIG cpu I686_CPU ident MET_ATH_CX_2010-04-29 options SCHED_ULE options PREEMPTION #Enable kernel thread preemption options INET #InterNETworking options INET6 #IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT #MD is a potential root device options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options NFSLOCKD #Network Lock Manager options NFS_ROOT #NFS usable as /, requires NFSCLIENT options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMP
iwi0 and spontaneous reboot on /etc/rc.d/netif restart
Hi, over the last 6 months or so, I have been so unfortunate to experience spontaneous reboots when I restart netif. Most of the time it leaves no trace in logs, but this time I was "fortunate" enough to be able to scrible down something while in console. I hope someone can shed some light on this - and I will be happy to provide a config files if necessary - it's basicly a standard setup with iwi0, wpa_supplicant connecting via wpa. It is a T42 with a Intel 2200BG. There is no issues in other OSes, so I figure this to be a driver specific problem. This is from handwritten notes, so there may be some inaccuracies. It is FreeBSD 8.0-release. wlan0: ieee80211_new_state_locked: pending SCAN -> AUTH transition lost Fata trap 12: page fault while in kernel mode cpuid=0; apic id=00 fault virtual adress = 0xc4bd71b4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0f78867 stack pointer = 0x28:0xc439ab7c frame pointer = 0x28:0xc439ac34 code seqment= base 0x0, limit 0xf, type 0x16 = DPL 0, pres 1, def 32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (iwi0 taskq) trap number = 12 panic: page fault cpuid = 0 Uptime 13m9s Cannot dump. Device not defined or unavailable Automatic reboot in 15 seconds - press a key on the console to abort. Best Regards, Torgeir ___ 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: /etc/rc.d/program nice value
On Fri, 15 Jan 2010 13:50:23 -0500
Greg Larkin wrote:
> Nerius Landys wrote:
> > I'm running some programs using the /etc/rc.d/ and
> > /usr/local/etc/rc.d/ startup scripts. I am wondering if there is
> > some standard way to run these programs at a higher nice value.
>
> Hi Nerius,
>
> Check out the list of variables in /etc/rc.subr. This should help
> you:
>
> # ${name}_nicen Nice level to run ${command} at.
That will work if the script lets /etc/rc.subr start the daemon. If
it implements its own start function then ${name}_nice will have to be
explicitly supported by the script - not all do that unfortunately.
___
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: /etc/rc.d/program nice value
> That means you can write this in your /etc/rc.conf file: > > apache22_enable="YES" > apache22_nice="10" > > Hope that helps, Oh yes, that helps a lot. Thanks! ___ 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: /etc/rc.d/program nice value
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nerius Landys wrote:
> I'm running some programs using the /etc/rc.d/ and
> /usr/local/etc/rc.d/ startup scripts. I am wondering if there is some
> standard way to run these programs at a higher nice value.
Hi Nerius,
Check out the list of variables in /etc/rc.subr. This should help you:
# ${name}_nicen Nice level to run ${command} at.
That means you can write this in your /etc/rc.conf file:
apache22_enable="YES"
apache22_nice="10"
Hope that helps,
Greg
- --
Greg Larkin
http://www.FreeBSD.org/ - The Power To Serve
http://www.sourcehosting.net/ - Ready. Set. Code.
http://twitter.com/sourcehosting/ - Follow me, follow you
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFLULjv0sRouByUApARAv7zAJ4tbzuO/iixDQ4uXuko3eZV3vd3vQCgxS6A
+iD7qTmAyK5Dff6WWSihtY4=
=o29l
-END PGP SIGNATURE-
___
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"
/etc/rc.d/program nice value
I'm running some programs using the /etc/rc.d/ and /usr/local/etc/rc.d/ startup scripts. I am wondering if there is some standard way to run these programs at a higher nice value. ___ 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: rc.d script not working for Xmms2 :-(
no just avoid using ${name} in the command.
name is just a label used for creating unique variable names you can
use in rc.conf, it doesn't have to match any binary.
___
Thanks we're getting closer but some thing's still hinky!
rd1# /usr/local/etc/rc.d/xmms2d stop
/usr/local/etc/rc.d/xmms2d: WARNING: cannot read shebang line from
/usr/local/bin/xmms2d-launcher
xmms2d not running?
This is the latest incarnation of the script:
#!/bin/sh
# PROVIDE:xmms2d
#xmms2d_enable="YES"
. /etc/rc.subr
name="xmms2d"
rcvar=`set_rcvar`
command="/usr/local/bin/xmms2d-launcher -u kaya"
load_rc_config $name
run_rc_command "$1"
I gather I goofed up one part but which I cannot say!
___
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: rc.d script not working for Xmms2 :-(
On Fri, 08 Jan 2010 15:00:11 +0200
Kaya Saman wrote:
> name="xmms2launcher"
> rcvar=`set_rcvar`
> command="/usr/local/bin/${name} -u kaya"
> ...
> So if I can't add the - does this mean that I have to create a link
> to xmms2-launcher with name xmms2launcher??
no just avoid using ${name} in the command.
name is just a label used for creating unique variable names you can
use in rc.conf, it doesn't have to match any binary.
___
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: rc.d script not working for Xmms2 :-(
Many thanks for the tips I am almost there but have a problem now!
This is the output I get:
./xmms2launcher stop
./xmms2launcher: WARNING: cannot read shebang line from
/usr/local/bin/xmms2launcher
xmms2launcher not running?
From my current file:
rd1# cat xmms2launcher
#!/bin/sh
# PROVIDE:xmms2launcher
. /etc/rc.subr
name="xmms2launcher"
rcvar=`set_rcvar`
command="/usr/local/bin/${name} -u kaya"
load_rc_config $name
run_rc_command "$1"
Of which I know call xmms2launcher_enable="YES" from within /etc/rc.conf
The only issue is that the command is here:
rd1# ls /usr/local/bin | grep xmms2
nyxmms2
xmms2
xmms2-et
xmms2-find-avahi
xmms2-launcher
xmms2-mdns-avahi
xmms2d
So if I can't add the - does this mean that I have to create a link to
xmms2-launcher with name xmms2launcher??
--K
RW wrote:
On Fri, 08 Jan 2010 12:23:40 +0200
Kaya Saman wrote:
So far I have modified the script to look like this:
#!/bin/sh
You may need a PROVIDE LINE e.g.
# PROVIDE:xmms2launcher
. /etc/rc.subr
name="xmms2-launcher"
You can't use "-" in shell variable names, so you shouldn't use it here
rcvar=`set_rcvar`
command="/usr/local/bin/${name}" -u kaya
The -u kaya needs to go in a _flags variable
___
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"
___
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: rc.d script not working for Xmms2 :-(
On Fri, 08 Jan 2010 12:23:40 +0200
Kaya Saman wrote:
> So far I have modified the script to look like this:
>
> #!/bin/sh
You may need a PROVIDE LINE e.g.
# PROVIDE:xmms2launcher
> . /etc/rc.subr
>
> name="xmms2-launcher"
You can't use "-" in shell variable names, so you shouldn't use it here
> rcvar=`set_rcvar`
> command="/usr/local/bin/${name}" -u kaya
The -u kaya needs to go in a _flags variable
___
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"
rc.d script not working for Xmms2 :-(
Hi guys,
I'm just attempting to create a startup script for Xmms2 so that the
service can autostart on boot!
So far I have Google'd around and found very little, the most promising
site was this:
http://www.freebsd.org/doc/en/articles/rc-scripting/rcng-daemon.html
which gives a script of this:
#!/bin/sh
. /etc/rc.subr
name="mumbled"
rcvar=`set_rcvar`
command="/usr/sbin/${name}
load_rc_config $name
run_rc_command "$1"
So far I have modified the script to look like this:
#!/bin/sh
. /etc/rc.subr
name="xmms2-launcher"
rcvar=`set_rcvar`
command="/usr/local/bin/${name}" -u kaya
load_rc_config $name
run_rc_command "$1"
and given it the name xmms2-launcher, the location of the script is in
/usr/local/etc/rc.d/
I also have this line in /etc/rc.conf:
xmms2-launcher_enable="YES"
Only when I attempt to start the script I get this information back:
-u: not found
xmms2-launcher_enable=YES: not found
./xmms2-launcher: WARNING: $xmms2-launcher_enable is not set properly -
see rc.conf(5).
Cannot 'start' xmms2-launcher. Set xmms2-launcher_enable to YES in
/etc/rc.conf or use 'onestart' instead of 'start'.
I would like to start the daemon as user kaya which is why I have the -u
added in the script but am completely lost now as I'm not great at
scripting since this is quite advanced for the simple stuff I do know about!
Can anyone help me??
Many thanks and best regards,
Kaya
___
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: passing options thru '/etc/rc.d/foo start'
On Thursday 17 September 2009 19:55:33 Ruben de Groot wrote: > On Thu, Sep 17, 2009 at 07:14:29PM +0200, Mel Flynn typed: > > On Wednesday 16 September 2009 21:18:03 Tom Worster wrote: > > > On 9/16/09 2:37 PM, "Mel Flynn" > > > > > > wrote: > > > > On Wednesday 16 September 2009 20:21:40 Chris Cowart wrote: > > > >> Tom Worster wrote: > > > >>> thanks, Mel, that's good to know. > > > >>> > > > >>> i think your suggestion of modifying rc.conf will turn out to be a > > > >>> tidy solution for me. > > > >> > > > >> You could also just put: > > > >> > > > >> sshd_flags="-o X11Forwarding=no" > > > >> > > > >> into your /etc/rc.conf file. > > > > > > > > What he wants is passing arguments without touching config files, > > > > which I find myself needing sometimes as well, on machines where > > > > static partitions are mounted read-only + kern.secure_level. > > > > > > that's right. > > > > > > when i read in 11.7 of the handbook: "Since the rc.d system is > > > primarily intended to start/stop services at system startup/shutdown > > > time, ..." i thought: maybe i'm making things hard by trying to use > > > rc.d scripts when i could just execute the daemon's binary. > > > > One downside I forgot to mention: > > You do open yourself up now to SSHD_FLAGS="-o AllowRoot=yes", so you may > > need to complicate the logic a bit more, by sanitizing SSHD_FLAGS. > > Please explain how this can be exploited by a non-root user? By adding this to .profile of compromised wheel account and waiting for him to run sudo -E or using an older version of sudo. Yes, it's an unlikely path. More to the point, it defeats having ro mounted /etc + secure level, since no reboot is required to modify the running sshd, so you're compromising your failsafe. -- Mel ___ 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: passing options thru '/etc/rc.d/foo start'
On Thu, Sep 17, 2009 at 07:14:29PM +0200, Mel Flynn typed: > On Wednesday 16 September 2009 21:18:03 Tom Worster wrote: > > On 9/16/09 2:37 PM, "Mel Flynn" > > > > wrote: > > > On Wednesday 16 September 2009 20:21:40 Chris Cowart wrote: > > >> Tom Worster wrote: > > >>> thanks, Mel, that's good to know. > > >>> > > >>> i think your suggestion of modifying rc.conf will turn out to be a tidy > > >>> solution for me. > > >> > > >> You could also just put: > > >> > > >> sshd_flags="-o X11Forwarding=no" > > >> > > >> into your /etc/rc.conf file. > > > > > > What he wants is passing arguments without touching config files, which I > > > find myself needing sometimes as well, on machines where static > > > partitions are mounted read-only + kern.secure_level. > > > > that's right. > > > > when i read in 11.7 of the handbook: "Since the rc.d system is primarily > > intended to start/stop services at system startup/shutdown time, ..." i > > thought: maybe i'm making things hard by trying to use rc.d scripts when i > > could just execute the daemon's binary. > > One downside I forgot to mention: > You do open yourself up now to SSHD_FLAGS="-o AllowRoot=yes", so you may need > to complicate the logic a bit more, by sanitizing SSHD_FLAGS. Please explain how this can be exploited by a non-root user? Ruben ___ 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: passing options thru '/etc/rc.d/foo start'
On Wednesday 16 September 2009 21:18:03 Tom Worster wrote: > On 9/16/09 2:37 PM, "Mel Flynn" > > wrote: > > On Wednesday 16 September 2009 20:21:40 Chris Cowart wrote: > >> Tom Worster wrote: > >>> thanks, Mel, that's good to know. > >>> > >>> i think your suggestion of modifying rc.conf will turn out to be a tidy > >>> solution for me. > >> > >> You could also just put: > >> > >> sshd_flags="-o X11Forwarding=no" > >> > >> into your /etc/rc.conf file. > > > > What he wants is passing arguments without touching config files, which I > > find myself needing sometimes as well, on machines where static > > partitions are mounted read-only + kern.secure_level. > > that's right. > > when i read in 11.7 of the handbook: "Since the rc.d system is primarily > intended to start/stop services at system startup/shutdown time, ..." i > thought: maybe i'm making things hard by trying to use rc.d scripts when i > could just execute the daemon's binary. One downside I forgot to mention: You do open yourself up now to SSHD_FLAGS="-o AllowRoot=yes", so you may need to complicate the logic a bit more, by sanitizing SSHD_FLAGS. -- Mel ___ 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: passing options thru '/etc/rc.d/foo start'
Tom Worster wrote: > On 9/16/09 3:19 PM, "Matthew Seaman" > wrote: > >> Tom Worster wrote: >>> is there a general shell syntax that can be used to pass arguments to a >>> daemon that you're starting with the /etc/rc.d/foo start command? >> If you're starting service foo, then you should be able to define command >> arguments by setting foo_flags="-a -b -c". This is a convention, and >> particular >> services may use several more specific variables to build a command line >> or may simply ignore any flags variable completely, so you'll have to check >> each case individually. >> >>> for example, how does one start sshd using /etc/rc.d/sshd and pass it >>> '-o X11Forwarding=no' without touching a config file? >> In this case, setting sshd_flags will work as sshd uses the default rc >> start function. > > hi matthew, > > i tried this and couldn't make it work before i emailed my question. then > mel answered that the /etc/rc.d/foo scripts ignore environment. and then, > looking closer at man pages, i got the impression that perhaps only /etc/rc > uses the foo_flags variables when it invokes /etc/rc.d/foo scripts. Uh, yeah. My tortured mental processes had somehow concluded that /etc/rc.conf *wasn't* a config file and then I pretty much forgot to add 'in /etc/rc.conf' at the crucial point in what I wrote. I don't think your request is possible without editing at least one file under /etc Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. Flat 3 7 Priory Courtyard PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW, UK signature.asc Description: OpenPGP digital signature
Re: passing options thru '/etc/rc.d/foo start'
On 9/16/09 3:19 PM, "Matthew Seaman" wrote: > Tom Worster wrote: >> is there a general shell syntax that can be used to pass arguments to a >> daemon that you're starting with the /etc/rc.d/foo start command? > > If you're starting service foo, then you should be able to define command > arguments by setting foo_flags="-a -b -c". This is a convention, and > particular > services may use several more specific variables to build a command line > or may simply ignore any flags variable completely, so you'll have to check > each case individually. > >> for example, how does one start sshd using /etc/rc.d/sshd and pass it >> '-o X11Forwarding=no' without touching a config file? > > In this case, setting sshd_flags will work as sshd uses the default rc > start function. hi matthew, i tried this and couldn't make it work before i emailed my question. then mel answered that the /etc/rc.d/foo scripts ignore environment. and then, looking closer at man pages, i got the impression that perhaps only /etc/rc uses the foo_flags variables when it invokes /etc/rc.d/foo scripts. tom ___ 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: passing options thru '/etc/rc.d/foo start'
Tom Worster wrote: is there a general shell syntax that can be used to pass arguments to a daemon that you're starting with the /etc/rc.d/foo start command? If you're starting service foo, then you should be able to define command arguments by setting foo_flags="-a -b -c". This is a convention, and particular services may use several more specific variables to build a command line or may simply ignore any flags variable completely, so you'll have to check each case individually. for example, how does one start sshd using /etc/rc.d/sshd and pass it '-o X11Forwarding=no' without touching a config file? In this case, setting sshd_flags will work as sshd uses the default rc start function. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: passing options thru '/etc/rc.d/foo start'
On 9/16/09 2:37 PM, "Mel Flynn" wrote: > On Wednesday 16 September 2009 20:21:40 Chris Cowart wrote: >> Tom Worster wrote: >>> thanks, Mel, that's good to know. >>> >>> i think your suggestion of modifying rc.conf will turn out to be a tidy >>> solution for me. >> >> You could also just put: >> >> sshd_flags="-o X11Forwarding=no" >> >> into your /etc/rc.conf file. > > What he wants is passing arguments without touching config files, which I find > myself needing sometimes as well, on machines where static partitions are > mounted read-only + kern.secure_level. that's right. when i read in 11.7 of the handbook: "Since the rc.d system is primarily intended to start/stop services at system startup/shutdown time, ..." i thought: maybe i'm making things hard by trying to use rc.d scripts when i could just execute the daemon's binary. an advantage i imagined of using rc.d is it starts the service with the same config as at boot so i don't have to remember any config items that might not be in the daemons config files. maybe all config _should_ be in the daemon's config files but then i _might_ have been both lazy and forgetful. ___ 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: passing options thru '/etc/rc.d/foo start'
On Wednesday 16 September 2009 20:21:40 Chris Cowart wrote: > Tom Worster wrote: > > thanks, Mel, that's good to know. > > > > i think your suggestion of modifying rc.conf will turn out to be a tidy > > solution for me. > > You could also just put: > > sshd_flags="-o X11Forwarding=no" > > into your /etc/rc.conf file. What he wants is passing arguments without touching config files, which I find myself needing sometimes as well, on machines where static partitions are mounted read-only + kern.secure_level. -- Mel ___ 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: passing options thru '/etc/rc.d/foo start'
Tom Worster wrote: > thanks, Mel, that's good to know. > > i think your suggestion of modifying rc.conf will turn out to be a tidy > solution for me. You could also just put: sshd_flags="-o X11Forwarding=no" into your /etc/rc.conf file. Pretty much all of the rc.d scripts support the use of NAME_flags being defined in /etc/rc.conf, which are passed as extra commandline arguments to the daemon. You should generally check /etc/defaults/rc.conf to see what you might be clobbering. A small number of scripts may override this feature from the library, breaking this method, but it's pretty widely supported. -- Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley pgpdLHTVAM3EC.pgp Description: PGP signature
Re: passing options thru '/etc/rc.d/foo start'
On 9/16/09 1:35 PM, "Mel Flynn"
wrote:
> On Wednesday 16 September 2009 18:45:29 Tom Worster wrote:
>> is there a general shell syntax that can be used to pass arguments to a
>> daemon that you're starting with the /etc/rc.d/foo start command?
>>
>> for example, how does one start sshd using /etc/rc.d/sshd and pass it
>> '-o X11Forwarding=no' without touching a config file?
>
> You don't. Defaults are set in /etc/defaults/rc.conf, overridden in
> /etc/rc.conf. Unless you add the logic yourself in /etc/rc.conf, the
> environment is not looked at.
> So this means a one-time edit of /etc/rc.conf:
> if test -n "${SSHD_FLAGS}"; then
> sshd_flags="${SSHD_FLAGS}"
> else
> sshd_flags="${sshd_flags}"
> fi
>
> Then start with SSHD_FLAGS="-o X11Forwarding=no" /etc/rc.d/sshd start
>
> But this is specific for sshd, as it supports _flags. There's no generic way
> to do this.
thanks, Mel, that's good to know.
i think your suggestion of modifying rc.conf will turn out to be a tidy
solution for me.
tom
___
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: passing options thru '/etc/rc.d/foo start'
On Wednesday 16 September 2009 18:45:29 Tom Worster wrote:
> is there a general shell syntax that can be used to pass arguments to a
> daemon that you're starting with the /etc/rc.d/foo start command?
>
> for example, how does one start sshd using /etc/rc.d/sshd and pass it
> '-o X11Forwarding=no' without touching a config file?
You don't. Defaults are set in /etc/defaults/rc.conf, overridden in
/etc/rc.conf. Unless you add the logic yourself in /etc/rc.conf, the
environment is not looked at.
So this means a one-time edit of /etc/rc.conf:
if test -n "${SSHD_FLAGS}"; then
sshd_flags="${SSHD_FLAGS}"
else
sshd_flags="${sshd_flags}"
fi
Then start with SSHD_FLAGS="-o X11Forwarding=no" /etc/rc.d/sshd start
But this is specific for sshd, as it supports _flags. There's no generic way
to do this.
--
Mel
___
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"
passing options thru '/etc/rc.d/foo start'
is there a general shell syntax that can be used to pass arguments to a daemon that you're starting with the /etc/rc.d/foo start command? for example, how does one start sshd using /etc/rc.d/sshd and pass it '-o X11Forwarding=no' without touching a config file? tom ___ 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: /etc/rc.d/named dilemma
Nerius Landys wrote: > I am still bambuzzled by the network taking 30 seconds to come up. One thing I've run into recently is an Ethernet switch that needs to resolve spanning tree after a port reset. The physical link comes back up quickly, but it seems to take about 30 seconds before the switch will handle any traffic. ___ 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: /etc/rc.d/named dilemma
On Saturday 22 August 2009 21:11:01 Nerius Landys wrote: > > I don't remember the original description, but any time I hear > > about a 30 second "gap" during startup, I think of the well-known DNS > > reverse look-up issue. Are you sure this is not the case here? > > Indeed, I have forgotten to have the PTR record set up for my new IP > address. > > However the original description is that when I issue a "ping -c 100 > x.y.z.w" to a well-known IP address, only the last 70 packets get > returned, not the first 30 (hence 30 seconds). This ping command is > issued very early in the rc.d scripts, after NETWORK and before named, > and the script does not exit until a ping request is successful. > ___ > 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" Nerius; I had the same problem until I put: # REQUIRE: SERVERS cleanvar ppp-user in /etc/rc.d/named script, which means that named won't start until the ppp -ddial adsl command, which is called by in /etc/rc.d/ppp-user, is finished. By then, DNS and default route will be established. I also put: # PROVIDE: ppp-user in /etc/rc.d/ppp-user. Sorry for writing you directly but I don't know why, the freebsd-questions list (in fact, all freebsd lists i'm subscribed to) is refusing my posts. Not even the list manager/owner gets them. If you would be so kind to forward this to them, I'd be very greatful. Maybe they could find out why so I could take action to try remedy what is causing the refusals of my e-mail. Thanks and Best wishes, -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since version 2.2.8 [not Pro-Audio YET!!] (99,7% winedows FREE) ___ 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: /etc/rc.d/named dilemma
> I don't remember the original description, but any time I hear about > a 30 second "gap" during startup, I think of the well-known DNS reverse > look-up issue. Are you sure this is not the case here? Indeed, I have forgotten to have the PTR record set up for my new IP address. However the original description is that when I issue a "ping -c 100 x.y.z.w" to a well-known IP address, only the last 70 packets get returned, not the first 30 (hence 30 seconds). This ping command is issued very early in the rc.d scripts, after NETWORK and before named, and the script does not exit until a ping request is successful. ___ 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: /etc/rc.d/named dilemma
Nerius Landys wrote: I am still bambuzzled by the network taking 30 seconds to come up. I don't remember the original description, but any time I hear about a 30 second "gap" during startup, I think of the well-known DNS reverse look-up issue. Are you sure this is not the case here? Robert Huff ___ 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: /etc/rc.d/named dilemma
> calcru: runtime went backwards from 37332 usec to 16577 > usec for pid 47 (sh)... Not to seem like I'm talking to myself, but I fixed this problem: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#CALCRU-NEGATIVE-RUNTIME (Turn off Intel® Enhanced SpeedStep.) I am still bambuzzled by the network taking 30 seconds to come up. ___ 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: /etc/rc.d/named dilemma
One last question. I'm getting interesting [kernel?] messages during bootup. You know, the kind that are highlighted white in the console. The relevant lines of rc.conf look like this right now: defaultrouter="64.156.192.1" hostname="daffy.nerius.com" ifconfig_em0="inet 64.156.192.169 netmask 255.255.255.0" waitfornetwork_enable="YES" named_enable="YES" sshd_enable="YES" #ntpdate_enable="YES" ntpd_enable="YES" linux_enable="YES" apache22_enable="YES" mysql_enable="YES" Early on in the bootup, the ifconfig shows for em0: inet 64.156.192.169 ... media: Ethernet autoselect status: no carrier Then later on: Waiting for network to initialize. em0: link state changed to UP calcru: runtime went backwards from 37332 usec to 16577 usec for pid 47 (sh)... ... (more messages about calcru) And then everything starts fine, including ntpd. Why is em0 only brought up when I do my ping command in /etc/rc.d/waitfornetwork? And are these calcru messages something to be worried about? ___ 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: /etc/rc.d/named dilemma
Thanks for the script. I found the underlying problem on my system.
My server is at a data center and I don't know what kind of equipment
the server is connected to. It appears that it takes 30 seconds for
the networking to start. I added this script as
/etc/rc.d/waitfornetwork, and enabled it in rc.conf:
===
#!/bin/sh
# PROVIDE: waitfornetwork
# REQUIRE: NETWORKING
# BEFORE: named
. /etc/rc.subr
: ${waitfornetwork_enable:=NO}
name=waitfornetwork
rcvar=`set_rcvar`
stop_cmd=":"
start_cmd="waitfornetwork_start"
waitfornetwork_start()
{
echo "Waiting for network to initialize."
for i in 0 1 2 3 4 5 6 7 8 9; do
#echo "Iteration $i"
if ping -c 1 198.41.0.4 | grep -q '^1 packets transmitted, 1
packets received, 0.0% packet loss'; then
break
fi
done
}
load_rc_config ${name}
run_rc_command "$1"
===
It goes through 4 or 5 iterations (the "for" loop) before it exits.
This takes about 30 seconds. Without this startup script, ntpdate and
ntpd fail, regardless of whether or not I use named as my local DNS
caching server. With this script enabled, ntpdate and ntpd are able
to resolve the listed DNS for the time servers, regardless of whether
I'm using 127.0.0.1 or some other DNS in my resolv.conf.
This 30 second delay for the network to start on every reboot (at the
data center) - is this normal?
___
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: /etc/rc.d/named dilemma
On Fri, 21 Aug 2009 21:37:09 -0700
Nerius Landys wrote:
> Then why
> can't I do a lookup right after named starts?
Possibly it's a delay in bind being ready or maybe you don't have any
network access - the latter is common with ppp.
> By the way, the underlying issue that I'm trying to address is that
> ntpdate, which comes right after named in the boot sequence, is not
> able to resolve the DNS for the time servers.
Try putting the following in /usr/local/etc/rc.d/waitfordns and make it
executable (untested)
#!/bin/sh
#
# PROVIDE: waitfordns
# REQUIRE: named
# BEFORE: ntpdate
. /etc/rc.subr
: ${waitfordns_enable:=yes}
name=waitfordns
rcvar=`set_rcvar`
stop_cmd=":"
start_cmd="waitfordns_start"
waitfordns_start(){
/usr/bin/dig +time=1 +retry=99 @127.0.0.1 google.com 2>&1 > /dev/null
}
load_rc_config ${name}
run_rc_command "$1"
___
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"
