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/perl
> 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 the
-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/week
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 iteratin
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
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 rem
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 n
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
>> On Wed, 25 Jan 2012 16:08:07 -0600,
>> "Doug Poland" 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 t
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'
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 tha
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 exactl
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
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 ba
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 con
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.
>
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 cod
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 some bashisms. On FreeBSD I ha
t;
>> Vince
>>
>>> 2011/8/23 Patrick Lamaiziere
>>>
>>>> Le Tue, 23 Aug 2011 17:50:43 +0400,
>>>> Pavel Timofeev a écrit :
>>>>
>>>> Hello,
>>>>
>>>>> Can carp(4) run daemons or scripts when ba
Aug 2011 17:50:43 +0400,
> >> Pavel Timofeev 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 a
l it to act on them.
A quick google for devd and carp gives
http://blather.michaelwlucas.com/archives/224
which looks like it covers the kind of thing you want.
Vince
>
> 2011/8/23 Patrick Lamaiziere
>
>> Le Tue, 23 Aug 2011 17:50:43 +0400,
>> Pavel Timofeev a écrit :
>>
&
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
> Le Tue, 23 Aug 2011 17:50:43 +0400,
> Pavel Timofeev a écrit :
>
> Hello,
>
> > Can carp(4) run daemons or script
Le Tue, 23 Aug 2011 17:50:43 +0400,
Pavel Timofeev 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 OpenBSD).
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
On Wed, 11 May 2011 11:59:48 +0200 Jonathan McKeown
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 interpre
On 15 May 2011 15:30, Randal L. Schwartz wrote:
> > "Chris" == Chris Telting 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 deta
> "Chris" == Chris Telting 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 issue. I simply wa
On 05/13/2011 14:34, Alejandro Imass wrote:
On Fri, May 13, 2011 at 6:07 AM, Chris Telting
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 exist and sudo was
part
On Sat, May 14, 2011 at 3:09 PM, Randal L. Schwartz
wrote:
>>>>>> "Pan" == Pan Tsu writes:
[...]
> (Untested) why not just "#!/usr/local/bin/sudo" ? It'll be given the
> filename as an argument.
Precisely. I think this thread should be forke
> "Pan" == Pan Tsu 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
so
Chris Telting 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 being suid is historic
On Fri, May 13, 2011 at 6:07 AM, Chris Telting
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 exist and sudo was
> part of the base system.
The sudo versus suid
C
On Friday, 13 May 2011, Pan Tsu wrote:
> Chris Telting 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 ratio
Chris Telting 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. But
...a shebang ca
On 13 May 2011 11:07, Chris Telting 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. It's just annoyin
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 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 tha
On 13 May 2011 08: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 t
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 co
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 and making
the binary SUID.
Well it's all hacks and in my not so humble option like chasing your
tail. The assumption
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 and making
> > the bi
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 and making
> >t
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. The way I have gotten around that (a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/11/11 12:31 PM, Alejandro Imass wrote:
> On Wed, May 11, 2011 at 10:14 AM, Jerry McAllister wrote:
>> On Tue, May 10, 2011 at 05:54:04PM -0700, Chris Telting wrote:
>>
>>> I've googled for over an hour.
>
> As
On Wed, May 11, 2011 at 10:14 AM, Jerry McAllister 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 smal
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 tim
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 mus
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
http://lists.freebsd
Chris Telting 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 indeed b
ng 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.
The reason that the suid bit doesn't work on scripts (shell, perl, or
otherwise) is because these are essentially text f
uld 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 in
--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 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 termi
On Tue, 10 May 2011 21:43:43 -0400, Daniel Staal 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 on partition
--As of May 10, 2011 5:54:04 PM -0700, Chris Telting is alleged to have
said:
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'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 a
eral question I have for quite a time: Can you
> use shell-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 pr
doug 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 long as you don't cal
> 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 environments? Does an attacker have
> the possibility to escape from a script down to a prompt?
>
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 to cope with termcap...) and s
to a generic python-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
owner-freebsd-questi...@freebsd.org
To: 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 and to do nothing else.
The straight-forw
pt?
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-scri
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.freebs
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 environmen
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 versio
n Fri, Jan 22, 2010 at 12:57 PM, DAve 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 scr
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 wo
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
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
Karl,
On Fri, Jun 12, 2009 at 3:07 PM, Karl Vogel 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 for a colleague.
Tha
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
__
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.
>>>
>>>
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 sen
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 (gi
nied, 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 a standard install), and/or how to
> disable this?
>
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 that are
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.co
Allow me an addition:
On Mon, 2 Mar 2009 03:53:24 +, RW 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
> ext
On Sun, 1 Mar 2009 19:14:17 -0800 (PST)
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 i
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
_
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 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 see
ginal Message -
From: "regis505"
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:
ing describing this kind of hang.
>
> - Original Message -
> From: "Sergio de Almeida Lenzi"
> To: "Formula 1" , "freebsd-questions"
>
> Sent: Saturday, February 21, 2009 6:18:22 AM GMT -08:00 US/Canada Pacific
> Subject: USB INSTALL SCRIPTS
thing
describing this kind of hang.
- Original Message -
From: "Sergio de Almeida Lenzi"
To: "Formula 1" , "freebsd-questions"
Sent: Saturday, February 21, 2009 6:18:22 AM GMT -08:00 US/Canada Pacific
Subject: USB INSTALL SCRIPTS
Ok...
the scripts are
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 a
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 a
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 manua
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 impress
e setup
> > > >> manually before so its no real biggy, but I imagine others would be
> > > >> more
> > > >> than a little frustrated.
> > > >>
> > > >> Anyone else have this trouble? I just realised I had to do this
; 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
> > >> poin
> > >>
> > >> 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 dif
gt;>
> >> 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 mysq
thers would be more
>> 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- wh
s 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 is not working manually. I'
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 page
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 p
techniques on those pages.
|>
|> Please post back here 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. Unfortunate
#x27;s coming from a
real email address by using the techniques on those pages.
Please post back here 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
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
>
1 - 100 of 545 matches
Mail list logo
