Re: CPU upgrade vs CPUTYPE

2012-12-18 Thread Joseph A. Nagy, Jr
Cross-posting reply to amd64@ for relevance and to get answers from 
those smart gents.


On 12/18/12 23:17, Toomas Aas wrote:

Hello!

We have a small server running FreeBSD 8.3 amd64 with Intel Pentium D
945 CPU. As the motherboard/CPU combo is getting rather old, we are
considering an upgrade to new motherboard with Xeon E3-1230 CPU. We
currently have these CPU settings

in /etc/make.conf:
CPUTYPE?=nocona

in kernel configuration:
cpu HAMMER


this is the only possible setting in the kernel conf for amd64 as I was 
told.


This was why (and might answer the make.conf question as well:

from b.f.:

Leave it alone.  The choices for the cpu directive in the kernel
config file, as described in config(5) and listed in
src/sys/conf/options. (the only choice for amd64 is HAMMER),
have nothing to do with the choices available for the CPUTYPE variable
(which you may want to change to suit your hardware -- these are the
architecture-dependent options available for the -march and -mtune
directives of your compiler that are also recognized by bsd.cpu.mk),
or with the cpu descriptions printed during boot.


As for the rest of your questions, I leave them in the hands of those 
more knowledgeable than I. HTH



Almost all the software is built from ports, few bits compiled directly
from source. Base system is maintained by buildworld.

Can we expect the software compiled with above CPU settings to run
without problems on the Xeon E3? We had a chance recently to try a
temporary motherboard/CPU swap in this server, replacing the CPU with
Core i3-2xxx and there were some 'signal 11' errors, but I'm not sure
whether this was due to incompatible CPUTYPE or something else.

Thanks in advance,




--
Yours in Christ,

Joseph A Nagy Jr
"Whoever loves instruction loves knowledge, But he who hates correction
is stupid." -- Proverbs 12:1
Emails are not formal business letters, whatever businesses may want.
Original content CopyFree (F) under the OWL http://owl.apotheon.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"


CPU upgrade vs CPUTYPE

2012-12-18 Thread Toomas Aas

Hello!

We have a small server running FreeBSD 8.3 amd64 with Intel Pentium D  
945 CPU. As the motherboard/CPU combo is getting rather old, we are  
considering an upgrade to new motherboard with Xeon E3-1230 CPU. We  
currently have these CPU settings


in /etc/make.conf:
CPUTYPE?=nocona

in kernel configuration:
cpu HAMMER

Almost all the software is built from ports, few bits compiled  
directly from source. Base system is maintained by buildworld.


Can we expect the software compiled with above CPU settings to run  
without problems on the Xeon E3? We had a chance recently to try a  
temporary motherboard/CPU swap in this server, replacing the CPU with  
Core i3-2xxx and there were some 'signal 11' errors, but I'm not sure  
whether this was due to incompatible CPUTYPE or something else.


Thanks in advance,

--
Toomas Aas

___
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: Somewhat OT: Is Full Command Logging Possible?

2012-12-18 Thread Tim Daneliuk

On 12/18/2012 10:10 PM, Devin Teske wrote:


On Dec 18, 2012, at 6:20 PM, Tim Daneliuk wrote:


On 12/18/2012 08:03 PM, Devin Teske wrote:


On Dec 18, 2012, at 5:43 PM, Tim Daneliuk wrote:


On 12/18/2012 07:33 PM, Devin Teske wrote:


On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote:







One further question, if I may.  If I do this:

   sudo su -

Will log_input record everything I do once I've been promoted to
root?  I ask because my initial experiments seem to show that all
that's getting recorded is the content of the sudo command itself,
not the subsequent actions…



Correct, sudo is blind to the actions performed once the command requested is executed 
(in this case, "su" and subsequently a shell followed by more actions).



Actually, I just tried this with both log_input and log_output options enabled.
It seems that it *can* see into the promoted shell with a few caveats:

  - Command output is logged immediately, but command inputs appear to only
be written to the log when you exit the promoted shell.  This may be
not quite right - there may have not been enough input to cause a
write flush to the log.

  - The logging seems to be able to see into a spawned subshell, but
I don't think it can see input/output if you, say, kick off an xterm.



What about if you do "sudo vim" and then type ":sh" ?


Yep, I just tried that too.  It catches that.  It also catches
the in/output of subshells - like, say, kicking off sh interactively.
Similarly, if you're running text-based emacs, it catches the output
of spawning to a shell from there and doing things.

The only restriction I have run into so far, it that - for obvious
reasons - sudo cannot see into what you're doing if you kick off
an X application like xterm or graphical emacs, for instance.



What about screen or tmux? (wondering if the transition into multiplexed shell 
is anywhere as opaque as X11).



It definitely works if you are in a screen session and sudo su - from there.  I 
have
not tried promoting myself to root and THEN starting the screen session (I 
don't use tmux).

--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Somewhat OT: Is Full Command Logging Possible?

2012-12-18 Thread Devin Teske

On Dec 18, 2012, at 6:20 PM, Tim Daneliuk wrote:

> On 12/18/2012 08:03 PM, Devin Teske wrote:
>> 
>> On Dec 18, 2012, at 5:43 PM, Tim Daneliuk wrote:
>> 
>>> On 12/18/2012 07:33 PM, Devin Teske wrote:
 
 On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote:
 
>>> 
>> 
> 
> One further question, if I may.  If I do this:
> 
>   sudo su -
> 
> Will log_input record everything I do once I've been promoted to
> root?  I ask because my initial experiments seem to show that all
> that's getting recorded is the content of the sudo command itself,
> not the subsequent actions…
> 
 
 Correct, sudo is blind to the actions performed once the command requested 
 is executed (in this case, "su" and subsequently a shell followed by more 
 actions).
 
>>> 
>>> Actually, I just tried this with both log_input and log_output options 
>>> enabled.
>>> It seems that it *can* see into the promoted shell with a few caveats:
>>> 
>>>  - Command output is logged immediately, but command inputs appear to only
>>>be written to the log when you exit the promoted shell.  This may be
>>>not quite right - there may have not been enough input to cause a
>>>write flush to the log.
>>> 
>>>  - The logging seems to be able to see into a spawned subshell, but
>>>I don't think it can see input/output if you, say, kick off an xterm.
>>> 
>> 
>> What about if you do "sudo vim" and then type ":sh" ?
> 
> Yep, I just tried that too.  It catches that.  It also catches
> the in/output of subshells - like, say, kicking off sh interactively.
> Similarly, if you're running text-based emacs, it catches the output
> of spawning to a shell from there and doing things.
> 
> The only restriction I have run into so far, it that - for obvious
> reasons - sudo cannot see into what you're doing if you kick off
> an X application like xterm or graphical emacs, for instance.
> 

What about screen or tmux? (wondering if the transition into multiplexed shell 
is anywhere as opaque as X11).
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. 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: which C function is best to check for directory EXISTANCE?

2012-12-18 Thread Karl Vogel
>> On Tue, 18 Dec 2012 16:26:10 -0800, 
>> Gary Kline  said:

G> which C function is best to check for the existence of a *directory*?
G> say that I am want to make postitve that "/tmp/foo/" exists.  ALso:
G> which will make sure that the directory AND file
G> "tmp/foo/filename12345" exists and that I have read access to it?

   I'd just call open() with O_RDONLY and if it fails, check errno for
   EACCESS (you don't have permission) or ENOENT (doesn't exist).

-- 
Karl Vogel  I don't speak for the USAF or my company

USELESS PHRASES WHEN SPEAKING TO A COP #9:
"You're not gonna check the trunk, are 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: Somewhat OT: Is Full Command Logging Possible?

2012-12-18 Thread Tim Daneliuk

On 12/18/2012 08:20 PM, Tim Daneliuk wrote:

On 12/18/2012 08:03 PM, Devin Teske wrote:


On Dec 18, 2012, at 5:43 PM, Tim Daneliuk wrote:


On 12/18/2012 07:33 PM, Devin Teske wrote:


On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote:







One further question, if I may.  If I do this:

   sudo su -

Will log_input record everything I do once I've been promoted to
root?  I ask because my initial experiments seem to show that all
that's getting recorded is the content of the sudo command itself,
not the subsequent actions…



Correct, sudo is blind to the actions performed once the command requested is executed 
(in this case, "su" and subsequently a shell followed by more actions).



Actually, I just tried this with both log_input and log_output options enabled.
It seems that it *can* see into the promoted shell with a few caveats:

  - Command output is logged immediately, but command inputs appear to only
be written to the log when you exit the promoted shell.  This may be
not quite right - there may have not been enough input to cause a
write flush to the log.

  - The logging seems to be able to see into a spawned subshell, but
I don't think it can see input/output if you, say, kick off an xterm.



What about if you do "sudo vim" and then type ":sh" ?


Yep, I just tried that too.  It catches that.  It also catches
the in/output of subshells - like, say, kicking off sh interactively.
Similarly, if you're running text-based emacs, it catches the output
of spawning to a shell from there and doing things.

The only restriction I have run into so far, it that - for obvious
reasons - sudo cannot see into what you're doing if you kick off
an X application like xterm or graphical emacs, for instance.


I should clarify that I tested this not on FreeBSD but on a Mint Linux
desktop I had handy.  I would expect the same behavior everywhere, though,
since sudo itself is reasonably portable...


--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Somewhat OT: Is Full Command Logging Possible?

2012-12-18 Thread Tim Daneliuk

On 12/18/2012 08:03 PM, Devin Teske wrote:


On Dec 18, 2012, at 5:43 PM, Tim Daneliuk wrote:


On 12/18/2012 07:33 PM, Devin Teske wrote:


On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote:







One further question, if I may.  If I do this:

   sudo su -

Will log_input record everything I do once I've been promoted to
root?  I ask because my initial experiments seem to show that all
that's getting recorded is the content of the sudo command itself,
not the subsequent actions…



Correct, sudo is blind to the actions performed once the command requested is executed 
(in this case, "su" and subsequently a shell followed by more actions).



Actually, I just tried this with both log_input and log_output options enabled.
It seems that it *can* see into the promoted shell with a few caveats:

  - Command output is logged immediately, but command inputs appear to only
be written to the log when you exit the promoted shell.  This may be
not quite right - there may have not been enough input to cause a
write flush to the log.

  - The logging seems to be able to see into a spawned subshell, but
I don't think it can see input/output if you, say, kick off an xterm.



What about if you do "sudo vim" and then type ":sh" ?


Yep, I just tried that too.  It catches that.  It also catches
the in/output of subshells - like, say, kicking off sh interactively.
Similarly, if you're running text-based emacs, it catches the output
of spawning to a shell from there and doing things.

The only restriction I have run into so far, it that - for obvious
reasons - sudo cannot see into what you're doing if you kick off
an X application like xterm or graphical emacs, for instance.







--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Somewhat OT: Is Full Command Logging Possible?

2012-12-18 Thread Devin Teske

On Dec 18, 2012, at 5:43 PM, Tim Daneliuk wrote:

> On 12/18/2012 07:33 PM, Devin Teske wrote:
>> 
>> On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote:
>> 
> 
 
>>> 
>>> One further question, if I may.  If I do this:
>>> 
>>>   sudo su -
>>> 
>>> Will log_input record everything I do once I've been promoted to
>>> root?  I ask because my initial experiments seem to show that all
>>> that's getting recorded is the content of the sudo command itself,
>>> not the subsequent actions…
>>> 
>> 
>> Correct, sudo is blind to the actions performed once the command requested 
>> is executed (in this case, "su" and subsequently a shell followed by more 
>> actions).
>> 
> 
> Actually, I just tried this with both log_input and log_output options 
> enabled.
> It seems that it *can* see into the promoted shell with a few caveats:
> 
>  - Command output is logged immediately, but command inputs appear to only
>be written to the log when you exit the promoted shell.  This may be
>not quite right - there may have not been enough input to cause a
>write flush to the log.
> 
>  - The logging seems to be able to see into a spawned subshell, but
>I don't think it can see input/output if you, say, kick off an xterm.
> 

What about if you do "sudo vim" and then type ":sh" ?
-- 
Devin



> 
>> I've suggested the lrexec module for catching everything, or you can look 
>> into the auditdistd (distributed auditing collection/collation to a 
>> remote/central server) approach, the praudit approach, or any of the other 
>> pieces of software mentions.
>> 

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. 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: Somewhat OT: Is Full Command Logging Possible?

2012-12-18 Thread Tim Daneliuk

On 12/18/2012 07:33 PM, Devin Teske wrote:


On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote:







One further question, if I may.  If I do this:

   sudo su -

Will log_input record everything I do once I've been promoted to
root?  I ask because my initial experiments seem to show that all
that's getting recorded is the content of the sudo command itself,
not the subsequent actions…



Correct, sudo is blind to the actions performed once the command requested is executed 
(in this case, "su" and subsequently a shell followed by more actions).



Actually, I just tried this with both log_input and log_output options enabled.
It seems that it *can* see into the promoted shell with a few caveats:

  - Command output is logged immediately, but command inputs appear to only
be written to the log when you exit the promoted shell.  This may be
not quite right - there may have not been enough input to cause a
write flush to the log.

  - The logging seems to be able to see into a spawned subshell, but
I don't think it can see input/output if you, say, kick off an xterm.



I've suggested the lrexec module for catching everything, or you can look into 
the auditdistd (distributed auditing collection/collation to a remote/central 
server) approach, the praudit approach, or any of the other pieces of software 
mentions.




--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Somewhat OT: Is Full Command Logging Possible?

2012-12-18 Thread Devin Teske

On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote:

> On 12/18/2012 07:09 PM, Tim Daneliuk wrote:
>> On 12/18/2012 06:53 PM, John Hein wrote:
>>> Tim Daneliuk wrote at 17:48 -0600 on Dec  5, 2012:
>>>  > On 12/05/2012 05:44 PM, Kurt Buff wrote:
>>>  > > On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk  
>>> wrote:
>>>  > >> I am working with an institution that today provides limited privilege
>>>  > >> escalation
>>>  > >> on their servers via very specific sudo rules.  The problem is that 
>>> the
>>>  > >> administrators can do 'sudo su -'.
>>>  > > 
>>>  > >
>>>  > >
>>>  > > sudo is misconfigured.
>>>  > >
>>>  > > man 5 sudoers and man 8 visudo
>>>  > >
>>>  > >
>>>  > >
>>>  > > Kurt
>>>  > >
>>>  >
>>>  > I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're
>>>  > saying.  Are you suggesting that there is a way to configure
>>>  > sudo so that if someone does 'sudo su -' to become an admin,
>>>  > sudo can be made to log every command they execute thereafter?
>>> 
>>> See log_input and log_output in sudoers(5)
>> 
>> Thanks so much John, that's the secret sauce I was looking for...
>> 
>> 
> 
> One further question, if I may.  If I do this:
> 
>   sudo su -
> 
> Will log_input record everything I do once I've been promoted to
> root?  I ask because my initial experiments seem to show that all
> that's getting recorded is the content of the sudo command itself,
> not the subsequent actions…
> 

Correct, sudo is blind to the actions performed once the command requested is 
executed (in this case, "su" and subsequently a shell followed by more actions).

I've suggested the lrexec module for catching everything, or you can look into 
the auditdistd (distributed auditing collection/collation to a remote/central 
server) approach, the praudit approach, or any of the other pieces of software 
mentions.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. 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: Somewhat OT: Is Full Command Logging Possible?

2012-12-18 Thread Tim Daneliuk

On 12/18/2012 07:09 PM, Tim Daneliuk wrote:

On 12/18/2012 06:53 PM, John Hein wrote:

Tim Daneliuk wrote at 17:48 -0600 on Dec  5, 2012:
  > On 12/05/2012 05:44 PM, Kurt Buff wrote:
  > > On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk  
wrote:
  > >> I am working with an institution that today provides limited privilege
  > >> escalation
  > >> on their servers via very specific sudo rules.  The problem is that the
  > >> administrators can do 'sudo su -'.
  > > 
  > >
  > >
  > > sudo is misconfigured.
  > >
  > > man 5 sudoers and man 8 visudo
  > >
  > >
  > >
  > > Kurt
  > >
  >
  > I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're
  > saying.  Are you suggesting that there is a way to configure
  > sudo so that if someone does 'sudo su -' to become an admin,
  > sudo can be made to log every command they execute thereafter?

See log_input and log_output in sudoers(5)


Thanks so much John, that's the secret sauce I was looking for...




One further question, if I may.  If I do this:

   sudo su -

Will log_input record everything I do once I've been promoted to
root?  I ask because my initial experiments seem to show that all
that's getting recorded is the content of the sudo command itself,
not the subsequent actions...

--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Somewhat OT: Is Full Command Logging Possible?

2012-12-18 Thread Tim Daneliuk

On 12/18/2012 06:53 PM, John Hein wrote:

Tim Daneliuk wrote at 17:48 -0600 on Dec  5, 2012:
  > On 12/05/2012 05:44 PM, Kurt Buff wrote:
  > > On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk  
wrote:
  > >> I am working with an institution that today provides limited privilege
  > >> escalation
  > >> on their servers via very specific sudo rules.  The problem is that the
  > >> administrators can do 'sudo su -'.
  > > 
  > >
  > >
  > > sudo is misconfigured.
  > >
  > > man 5 sudoers and man 8 visudo
  > >
  > >
  > >
  > > Kurt
  > >
  >
  > I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're
  > saying.  Are you suggesting that there is a way to configure
  > sudo so that if someone does 'sudo su -' to become an admin,
  > sudo can be made to log every command they execute thereafter?

See log_input and log_output in sudoers(5)


Thanks so much John, that's the secret sauce I was looking for...


--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Somewhat OT: Is Full Command Logging Possible?

2012-12-18 Thread John Hein
Tim Daneliuk wrote at 17:48 -0600 on Dec  5, 2012:
 > On 12/05/2012 05:44 PM, Kurt Buff wrote:
 > > On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk  wrote:
 > >> I am working with an institution that today provides limited privilege
 > >> escalation
 > >> on their servers via very specific sudo rules.  The problem is that the
 > >> administrators can do 'sudo su -'.
 > > 
 > >
 > >
 > > sudo is misconfigured.
 > >
 > > man 5 sudoers and man 8 visudo
 > >
 > >
 > >
 > > Kurt
 > >
 >
 > I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're
 > saying.  Are you suggesting that there is a way to configure
 > sudo so that if someone does 'sudo su -' to become an admin,
 > sudo can be made to log every command they execute thereafter?

See log_input and log_output in sudoers(5)
___
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: which C function is best to check for directory EXISTANCE?

2012-12-18 Thread Polytropon
On Tue, 18 Dec 2012 16:26:10 -0800, Gary Kline wrote:
> 
>   which C function is best to check for the existence of a 
>   *directory*?  say that I am want to make postitve that "/tmp/foo/"
>   exists.

That can be done with the opendir() function; its manpage
lists other interesting "follow-up functions" to work with.



>   ALso: which will make sure that the directory AND ffile 
>   "tmp/foo/filename12345" exists and that I have read access to it?

You can use readdir() and parse its output. If you already know
the file name, use a fopen() call for the mode you're trying to
open it with (e. g. "r" or "w") to see if the permissions are
set accordingly. Also ferror() can be used to test for specific
errors that may occur during file operations.



>   in other words, can playing around with access() and stat() be
>   best?

That also sounds possible. In case you're going to continue to
operate with the file in question, certain functions sound better.
But for the "pure testing", access() and stat() provide sufficient
functionality.


> is there any new dirstat("PATh") that would work?

$ man dirstat
No manual entry for dirstat

:-)



>   just want to see which way is best?

Depends. :-)




-- 
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"


which C function is best to check for directory EXISTANCE?

2012-12-18 Thread Gary Kline

which C function is best to check for the existence of a 
*directory*?  say that I am want to make postitve that "/tmp/foo/"
exists.

ALso: which will make sure that the directory AND ffile 
"tmp/foo/filename12345" exists and that I have read access to it?
in other words, can playing around with access() and stat() be
best?  is there any new dirstat("PATh") that would work?

just want to see which way is best?

dank mucho, y'all!

gary


-- 
 Gary Kline  kl...@thought.org  http://www.thought.org  Public Service Unix
  Twenty-six years of service to the Unix community.

___
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: updatedb?

2012-12-18 Thread Bas Smeelen

On 12/18/12 23:04, C. P. Ghost wrote:

On Tue, Dec 18, 2012 at 10:01 PM, Walter Hurry  wrote:

$ sudo /usr/libexec/locate.updatedb

WARNING
Executing updatedb as root.  This WILL reveal all filenames
on your machine to all login users, which is a security risk.

$

Why is it a "security risk"? Security through obscurity? Really? In this
day and age?

Or am I missing something?

Suppose someone managed to start a shell under your account
and is seeking to escalate privileges, i.e. to become root. If he can
look at a full unrestricted locatedb, he may pay particular attention
to config files, log files etc... that may otherwise be hidden from sight.

Just by looking at this, he may infer that a particular software package
at a particular revision is actually running on that host and is configured
in a particular way. E.g., he may see that logfiles accumulate in /var/log
and are cleaned only once a week. It would be then easy to induce that
program to create more log files, thus denying service to other programs
that need /var as well. This, in turn, could result in real exploits of those
other programs...

Sure, most of this is already world-visible and in the regular locatedb
because we're so liberal with the rights of /var/db/pkg, /var/log, /etc, ... but
some admins prefer to hide particularly sensitive programs, their configs,
logs etc., in a non-world-readable directory hierarchy. Running
locate.updatedb(8) with root privileges would defeat that strategy.
That's why it is discouraged.

Of course, this is even more necessary when you have regular users on
that machine that don't necessarily trust each others. They wouldn't like
their home dirs to be world-readable by default by everyone else. Maybe
they won't object (and set /home/$USER to -rwxr-xr-x instead of -rwxr-x---
or -rwx--) but that's their call, not the sysadmin's.

-cpghost.



Sorry, cpghost, I missed the point. Clear explanation.
Should such programs be modified so there is never a change to being run 
as root?


I guess there are environments where measures like these are taken, no 
warning, just refuse to run as root?


___
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: updatedb?

2012-12-18 Thread Bas Smeelen

On 12/18/12 23:44, RW wrote:

On Tue, 18 Dec 2012 22:53:29 +0100
Polytropon wrote:


On Tue, 18 Dec 2012 21:32:50 +, RW wrote:

On Tue, 18 Dec 2012 21:01:33 + (UTC)
Walter Hurry wrote:


$ sudo /usr/libexec/locate.updatedb

WARNING
Executing updatedb as root.  This WILL reveal all filenames
on your machine to all login users, which is a security risk.

$

Why is it a "security risk"? Security through obscurity? Really?
In this day and age?

Or am I missing something?

If permissions have been set to prevent other users reading
filenames then obviously leaking file names is security issue.

There are no "leaking file names",

There is from the perspective of an ordinary user that's configured
directories under ~ to be confidential.


as by command, the tool does
what it is requested to: to not obey the restrictions that apply
in its _normal_ use and list _all_ file names instead.

Obviously. But the warning is intended for people that haven't
thought through the consequences of what they are doing.


Agree. It is good to be there. Should be clear to Walter I guess. It is 
not security through obscurity, it is security by permissions and 
controls, and root can circumvent these and expose potential security 
risks by information to others or the world, thus the warning when 
running it as root.


Thanks.




On Tue, 18 Dec 2012 22:49:43 +0100
Bas Smeelen wrote:



Yes. But as stated before it defaults to run as user nobody.

Line 26 /etc/periodic/weekly/310.locate
echo /usr/libexec/locate.updatedb | nice -n 5 su -fm nobody || rc=3

This is true but not very relevant.

It runs as nobody from the periodic script, but the warning comes from
locate.updatedb itself, which may be run independently of 310.locate.


If someone runs it as root it can be, as everything being run as
root, a security issue.

Not really, mostly when things are run as root there is an additional
risk. Very few things do the wrong thing simply as a consequence of
running as root so it warrants a warning.


Fully agree. Root can be a liability though.


___
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: updatedb?

2012-12-18 Thread RW
On Tue, 18 Dec 2012 22:53:29 +0100
Polytropon wrote:

> On Tue, 18 Dec 2012 21:32:50 +, RW wrote:
> > On Tue, 18 Dec 2012 21:01:33 + (UTC)
> > Walter Hurry wrote:
> > 
> > > $ sudo /usr/libexec/locate.updatedb
> > > >>> WARNING
> > > >>> Executing updatedb as root.  This WILL reveal all filenames
> > > >>> on your machine to all login users, which is a security risk.
> > > $
> > > 
> > > Why is it a "security risk"? Security through obscurity? Really?
> > > In this day and age?
> > > 
> > > Or am I missing something?
> > 
> > If permissions have been set to prevent other users reading
> > filenames then obviously leaking file names is security issue.
> 
> There are no "leaking file names",

There is from the perspective of an ordinary user that's configured
directories under ~ to be confidential.

> as by command, the tool does
> what it is requested to: to not obey the restrictions that apply
> in its _normal_ use and list _all_ file names instead.

Obviously. But the warning is intended for people that haven't
thought through the consequences of what they are doing.

On Tue, 18 Dec 2012 22:49:43 +0100
Bas Smeelen wrote:


> Yes. But as stated before it defaults to run as user nobody.
> 
> Line 26 /etc/periodic/weekly/310.locate
> echo /usr/libexec/locate.updatedb | nice -n 5 su -fm nobody || rc=3

This is true but not very relevant.

It runs as nobody from the periodic script, but the warning comes from
locate.updatedb itself, which may be run independently of 310.locate.  

> If someone runs it as root it can be, as everything being run as
> root, a security issue.

Not really, mostly when things are run as root there is an additional
risk. Very few things do the wrong thing simply as a consequence of
running as root so it warrants a warning.
___
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: svn revision in uname

2012-12-18 Thread Lowell Gilbert
David Demelier  writes:

>
> 2012/12/15 Lowell Gilbert 
>
>> "Anders N."  writes:
>>
>> > Hi. I've noticed in my "uname -a" on 9.1-RELEASE there is "r243826."
>> > This is on a system that upgraded from 9.1-RC3 using freebsd-update
>> > (binary). On another system, upgraded from 9.0-RELEASE via
>> > freebsd-update (source), there is nothing at all and uname -a looks
>> > normal. Two other people I asked have r243825 (installed from ISO) and
>> > r243872 (upgraded from svn).
>> >
>> > They're all 9.1-RELEASE, shouldn't they be the same, final version?
>>
>> As I understand it, the revision ID refers to the whole repository, not
>> just a branch. So if you do your own svn checkout tomorrow, you'll get
>> yet another revision number, even though the files will (probably) be
>> completely identical to what you checked out yesterday -- ongoing
>> commits to HEAD will keep kicking the revision number up.
>>
>> There is work going on to make system builds completely, bit-for-bit,
>> repeatable, but that will presumably mean getting rid of this revision
>> number information, not making it consistent.

> I hope it will be removed soon, it pollutes the uname -a output.

It's easy enough to add a stage in the kernel build to remove it if you
don't like it, but in most source-update environments it's a very
valuable piece of information. Even if a reproduceable-build
infrastructure is put in place, it would have to be optional because
this information is necessary in heterogeneous environments. I don't
know that anyone's working on it the moment -- I *thought* I'd read
something about it recently, but I can't find any reference to such an
effort this year.
___
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: updatedb?

2012-12-18 Thread Bas Smeelen

On 12/18/12 23:04, C. P. Ghost wrote:

On Tue, Dec 18, 2012 at 10:01 PM, Walter Hurry  wrote:

$ sudo /usr/libexec/locate.updatedb

WARNING
Executing updatedb as root.  This WILL reveal all filenames
on your machine to all login users, which is a security risk.

$

Why is it a "security risk"? Security through obscurity? Really? In this
day and age?

Or am I missing something?

Suppose someone managed to start a shell under your account
and is seeking to escalate privileges, i.e. to become root. If he can
look at a full unrestricted locatedb, he may pay particular attention
to config files, log files etc... that may otherwise be hidden from sight.


locate.updatebd is _not_ run as root by default.
See Polytropon's and other replies.

If root runs it, it is root's responsibility that others can obtain all 
filenames on the system.




Just by looking at this, he may infer that a particular software package
at a particular revision is actually running on that host and is configured
in a particular way. E.g., he may see that logfiles accumulate in /var/log
and are cleaned only once a week. It would be then easy to induce that
program to create more log files, thus denying service to other programs
that need /var as well. This, in turn, could result in real exploits of those
other programs...

Sure, most of this is already world-visible and in the regular locatedb
because we're so liberal with the rights of /var/db/pkg, /var/log, /etc, ... but
some admins prefer to hide particularly sensitive programs, their configs,
logs etc., in a non-world-readable directory hierarchy. Running
locate.updatedb(8) with root privileges would defeat that strategy.
That's why it is discouraged.

Of course, this is even more necessary when you have regular users on
that machine that don't necessarily trust each others. They wouldn't like
their home dirs to be world-readable by default by everyone else. Maybe
they won't object (and set /home/$USER to -rwxr-xr-x instead of -rwxr-x---
or -rwx--) but that's their call, not the sysadmin's.

-cpghost.




___
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: updatedb?

2012-12-18 Thread C. P. Ghost
On Tue, Dec 18, 2012 at 10:01 PM, Walter Hurry  wrote:
> $ sudo /usr/libexec/locate.updatedb
 WARNING
 Executing updatedb as root.  This WILL reveal all filenames
 on your machine to all login users, which is a security risk.
> $
>
> Why is it a "security risk"? Security through obscurity? Really? In this
> day and age?
>
> Or am I missing something?

Suppose someone managed to start a shell under your account
and is seeking to escalate privileges, i.e. to become root. If he can
look at a full unrestricted locatedb, he may pay particular attention
to config files, log files etc... that may otherwise be hidden from sight.

Just by looking at this, he may infer that a particular software package
at a particular revision is actually running on that host and is configured
in a particular way. E.g., he may see that logfiles accumulate in /var/log
and are cleaned only once a week. It would be then easy to induce that
program to create more log files, thus denying service to other programs
that need /var as well. This, in turn, could result in real exploits of those
other programs...

Sure, most of this is already world-visible and in the regular locatedb
because we're so liberal with the rights of /var/db/pkg, /var/log, /etc, ... but
some admins prefer to hide particularly sensitive programs, their configs,
logs etc., in a non-world-readable directory hierarchy. Running
locate.updatedb(8) with root privileges would defeat that strategy.
That's why it is discouraged.

Of course, this is even more necessary when you have regular users on
that machine that don't necessarily trust each others. They wouldn't like
their home dirs to be world-readable by default by everyone else. Maybe
they won't object (and set /home/$USER to -rwxr-xr-x instead of -rwxr-x---
or -rwx--) but that's their call, not the sysadmin's.

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
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: updatedb?

2012-12-18 Thread Polytropon
On Tue, 18 Dec 2012 21:32:50 +, RW wrote:
> On Tue, 18 Dec 2012 21:01:33 + (UTC)
> Walter Hurry wrote:
> 
> > $ sudo /usr/libexec/locate.updatedb
> > >>> WARNING
> > >>> Executing updatedb as root.  This WILL reveal all filenames
> > >>> on your machine to all login users, which is a security risk.
> > $
> > 
> > Why is it a "security risk"? Security through obscurity? Really? In
> > this day and age?
> > 
> > Or am I missing something?
> 
> If permissions have been set to prevent other users reading filenames
> then obviously leaking file names is security issue.

There are no "leaking file names", as by command, the tool does
what it is requested to: to not obey the restrictions that apply
in its _normal_ use and list _all_ file names instead.

See /etc/periodic/weekly/310.locate for example: The default call
of locate.updatedb is this:

echo /usr/libexec/locate.updatedb | nice -n 5 su -fm nobody || rc=3

The program (script) will additionally honor settings in the
/etc/locate.rc file.

So if the questioned use of "sudo /usr/libexec/locate.updatedb" to
run it as root (with _all_ permissions!) leads to the intended
behaviour, i. e. list _all_ files on the system, that isn't
actually a leak, I'd say. (Terminology: A leak would appear if
you'd run locate.updatedb with the "nobody" user, and still
file names from inside a o-rwx directory would appear!)

I really like the analogy provided by Devin Teske in his reply:

When you run updatedb as root, it traverses all
directories even those that you may have posted
a big "keep out" sign on (aforementioned "chmod").
Then every non-privileged user on the system can
list the contents of your secret hideout with the
"keep out" sign posted on it. You might have well
built that house out of glass (they can't read the
contents of the books on your bookshelf, but they
can see the covers and know what you've got stocked
on the shelves).

Again: If that's intended, locate.updatedb will act as instructed.
Oh behold the unlimited power of root. :-)




-- 
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: updatedb?

2012-12-18 Thread Bas Smeelen

On 12/18/12 22:32, RW wrote:

On Tue, 18 Dec 2012 21:01:33 + (UTC)
Walter Hurry wrote:


$ sudo /usr/libexec/locate.updatedb

WARNING
Executing updatedb as root.  This WILL reveal all filenames
on your machine to all login users, which is a security risk.

$

Why is it a "security risk"? Security through obscurity? Really? In
this day and age?

Or am I missing something?

If permissions have been set to prevent other users reading filenames
then obviously leaking file names is security issue.


Yes. But as stated before it defaults to run as user nobody.

Line 26 /etc/periodic/weekly/310.locate
echo /usr/libexec/locate.updatedb | nice -n 5 su -fm nobody || rc=3

No issue there.

If someone runs it as root it can be, as everything being run as root, a 
security issue.




___
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: updatedb?

2012-12-18 Thread RW
On Tue, 18 Dec 2012 21:01:33 + (UTC)
Walter Hurry wrote:

> $ sudo /usr/libexec/locate.updatedb
> >>> WARNING
> >>> Executing updatedb as root.  This WILL reveal all filenames
> >>> on your machine to all login users, which is a security risk.
> $
> 
> Why is it a "security risk"? Security through obscurity? Really? In
> this day and age?
> 
> Or am I missing something?

If permissions have been set to prevent other users reading filenames
then obviously leaking file names is security issue.
  

___
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: updatedb?

2012-12-18 Thread Adam Vande More
On Tue, Dec 18, 2012 at 3:01 PM, Walter Hurry  wrote:

> Security through obscurity? Really? In this
> day and age?
>

My password is obscured from you.  I consider that more secure regardless
of what any other opinion is.

-- 
Adam Vande More
___
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: updatedb?

2012-12-18 Thread Polytropon
On Tue, 18 Dec 2012 21:01:33 + (UTC), Walter Hurry wrote:
> $ sudo /usr/libexec/locate.updatedb
> >>> WARNING
> >>> Executing updatedb as root.  This WILL reveal all filenames
> >>> on your machine to all login users, which is a security risk.
> $
> 
> Why is it a "security risk"? Security through obscurity? Really? In this 
> day and age?
> 
> Or am I missing something?

Depends. In case you're using your system primarily as a 
single-user installation - no problem. If there are users
who don't have trust in others (and this is _correct_),
any call of "locate " could reveal data stored
on different user accounts, even if they cannot be accessed
due to o-x for the individual home directories. Sometimes
file names can already tell a lot.

The locate.updatedb is usually run from the "nobody" user
account when invoked automatically. This means that the
directory restrictions can apply (e. g. user home directories
cannot be searched when they have o-x attribute).





-- 
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: updatedb?

2012-12-18 Thread Devin Teske

On Dec 18, 2012, at 1:01 PM, Walter Hurry wrote:

> $ sudo /usr/libexec/locate.updatedb
 WARNING
 Executing updatedb as root.  This WILL reveal all filenames
 on your machine to all login users, which is a security risk.
> $
> 
> Why is it a "security risk"? Security through obscurity? Really? In this 
> day and age?
> 
> Or am I missing something?

You're missing the fact that updatedb essentially makes a list of every file on 
your disk (and that this list is able to be queried by anybody regardless of 
permissions or group membership).

The best and most notable example of this constituting a "security risk" is if 
you've prevented access to a directory… root's home-directory (/root) for 
example. Illustratively, this would be if you did "chmod go-wrx somedir" so 
that only the owner could see inside it.

When you run updatedb as root, it traverses all directories even those that you 
may have posted a big "keep out" sign on (aforementioned "chmod"). Then every 
non-privileged user on the system can list the contents of your secret hideout 
with the "keep out" sign posted on it. You might have well built that house out 
of glass (they can't read the contents of the books on your bookshelf, but they 
can see the covers and know what you've got stocked on the shelves).

If this doesn't concern you, (and there's plenty of reasons to ignore this 
warning -- say, if you operate in a closed environment where trust isn't an 
issue and you value the ability to find any file on the system at any time) -- 
then proceed my friend, … proceed.

Otherwise, it's best to think about running updatedb as a non-privileged user 
that (a) can't use built-in super-user privileges to bypass security settings 
when enumerating the UNIX filesystems you've configured in locate.conf(5) 
(optional -- by default it acts sensibly and ignores what you'd expect it to).
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. 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"


updatedb?

2012-12-18 Thread Walter Hurry
$ sudo /usr/libexec/locate.updatedb
>>> WARNING
>>> Executing updatedb as root.  This WILL reveal all filenames
>>> on your machine to all login users, which is a security risk.
$

Why is it a "security risk"? Security through obscurity? Really? In this 
day and age?

Or am I missing something?

___
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 AWK

2012-12-18 Thread RW
On Mon, 17 Dec 2012 08:16:26 -0800
Devin Teske wrote:

> 
> On Dec 17, 2012, at 3:39 AM, Jack Mc Lauren wrote:
> 
> > Hi guys
> > 
> > How can I read a file which contains a number and assign that
> > number to a variable via awk programming? By the way, I want to use
> > this awk program in a shell script.
> > 
> > Thanks in advance
> 
> Try this:
> 
> awk -v file=/etc/ttys 'BEGIN { getline line  from %s: %s\n", file, line }'
> 
Semms a bit complicated when you could set the awk variable directly
e.g.

$ echo 42 > /tmp/f
$ awk -v x=`cat /tmp/f`  'BEGIN{ print x+1 }'
43


___
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: svn revision in uname

2012-12-18 Thread C. P. Ghost
On Mon, Dec 17, 2012 at 2:13 PM, David Demelier
 wrote:
> I hope it will be removed soon, it pollutes the uname -a output.

I don't hope so. It helps us keep track of the exact revision
numbers of deployed servers here. Please don't remove it,
or at least, provide an additional switch to uname to
retrieve it.

Thanks,
-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
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: Upgrading FreeBSD 8.3 amd64

2012-12-18 Thread Polytropon
On Tue, 18 Dec 2012 18:54:29 +0100, Ralf Mardorf wrote:
> On Tue, 2012-12-18 at 18:42 +0100, Ralf Mardorf wrote:
> > I want to test snd_hdspe. How can I upgrade from 8.2 to a version
>   ^^^8.3
> > including the driver or something similar to get the driver?
> > Btw. I didn't test, if the driver is part of 8.3 until now :D, but if
> > IIUC I need >= 9.0.
> 
> I'll read
> http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html
> can I assume that because I didn't install or updated and configured
> anything until now, there won't be issues for a version upgrade, if I
> only configure PPPoE, followed by a release upgrade and after that I'll
> install software and set up FreeBSD completely?

Sounds like a valid approach. I've been doing this many times,
i. e. first install base system from installation media without
additional packages, setup networking (PPPoE in former times,
DHCP today), then update the system to the desired version or
branch (e. g. -STABLE via source), and then start installing
the applications from ports (also updated).



-- 
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: Upgrading FreeBSD 8.3 amd64

2012-12-18 Thread Ralf Mardorf
On Tue, 2012-12-18 at 18:57 +0100, Polytropon wrote:
> On Tue, 18 Dec 2012 18:42:41 +0100, Ralf Mardorf wrote:
> > I want to test snd_hdspe. How can I upgrade from 8.2 to a version
> > including the driver or something similar to get the driver?
> > Btw. I didn't test, if the driver is part of 8.3 until now :D, but if
> > IIUC I need >= 9.0.
> 
> It would probably be the easiest way to update your source tree
> (using svn as this is the default method today) and re-install
> from that. I'm not sure freebsd-update can cross the "major
> version border" without trouble (never tried).
> 
> See 25.7 for details:
> 
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html
> 
> But also note that freebsd-update supports a -r  option
> as explained in 25.2.3:
> 
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html
> 
> But as I said, I've never personally tried that.
> 
> This approach keeps all your partition settings and doesn't require
> any other work to be done on that level.

Thank you :)

I'll read and test it later.

Regards,
Ralf

___
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: Upgrading FreeBSD 8.3 amd64

2012-12-18 Thread Polytropon
On Tue, 18 Dec 2012 18:42:41 +0100, Ralf Mardorf wrote:
> I want to test snd_hdspe. How can I upgrade from 8.2 to a version
> including the driver or something similar to get the driver?
> Btw. I didn't test, if the driver is part of 8.3 until now :D, but if
> IIUC I need >= 9.0.

It would probably be the easiest way to update your source tree
(using svn as this is the default method today) and re-install
from that. I'm not sure freebsd-update can cross the "major
version border" without trouble (never tried).

See 25.7 for details:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html

But also note that freebsd-update supports a -r  option
as explained in 25.2.3:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html

But as I said, I've never personally tried that.

This approach keeps all your partition settings and doesn't require
any other work to be done on that level.


-- 
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: Upgrading FreeBSD 8.3 amd64

2012-12-18 Thread Ralf Mardorf
On Tue, 2012-12-18 at 18:42 +0100, Ralf Mardorf wrote:
> I want to test snd_hdspe. How can I upgrade from 8.2 to a version
  ^^^8.3
> including the driver or something similar to get the driver?
> Btw. I didn't test, if the driver is part of 8.3 until now :D, but if
> IIUC I need >= 9.0.

I'll read
http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html
can I assume that because I didn't install or updated and configured
anything until now, there won't be issues for a version upgrade, if I
only configure PPPoE, followed by a release upgrade and after that I'll
install software and set up FreeBSD completely?

___
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"


Upgrading FreeBSD 8.3 amd64

2012-12-18 Thread Ralf Mardorf
Hi :)

first I tried to install FreeBSD 9.0 64bit by the default installer, but
it didn't work, then I installed PC-BSD 8.2 and it worked, after that I
tried 9.0 again, but I choose sysinstall, it also failed.

Now I've got FreeBSD 8.3 64bit installed, installing it worked without
issues. I later today need to set up FreeBSD.

The self-doubts that I'm an idiot are gone ;), I did the same as I tried
to do for 9.0. The 9.0 media's checksum and the burners verifying after
burning were ok.

I want to test snd_hdspe. How can I upgrade from 8.2 to a version
including the driver or something similar to get the driver?
Btw. I didn't test, if the driver is part of 8.3 until now :D, but if
IIUC I need >= 9.0.

Regards,
Ralf

___
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: Torrents Page

2012-12-18 Thread Willem Jan Withagen
On 12/13/12 12:09, Paul Hohberg wrote:
> I have been unable to access the torrents page at 
> http://torrents.FreeBSD.org:8080/ is this something you are working 
> on?
> 

> My understanding is that it was found to have too many security 
> issues and has been taken down because of that. I have also heard it 
> may or may not be back. Of course, that is at best rumor. I've not
> seen anything really "official".

Given the fact that it runs on a host called:
bwwwdyn.freebsd.org
Which sounds horribly dynamic, is/was it a FreeBSD service, or a service
just offered?

I do not hat the bandwidth to run a massive supply of torrents, but
offering the service as central torrent administration would be
something I'd willing to look at.

--WjW
___
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"


portmaster: hal-0.5.14_20 and xorg-server-1.7.7_6, 1 (re)installation fails

2012-12-18 Thread Bas Smeelen
When running portmaster -d -w -r pcre because of the upgrade from 
pcre-8.31 to pcre-8.32 I encountered the following inconveniences:


Upgrade to hal-0.5.14_20 failed with the message it needs intltool > 
0.40 which was installed at the time. First upgrading to intltool-0.41.1 
solved this.


When reinstalling xorg-server-1.7.7_6,1 with portmaster today:

Making install in xkb
mkdir: /usr/local/share/X11/xkb/compiled: No such file or directory
mkdir: /usr/local/share/X11/xkb/compiled: No such file or directory

So I checked /usr/local/share/X11/xkb/compiled and this is a symlink to 
/var/lib/xkb which did not exist at the time. I created /var/lib/xkb and 
the installation went fine then. There is one file installed in this 
location: README.compiled


This worked, but is it the right solution? Does anyone know what changed 
maybe?


This is on 9.1-RELEASE with a portstree just updated with portsnap. 
Previous versions of the ports were from about 20 days ago. Everything 
is installed the standard way.


Just if someone runs into these issues these may be found in the list 
(or already have been solved in ports) Things like this do not happen 
too often.


___
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: FreeBSD as VMWare guest / disk resizing

2012-12-18 Thread Lucian
On 18 December 2012 15:27, Devin Teske  wrote:
>
> On Dec 18, 2012, at 6:35 AM, Luke Bakken wrote:
> Live resize (without reboot even) is something being worked on for the future 
> 10.x series.

Looking forward to this, we can't offer cloud instances with FreeBSD
until this happens.
___
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"


mfsroot starts sysinstall how?

2012-12-18 Thread Rick Miller
Hi all,

For anyone interested, I posted a blog with regards to how sysinstall
is run from mfsroot.  URL is
http://blog.hostileadmin.com/2012/12/18/mfsroot-starts-sysinstall-how/

-- 
Take care
Rick Miller
___
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: FreeBSD as VMWare guest / disk resizing

2012-12-18 Thread Devin Teske

On Dec 18, 2012, at 6:35 AM, Luke Bakken wrote:

>> You'll of course need to boot from another medium to do this.
>> 
> 
> That's my main question - can a larger disk be detected *without* a
> reboot. On FreeBSD instances running within VMWare I have been able to
> add new disks without a reboot but, as I described below, have not
> found a way to get the operating system to detect a larger *existing*
> disk without a reboot. VMWare allows you to resize a disk on the fly.
> Obviously I'm only interested in the "grow the disk" scenario :-)
> 
> I'm beginning to think a reboot is necessary, which is surprising!

Live resize (without reboot even) is something being worked on for the future 
10.x series.
-- 
Devin


> 
>> On Dec 17, 2012, at 4:15 PM, Luke Bakken wrote:
>> 
>> Hello everyone -
>> 
>> I'm looking for a way to get FreeBSD 8 / 9 to detect that an already
>> existing disk has grown. I have FreeBSD running as a guest within
>> vSphere ESX 5. Here is the output of camcontrol showing how the disks
>> are detected within the OS:
>> 
>> [root@QA1HWFBSD83201 ~]# camcontrol inquiry da0
>> pass0:  Fixed Direct Access SCSI-2 device
>> pass0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Command
>> Queueing Enabled
>> 
>> In the VM settings I can increase the disk size but I can't seem to
>> find the right command within FreeBSD to force it to detect the new,
>> larger size without a reboot. 'camcontrol rescan all' works great to
>> detect a new drive but doesn't detect a larger disk. Within a Linux
>> distribution like Debian, the following command will detect the larger
>> drive:
>> 
>> echo 1 > /sys/class/scsi_device/0:0:0:0/device/rescan
>> 
>> I apologize if this has been answered in the archives or online but I
>> just haven't been able to get a definitive answer if this is possible,
>> and how.
>> 
>> Thanks so much in advance,
>> Luke
>> ___
>> 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"
>> 
>> 
>> _
>> The information contained in this message is proprietary and/or
>> confidential. If you are not the intended recipient, please: (i) delete the
>> message and all copies; (ii) do not disclose, distribute or use the message
>> in any manner; and (iii) notify the sender immediately. In addition, please
>> be aware that any message addressed to our domain is subject to archiving
>> and review by persons other than the intended recipient. Thank you.

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. 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: FreeBSD as VMWare guest / disk resizing

2012-12-18 Thread Warren Block

On Tue, 18 Dec 2012, Luke Bakken wrote:


You'll of course need to boot from another medium to do this.



That's my main question - can a larger disk be detected *without* a
reboot. On FreeBSD instances running within VMWare I have been able to
add new disks without a reboot but, as I described below, have not
found a way to get the operating system to detect a larger *existing*
disk without a reboot. VMWare allows you to resize a disk on the fly.
Obviously I'm only interested in the "grow the disk" scenario :-)


Force a GEOM retaste?

# true > /dev/ada0
___
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: FreeBSD as VMWare guest / disk resizing

2012-12-18 Thread Luke Bakken
> You'll of course need to boot from another medium to do this.
>

That's my main question - can a larger disk be detected *without* a
reboot. On FreeBSD instances running within VMWare I have been able to
add new disks without a reboot but, as I described below, have not
found a way to get the operating system to detect a larger *existing*
disk without a reboot. VMWare allows you to resize a disk on the fly.
Obviously I'm only interested in the "grow the disk" scenario :-)

I'm beginning to think a reboot is necessary, which is surprising!

> On Dec 17, 2012, at 4:15 PM, Luke Bakken wrote:
>
> Hello everyone -
>
> I'm looking for a way to get FreeBSD 8 / 9 to detect that an already
> existing disk has grown. I have FreeBSD running as a guest within
> vSphere ESX 5. Here is the output of camcontrol showing how the disks
> are detected within the OS:
>
> [root@QA1HWFBSD83201 ~]# camcontrol inquiry da0
> pass0:  Fixed Direct Access SCSI-2 device
> pass0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Command
> Queueing Enabled
>
> In the VM settings I can increase the disk size but I can't seem to
> find the right command within FreeBSD to force it to detect the new,
> larger size without a reboot. 'camcontrol rescan all' works great to
> detect a new drive but doesn't detect a larger disk. Within a Linux
> distribution like Debian, the following command will detect the larger
> drive:
>
> echo 1 > /sys/class/scsi_device/0:0:0:0/device/rescan
>
> I apologize if this has been answered in the archives or online but I
> just haven't been able to get a definitive answer if this is possible,
> and how.
>
> Thanks so much in advance,
> Luke
> ___
> 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"
>
>
> _
> The information contained in this message is proprietary and/or
> confidential. If you are not the intended recipient, please: (i) delete the
> message and all copies; (ii) do not disclose, distribute or use the message
> in any manner; and (iii) notify the sender immediately. In addition, please
> be aware that any message addressed to our domain is subject to archiving
> and review by persons other than the intended recipient. 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: i386 vs. amd64

2012-12-18 Thread Joseph A. Nagy, Jr

On 12/18/12 00:13, Erich Dollansky wrote:

Hi,

wasn't the same question here a few days ago?

On Tue, 18 Dec 2012 00:16:36 -0500
Aryeh Friedman  wrote:


Ever since 8.X (my system is now 9.1-RC3 [done via csup]) been using
i386 with the following main ports:


Let me chime in where Erich couldn't answer as I recently made the 
switch to amd64 myself.



x11-wm/xfce4


yes.


www/firefox


Yes.


www/linux-f10-flashplugin11


Yes


editors/libreoffice


Yes.


www/tomcat-7
www/apace22


Typo? Apache 2.2 runs.


devel/aegis (I am the maintainer)
devel/fhist
devel/cook
java/openjdk6


Yes



So I have the following questions:

1. Will all the above ports (and their dependencies) work on amd64?


I gave you the answer if I knew one. I general, I do not have problems
which are linked to 32 or 64 bits.


I've had no problems either, and I am in the middle of a devel/pcre 
rebuilding (over 200 ports).



2. Is there any way to do a in place switch to amd64 or do I need to
rebuild the system from the ground up?


To my knowledge, it is still a fresh installation. Just download an
image and start from there.


I think the handbook gives directions for an in-place switch, but it 
(and many, many others) suggest a fresh install, which is what I went 
with (I had other reasons as well).



3. In general is amd64 now as capable of handling ports and such as
well as i386 does?


I saw that some ports I used to use on i386 went 100% smooth on amd64.
I believe that this has improved even further.

Just make the jump.



I agree, I've had no problems related to the arch since I switched and 
would 100% recommend it for anyone considering it.


--
Yours in Christ,

Joseph A Nagy Jr
"Whoever loves instruction loves knowledge, But he who hates correction
is stupid." -- Proverbs 12:1
Emails are not formal business letters, whatever businesses may want.
Original content CopyFree (F) under the OWL http://owl.apotheon.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: Obsolete Shared Libraries?

2012-12-18 Thread Steve O'Hara-Smith
On Tue, 18 Dec 2012 12:40:39 + (UTC)
Walter Hurry  wrote:

> 9.1 RC3 (started out as 9.0 RELEASE)
> 
> Over time, as ports have been upgraded, I seem to have accumulated a 
> number of obsolete shared libraries - a recent example being /usr/local/
> lib/libpcre.so.1, which appears no longer to be linked in by anything, 
> having been replaced by libpcre.so.3.
> 
> Is there a convenient and safe utility to clean out this detritus? I'm 
> not trying to save disk space or anything; it's just a matter of tidiness.

portsclean - it will also tidy up distfiles, packages and work
areas.

-- 
Steve O'Hara-Smith 
___
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"


Obsolete Shared Libraries?

2012-12-18 Thread Walter Hurry
9.1 RC3 (started out as 9.0 RELEASE)

Over time, as ports have been upgraded, I seem to have accumulated a 
number of obsolete shared libraries - a recent example being /usr/local/
lib/libpcre.so.1, which appears no longer to be linked in by anything, 
having been replaced by libpcre.so.3.

Is there a convenient and safe utility to clean out this detritus? I'm 
not trying to save disk space or anything; it's just a matter of tidiness.

___
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"


resolvconf overwriting /etc/resolv.conf

2012-12-18 Thread Ruben de Groot

Hi,

I run bind on a LAN, with some LAN-only (sub)domains. On the LAN is also
a DSL modem/router that advertises ipv6 addresses. So far so good.
However, since I upgraded the server from 8-STABLE to 9.1-PRERELEASE,
the /etc/resolv.conf gets overwritten by the resolvconf script, with an
ipv6 nameserver (presumably the router, haven't checked). This is not 
what I want.

Now I see that you can prepend nameservers through /etc/resolvconf.conf,
but what I really want is for resolvconf to leave my /etc/resolv.conf
alone. Is there any way to disable the script (apart from deleting it)?

thanks,
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"