When trying to do a clean/new install of mariadb, I first install
mariadb-server (which installs cleanly), and try to install mariadb-scripts
which fails with:
# make install
=== Installing for mariadb-scripts-5.3.12
=== mariadb-scripts-5.3.12 depends on file: /usr/local/bin/perl5.16.2 -
found
I have a FreeBSD ZFS file server with tens of millions of files stored on it.
But, the daily periodic scripts like
/etc/periodic/security/110.neggrpperm and
/etc/periodic/weekly/310.locate take hours iterating through those
folders, and I just don't need them to be scanned.
I see that I can edit
On Wed, 6 Feb 2013 09:26:17 -0800, Tim Gustafson wrote:
I have a FreeBSD ZFS file server with tens of millions of files stored on it.
But, the daily periodic scripts like
/etc/periodic/security/110.neggrpperm and
/etc/periodic/weekly/310.locate take hours iterating through those
folders
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/6/13 12:26 PM, Tim Gustafson wrote:
I have a FreeBSD ZFS file server with tens of millions of files
stored on it.
But, the daily periodic scripts like
/etc/periodic/security/110.neggrpperm and
/etc/periodic/weekly/310.locate take hours
I have a FreeBSD ZFS file server with tens of millions of files
stored on it.
But, the daily periodic scripts like
/etc/periodic/security/110.neggrpperm and
/etc/periodic/weekly/310.locate take hours iterating through those
folders, and I just don't need them to be scanned.
I see that I
I am making a mfs boot disk to send along with a server
we are dispatching to a remote campus.
I am using the scripts from Martin Matuska's
mfsbsd-1.0-beta3
suite of programs and they produce a great bootable CD but I
need /usr/local/etc/eject.allow present to let us remotely
Hi all.
It seems that patches to periodic scripts have hard time coming into the
tree. I personally filed
http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/165817 and still there's
no move despite change is purely cosmetical and just fixes right way of
things.
And this is not just one
On Wed, 25 Jan 2012 16:08:07 -0600
Doug Poland articulated:
Hello,
I'm trying port some shell scripts to FreeBSD that were originally
written on Darwin (OS X).
The issue I'm having is the shebang line of the scripts in OS X is
#!/bin/sh, and it turns out that is really an instance
On 01/26/12 08:08, Doug Poland wrote:
Hello,
I'm trying port some shell scripts to FreeBSD that were originally
written on Darwin (OS X).
The issue I'm having is the shebang line of the scripts in OS X is
#!/bin/sh, and it turns out that is really an instance of bash, and
the code contains
On Jan 25, 2012, at 2:08 PM, Doug Poland wrote:
The issue I'm having is the shebang line of the scripts in OS X is
#!/bin/sh, and it turns out that is really an instance of bash, and
the code contains some bashisms. On FreeBSD I have bash in
/usr/local/bin/bash.
Is there an easy/best way
On Wed, 25 Jan 2012, Doug Poland wrote:
I'm trying port some shell scripts to FreeBSD that were originally
written on Darwin (OS X).
The issue I'm having is the shebang line of the scripts in OS X is
#!/bin/sh, and it turns out that is really an instance of bash, and
the code contains some
On Jan 25, 2012, at 18:04 , Chuck Swiger wrote:
On Jan 25, 2012, at 2:08 PM, Doug Poland wrote:
The issue I'm having is the shebang line of the scripts in OS X is
#!/bin/sh, and it turns out that is really an instance of bash, and
the code contains some bashisms. On FreeBSD I have bash
On 01/26/12 12:55, Doug Poland wrote:
On Jan 25, 2012, at 18:04 , Chuck Swiger wrote:
On Jan 25, 2012, at 2:08 PM, Doug Poland wrote:
The issue I'm having is the shebang line of the scripts in OS X is
#!/bin/sh, and it turns out that is really an instance of bash, and
the code contains some
Hi--
On Jan 25, 2012, at 7:24 PM, Da Rock wrote:
On 01/26/12 12:55, Doug Poland wrote:
This gets me closer, but the scripts behave differently now on OS X. For
example, printf's don't output the same.
Try searching on google and find out exactly what sh MacOSX is using. Then
you'd have
On Jan 25, 2012, at 5:08 PM, Doug Poland wrote:
Hello,
I'm trying port some shell scripts to FreeBSD that were originally
written on Darwin (OS X).
The issue I'm having is the shebang line of the scripts in OS X is
#!/bin/sh, and it turns out that is really an instance of bash
On Jan 25, 2012, at 8:13 PM, Chuck Swiger wrote:
Hi--
On Jan 25, 2012, at 7:24 PM, Da Rock wrote:
On 01/26/12 12:55, Doug Poland wrote:
This gets me closer, but the scripts behave differently now on OS X. For
example, printf's don't output the same.
Try searching on google and find
On Wed, 25 Jan 2012 16:08:07 -0600,
Doug Poland d...@polands.org said:
D I'm trying port some shell scripts to FreeBSD that were originally
D written on Darwin (OS X). The issue I'm having is the shebang line of
D the scripts in OS X is #!/bin/sh, and it turns out that is really an
D instance
) run daemons or scripts when backup server come into the
work? As I know ucarp and heartbeat can do this.
No, carp only works at the interface level. In ports you will find
ifstated(8) (from OpenBSD). It can react to a change on an
interface and run tests.
Also may be with devd, but imo
Can carp(4) run daemons or scripts when backup server come into the work?
As I know ucarp and heartbeat can do this.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail
Le Tue, 23 Aug 2011 17:50:43 +0400,
Pavel Timofeev tim...@gmail.com a écrit :
Hello,
Can carp(4) run daemons or scripts when backup server come into the
work? As I know ucarp and heartbeat can do this.
No, carp only works at the interface level. In ports you will find
ifstated(8) (from
Oh, thank you very much!
I didn't know about ifstated. I'll try it.
Also may be with devd
How? What do you mean?
2011/8/23 Patrick Lamaiziere patf...@davenulle.org
Le Tue, 23 Aug 2011 17:50:43 +0400,
Pavel Timofeev tim...@gmail.com a écrit :
Hello,
Can carp(4) run daemons or scripts
or scripts when backup server come into the
work? As I know ucarp and heartbeat can do this.
No, carp only works at the interface level. In ports you will find
ifstated(8) (from OpenBSD). It can react to a change on an
interface and run tests.
Also may be with devd, but imo ifstated will do
daemons or scripts when backup server come into the
work? As I know ucarp and heartbeat can do this.
No, carp only works at the interface level. In ports you will find
ifstated(8) (from OpenBSD). It can react to a change on an
interface and run tests.
Also may be with devd, but imo
On Wed, 11 May 2011 11:59:48 +0200 Jonathan McKeown j.mcke...@ru.ac.za
wrote:
On Wednesday 11 May 2011 04:19:29 Devin Teske wrote:
The reason that the suid bit doesn't work on scripts (shell, perl, or
otherwise) is because these are essentially text files that are interpreted
On 05/13/2011 14:34, Alejandro Imass wrote:
On Fri, May 13, 2011 at 6:07 AM, Chris Telting
christopher...@telting.org wrote:
On 05/13/2011 01:32, krad wrote:
[...]
me ask you.. is sudo ping acceptable? Please explain the logical reason
why not. It would be the preferred method if suid didn't
Chris == Chris Telting christopher...@telting.org writes:
Chris I honestly tried when I posted the question to avoid the question
Chris of right or wrong. I simply have one opinion for my own need and
Chris preference and don't want to go into rigid detail and did not
Chris mean to reopen the
On 15 May 2011 15:30, Randal L. Schwartz mer...@stonehenge.com wrote:
Chris == Chris Telting christopher...@telting.org writes:
Chris I honestly tried when I posted the question to avoid the question
Chris of right or wrong. I simply have one opinion for my own need and
Chris preference and
Chris Telting christopher...@telting.org wrote:
let me ask you.. is sudo ping acceptable? Please explain the
logical reason why not. It would be the preferred method if suid
didn't exist and sudo was part of the base system.
Without suid there would be no sudo ;)
Part of the reason for ping
Pan == Pan Tsu iny...@gmail.com writes:
Pan ...a shebang can be written with sudo in mind, e.g.
Pan #! /usr/bin/env -S sudo sh
Pan id
(Untested) why not just #!/usr/local/bin/sudo ? It'll be given the
filename as an argument.
Aside: In general, almost every use of #!/usr/bin/env XXX as a
versus sudo for scripts?
I second the sudo idea instead of suiding the interpreter, and it's a
better solution to the one I have used in the past like C-wrapping and
suiding specific operations.
___
freebsd-questions@freebsd.org mailing list
http
On Thursday 12 May 2011 17:26:49 Chris Telting wrote:
On 05/12/2011 07:57, Jonathan McKeown wrote:
I'll say that again. It is inherently insecure to run an interpreted
program set-uid, because the filename is opened twice and there's no
guarantee that someone hasn't changed the contents
On 13 May 2011 08:32, Jonathan McKeown j.mcke...@ru.ac.za wrote:
On Thursday 12 May 2011 17:26:49 Chris Telting wrote:
On 05/12/2011 07:57, Jonathan McKeown wrote:
I'll say that again. It is inherently insecure to run an interpreted
program set-uid, because the filename is opened
On 05/13/2011 00:32, Jonathan McKeown wrote:
On Thursday 12 May 2011 17:26:49 Chris Telting wrote:
On 05/12/2011 07:57, Jonathan McKeown wrote:
I'll say that again. It is inherently insecure to run an interpreted
program set-uid, because the filename is opened twice and there's no
guarantee
On 05/13/2011 01:32, krad wrote:
what i cant understand is the complete aversion to sudo. Could you
shed any light on why you are trying to avoid a tried and tested method.
That I freely admit is for no rational reason. It's just annoying. But
let me ask you.. is sudo ping acceptable? Please
On 13 May 2011 11:07, Chris Telting christopher...@telting.org wrote:
On 05/13/2011 01:32, krad wrote:
what i cant understand is the complete aversion to sudo. Could you shed
any light on why you are trying to avoid a tried and tested method.
That I freely admit is for no rational reason.
Chris Telting christopher...@telting.org writes:
On 05/13/2011 01:32, krad wrote:
what i cant understand is the complete aversion to sudo. Could you
shed any light on why you are trying to avoid a tried and tested
method.
That I freely admit is for no rational reason. It's just annoying.
C
On Friday, 13 May 2011, Pan Tsu iny...@gmail.com wrote:
Chris Telting christopher...@telting.org writes:
On 05/13/2011 01:32, krad wrote:
what i cant understand is the complete aversion to sudo. Could you
shed any light on why you are trying to avoid a tried and tested
method.
That I
are using suid it it should work; I don't want to use a
kludge and I don't want to use sudo. I'm hoping it's a setting that is
just disabled by default.
My understanding is that in general the system does not allow SUID
on scripts. The way I have gotten around that (a long time ago)
was to create
on scripts. The way I have gotten around that (a long time ago)
was to create a small binary that exec's the script and making
the binary SUID.
Well it's all hacks and in my not so humble option like chasing your
tail. The assumption is that if someone creates an executable
(assumption
. Suid in and of itself is a security issue.
But if you are using suid it it should work; I don't want to use a
kludge and I don't want to use sudo. I'm hoping it's a setting that is
just disabled by default.
My understanding is that in general the system does not allow SUID
on scripts
does not allow SUID
on scripts. The way I have gotten around that (a long time ago)
was to create a small binary that exec's the script and making
the binary SUID.
Well it's all hacks and in my not so humble option like chasing your
tail. The assumption is that if someone creates an executable
Chris Telting christopher...@telting.org wrote:
Seemed like I read that historically unix ran the #! command
as the suid when it executed the file. Did Freebsd delete
that functionality? (Otherwise how did suid scripts get the
bad reputation if they could never execute suid.)
There have
Here is some information on what perl does:
http://www.washington.edu/perl5man/pod/perlsec.html
Also there is an option (not chosen by default) in the perl port to
enable setuid.
Riaan
___
freebsd-questions@freebsd.org mailing list
On Wednesday 11 May 2011 04:19:29 Devin Teske wrote:
The reason that the suid bit doesn't work on scripts (shell, perl, or
otherwise) is because these are essentially text files that are interpreted
by their associated interpreter. It is the interpreter itself that must be
suid.
I'm pretty
want to use a
kludge and I don't want to use sudo. I'm hoping it's a setting that is
just disabled by default.
My understanding is that in general the system does not allow SUID
on scripts. The way I have gotten around that (a long time ago)
was to create a small binary that exec's the script
On Wed, May 11, 2011 at 10:14 AM, Jerry McAllister jerr...@msu.edu wrote:
On Tue, May 10, 2011 at 05:54:04PM -0700, Chris Telting wrote:
I've googled for over an hour.
As other have said suiding on scripts is not allowed in modern
versions of Unix. What I do for example, is create small C
on scripts is not allowed in modern
versions of Unix. What I do for example, is create small C programs
suid them and use those special suid execs to do special stuff. For
example, if I need to erase some files created by the mysql daemon
process I will create a C exec called suidrm and have it suid
I've googled for over an hour.
I'm not looking to get into a discussion on security or previous bugs
that are currently fixed. Suid in and of itself is a security issue.
But if you are using suid it it should work; I don't want to use a
kludge and I don't want to use sudo. I'm hoping it's
On Tue, 10 May 2011 21:43:43 -0400, Daniel Staal dst...@usa.net wrote:
One thought: What's the output of 'mount' for the slice you are trying to
run this script from? (Suid can be blocked on a per-mountpoint basis.)
Just for terminology: You mount a partition, _not_ a slice,
so mount operates
--As of May 11, 2011 3:55:03 AM +0200, Polytropon is alleged to have said:
On Tue, 10 May 2011 21:43:43 -0400, Daniel Staal dst...@usa.net wrote:
One thought: What's the output of 'mount' for the slice you are trying
to run this script from? (Suid can be blocked on a per-mountpoint
basis.)
a kludge and I don't
want to use sudo. I'm hoping it's a setting that is just disabled by default.
The reason that the suid bit doesn't work on scripts (shell, perl, or
otherwise) is because these are essentially text files that are interpreted by
their associated interpreter
it it should work; I don't want to use a kludge and I don't want to
use sudo. I'm hoping it's a setting that is just disabled by default.
The reason that the suid bit doesn't work on scripts (shell, perl, or
otherwise) is because these are essentially text files that are interpreted
to that script would be done by either setting the
login-shell to that script, setting the ssh-command for that account/key (and
ensuring that it can't be altered), or both.
All in all, this is a more general question I have for quite a time: Can you
use shell-scripts for security-relevant
...@freebsd.org owner-freebsd-questi...@freebsd.org
To: freebsd-questions@freebsd.org freebsd-questions@freebsd.org
Sent: Thu Nov 18 07:52:39 2010
Subject: Escaping from shell-scripts
Hi,
I'm planning a service with a login-user-interface. Thus, I want to restrict
the user somehow to this script
-prompt?
The restriction to that script would be done by either setting the
login-shell to that script, setting the ssh-command for that account/key (and
ensuring that it can't be altered), or both.
All in all, this is a more general question I have for quite a time: Can you
use shell-scripts
shell-scripts for security-relevant environments? Does an attacker have
the possibility to escape from a script down to a prompt?
I'm not that into shell-programming and there are too many legacies about
terminals (some time ago, I had to cope with termcap...) and shells which one
just can't all
general question I have for quite a time: Can
you
use shell-scripts for security-relevant environments? Does an attacker have
the possibility to escape from a script down to a prompt?
I'm not that into shell-programming and there are too many legacies about
terminals (some time ago, I had
doug d...@fledge.watson.org writes:
If you make a program a shell AFAIK to escape is to logff. Bash has a
chroot like facility that might work. However if you write a simple C
program as a wrapper for your shell script and make that program a
shell, I would think that is pretty secure.
As
-scripts for security-relevant environments?
Yes, but you really shouldn't trust them any farther than you would trust a
user with an interactive shell. It's just too easy to exploit $IFS, invoke
command line utilities that provide shell escapes, etc.
Python or C is likely to be more securable
Hi,
I know this isn't the ideal, place but im not having much joy on the
net-snmp users mailing list.
Does anyone have any good guides for writing or examples of snmp pass
scripts?
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org
Hi:
I have a setup with diskless clients mounting /var/diskless/FreeBSD
read-only as root file system.
How do I configure cron/locate.rc to run on the server such that the
locate database is relative to the root for the diskless systems?
I could do a chroot and run it within this
Good morning all,
I have been working on an issue here where I am being asked if we can
support letting clients install and run their own CGI scripts on a
shared vhost. I have tried sbox and cgiwrap, both which worked, but they
cannot stop the one test of reading the /etc/passwd file.
Forgive my
DAve wrote:
Good morning all,
I have been working on an issue here where I am being asked if we can
support letting clients install and run their own CGI scripts on a
shared vhost. I have tried sbox and cgiwrap, both which worked, but they
cannot stop the one test of reading the /etc/passwd
Matthew Seaman wrote:
DAve wrote:
Good morning all,
I have been working on an issue here where I am being asked if we can
support letting clients install and run their own CGI scripts on a
shared vhost. I have tried sbox and cgiwrap, both which worked, but they
cannot stop the one test
, Jan 22, 2010 at 12:57 PM, DAve dave.l...@pixelhammer.com wrote:
Matthew Seaman wrote:
DAve wrote:
Good morning all,
I have been working on an issue here where I am being asked if we can
support letting clients install and run their own CGI scripts on a
shared vhost. I have tried sbox
Nathan Vidican wrote:
Check out suExec, (assuming you're using Apache)...
Please see: http://httpd.apache.org/docs/1.3/mod/core.html#user and/or
http://httpd.apache.org/docs/1.3/suexec.html
You can make an entire VirtualHost directive run as a different user/group.
A more up to date
If you want to keep an eye on some hosts without doing a full Nagios install:
http://www.hcst.net/~vogelke/src/ishostup/
--
Karl Vogel I don't speak for the USAF or my company
If you can't be kind, at least have the decency to be vague.--unknown
Karl,
On Fri, Jun 12, 2009 at 3:07 PM, Karl Vogelvogelke+u...@pobox.com wrote:
If you want to keep an eye on some hosts without doing a full Nagios install:
http://www.hcst.net/~vogelke/src/ishostup/
Very cool. I'll take a look at it later, as I am going to be setting
up a Nagios solution
Chuck Swiger wrote:
On Mar 17, 2009, at 5:09 PM, Steve Bertrand wrote:
Although SMTP is denied, I just realized that there are numerous
messages from periodic scripts that are queued up that can't be sent.
Can someone advise how to find out each and every periodic script that
tries to send out
Matthew Seaman wrote:
Chuck Swiger wrote:
On Mar 17, 2009, at 5:09 PM, Steve Bertrand wrote:
Although SMTP is denied, I just realized that there are numerous
messages from periodic scripts that are queued up that can't be sent.
Can someone advise how to find out each and every periodic
Hi everyone,
Taking the questions regarding my routing boxes one step further, I have
strict rules that allow only certain control and management protocols to
communicate on the network.
Although SMTP is denied, I just realized that there are numerous
messages from periodic scripts
realized that there are numerous
messages from periodic scripts that are queued up that can't be sent.
Can someone advise how to find out each and every periodic script that
tries to send out email (given a standard install), and/or how to
disable this?
Or, is there a way to completely
On Mar 17, 2009, at 5:09 PM, Steve Bertrand wrote:
Although SMTP is denied, I just realized that there are numerous
messages from periodic scripts that are queued up that can't be sent.
Can someone advise how to find out each and every periodic script that
tries to send out email (given
On Sun, Mar 01, 2009 at 07:14:17PM -0800, gahn wrote:
Hi all:
I have some starting scripts under some other directories other
than /etc/rc.d. How could I utilize the rc.conf file to start them
when the system boots up?
The default location for rc.conf is /etc/rc.d only and the
knob
Hi all:
I have some starting scripts under some other directories other than /etc/rc.d.
How could I utilize the rc.conf file to start them when the system boots up?
The default location for rc.conf is /etc/rc.d only and the knob
local_startup=/usr/local/etc/rc.d doesn't seem to be working
gahn writes:
The default location for rc.conf is /etc/rc.d only and the knob
local_startup=/usr/local/etc/rc.d doesn't seem to be working
for me for some reasons
Your best bet is to figure out why the latter is true, and fix
it.
Robert Huff
Hi,
The default location for rc.conf is /etc/rc.d only and the knob
local_startup=/usr/local/etc/rc.d doesn't seem to be working for
me for some reasons
Syntax? on my machines it's:
local_startup=/usr/local/etc/rc.d
with quotes around the path, not around the full line.
Olivier
On Sun, 1 Mar 2009 19:14:17 -0800 (PST)
gahn ipfr...@yahoo.com wrote:
Hi all:
I have some starting scripts under some other directories other
than /etc/rc.d. How could I utilize the rc.conf file to start them
when the system boots up?
The default location for rc.conf is /etc/rc.d only
Allow me an addition:
On Mon, 2 Mar 2009 03:53:24 +, RW rwmailli...@googlemail.com wrote:
/usr/local/etc/rc.d is the default for local scripts, that's where
package put their scripts, but there are some rules.
- they should either be proper RCNG scripts or they should end in a .sh
SCRIPTS
Ok...
the scripts are at:
http://dist.k1.com.br/scripts/baselist_amd64
http://dist.k1.com.br/scripts/baselist_i386
http://dist.k1.com.br/scripts/makebootdisk
http://dist.k1.com.br/scripts/zfsetup
install these scripts on /root
makebootdisk:
formats the disk (or usb stick
Message -
From: regis505 regis...@gmail.com
To: freebsd-questions@freebsd.org
Sent: Thursday, February 26, 2009 7:41:58 AM GMT -08:00 US/Canada Pacific
Subject: Re: USB INSTALL SCRIPTS
Just want to say that it does the same to me. The script works great but it
stops at the same place
: USB INSTALL SCRIPTS
Ok...
the scripts are at:
http://dist.k1.com.br/scripts/baselist_amd64
http://dist.k1.com.br/scripts/baselist_i386
http://dist.k1.com.br/scripts/makebootdisk
http://dist.k1.com.br/scripts/zfsetup
install these scripts on /root
makebootdisk:
formats the disk (or usb
Ok...
the scripts are at:
http://dist.k1.com.br/scripts/baselist_amd64
http://dist.k1.com.br/scripts/baselist_i386
http://dist.k1.com.br/scripts/makebootdisk
http://dist.k1.com.br/scripts/zfsetup
install these scripts on /root
makebootdisk:
formats the disk (or usb stick) at da0,da1...) make
Ok...
the scripts are at:
http://dist.k1.com.br/scripts/baselist_amd64
http://dist.k1.com.br/scripts/baselist_i386
http://dist.k1.com.br/scripts/makebootdisk
http://dist.k1.com.br/scripts/zfsetup
install these scripts on /root
makebootdisk:
formats the disk (or usb stick) at da0,da1...) make
On Thursday 02 October 2008 01:59:18 Da Rock wrote:
On Wed, 2008-10-01 at 12:53 +0200, Erik Trulsson wrote:
On Wed, Oct 01, 2008 at 08:39:47PM +1000, Da Rock wrote:
So are you saying I can't start a script manually without enabling it
in rc.conf? I was not under that impression... I
On Thu, 2008-10-02 at 09:18 +0200, Jonathan McKeown wrote:
On Thursday 02 October 2008 01:59:18 Da Rock wrote:
On Wed, 2008-10-01 at 12:53 +0200, Erik Trulsson wrote:
On Wed, Oct 01, 2008 at 08:39:47PM +1000, Da Rock wrote:
So are you saying I can't start a script manually without
...
For reference: I'm starting the script manually for testing at this
point (if that makes a difference- which I believe it shouldn't).
Manually running port installed rc scripts is not working manually. I'm
trying mysql, courier-imap, and I've tried isc-dhcp in the past. None
realised I had to do this last
time too...
For reference: I'm starting the script manually for testing at this
point (if that makes a difference- which I believe it shouldn't).
Manually running port installed rc scripts is not working manually. I'm
trying mysql, courier-imap, and I've tried isc
than a little frustrated.
Anyone else have this trouble? I just realised I had to do this last
time too...
For reference: I'm starting the script manually for testing at this
point (if that makes a difference- which I believe it shouldn't).
Manually running port installed rc scripts
- which I believe it shouldn't).
Manually running port installed rc scripts is not working manually. I'm
trying mysql, courier-imap, and I've tried isc-dhcp in the past. None of
these will work when run manually- even on different machines and bsd
versions (all 6.x).
Is it just me
a difference- which I believe it shouldn't).
Manually running port installed rc scripts is not working manually. I'm
trying mysql, courier-imap, and I've tried isc-dhcp in the past. None
of
these will work when run manually- even on different machines and bsd
versions (all 6.x
starting the script manually for testing at this
point (if that makes a difference- which I believe it shouldn't).
Manually running port installed rc scripts is not working manually. I'm
trying mysql, courier-imap, and I've tried isc-dhcp in the past. None of
these will work when
Jonathan Belson wrote:
Matthew Seaman wrote:
Yes. root is specifically exempted from all the masquerading stuff.
There's an EXPOSED_USER macro you can use in $(hostname).mc to control
that.
Ah, that explains it. There doesn't seem to be a way to remove exposed
users, but there is a web
if you run into any trouble!
OK, thanks. After playing with MASQUERADE_AS(), MASQUERADE_DOMAIN() plus a few
FEATURES(), I've managed to change the 'From:' address for e-mails sent via the
command line. Unfortunately, e-mails sent via the cron-ed periodic scripts
still don't get through, although
:' address for
| e-mails sent via the command line. Unfortunately, e-mails sent via the
| cron-ed periodic scripts still don't get through, although if I run e.g.
| 'periodic daily' from the command line, the mail does reach me.
|
| The only difference I can think of is that cron runs the scripts
Matthew Seaman wrote:
Jonathan Belson wrote:
| | OK, thanks. After playing with MASQUERADE_AS(), MASQUERADE_DOMAIN()
| plus a few FEATURES(), I've managed to change the 'From:' address for
| e-mails sent via the command line. Unfortunately, e-mails sent via
the | cron-ed periodic scripts
On Sun, 17 Aug 2008, David Wolfskill wrote:
[snipped]
will assign to foo the value of the bar variable form the last record
read (in FreeBSD 6.3-STABLE, at least), the following fails to do so:
foo=
cat $filename | while read bar ... ; do
...
foo=$bar
David Wolfskill wrote:
I am writing a (Bourne) shell script that is intended (among other
things) to obtain information from a command, such as:
netstat -nibd -f inet
by reading and parsing the output.
However, the obvious (to me) approach of piping the output of the
David Wolfskill wrote:
foo=
cat $filename | while read bar ... ; do
...
foo=$bar
...
done
echo $foo
A trick I've used to great advantage in bourne shell and bash for
passing multiple variables back is to produce small snippets of shell
script
As I thought while reading your message, awk seems to be
a good solution. Just a note:
On Mon, 18 Aug 2008 06:29:03 +0300, Giorgos Keramidas [EMAIL PROTECTED] wrote:
Would you
be ok with an awk(1) script instead of /bin/sh? It tends to be nicer
for this sort of thing, i.e.:
[...]
$
1 - 100 of 523 matches
Mail list logo
