Re: one keydisk to access multiple encrypted systems

2012-08-25 Thread Aaron
On Aug 24, 2012 8:48 PM, "Erling Westenvik" 
wrote:
>
> According to http://www.undeadly.org/cgi?action=article&sid=20110530221728
> I've set up fully encrypted disk by using the bioctl(4) feature for
> specifying a key disk
>
>   # bioctl -C force -c C -l /dev/wd0d -k /dev/sd0d softraid0
>
> and it works perfectly. But, is it possible to use the same key disk for
> multiple systems, ie. using the same passphrase between them? The man
> page for bioctl(4) mentions a -P switch
>
>   -P  Change the passphrase on the selected crypto volume
>
> but its usage is unclear to me.

It is possible if you use different partitions on the same drive, however,
you would have to run -P twice ( once for each volume ).

>
> Regards,
> Erling



Re: one keydisk to access multiple encrypted systems

2012-08-25 Thread Erling Westenvik
On Sat, Aug 25, 2012 at 07:03:42AM -0600, Aaron wrote:
> 
> It is possible if you use different partitions on the same drive, however,
> you would have to run -P twice ( once for each volume ).
> 

Sorry for not mentioning that I'm aware about the possibility of having
several mini partitions on the key disk, one for each encrypted machine. 
Also, the -P switch in bioctl(4) has nothing to do with the creation of
a key disk since the passphrase is generated automatically when invoking

  # bioctl -C force -c C -l /dev/wd0d -k /dev/sd0d softraid0

What I'm looking for is a way to have only one key disk partition for
multiple machines. (Perhaps also a way to manually specify a passphrase
in case of a lost/forgotten key disk, or a way to create a new key disk
in case of a corrupted image. But I may be way out on this one..)



Re: one keydisk to access multiple encrypted systems

2012-08-25 Thread Aaron Bieber
On Sat, Aug 25, 2012 at 05:08:31PM +0200, Erling Westenvik wrote:
> On Sat, Aug 25, 2012 at 07:03:42AM -0600, Aaron wrote:
> > 
> > It is possible if you use different partitions on the same drive, however,
> > you would have to run -P twice ( once for each volume ).
> > 
> 
> Sorry for not mentioning that I'm aware about the possibility of having
> several mini partitions on the key disk, one for each encrypted machine. 

k

> Also, the -P switch in bioctl(4) has nothing to do with the creation of
> a key disk since the passphrase is generated automatically when invoking

I never intended to imply that -P had anything to do with creation.  I
simply meant that you would have to run bioctl with the -P option twice,
once for each partition when changing your passphrase.
> 
>   # bioctl -C force -c C -l /dev/wd0d -k /dev/sd0d softraid0
> 
> What I'm looking for is a way to have only one key disk partition for
> multiple machines. (Perhaps also a way to manually specify a passphrase
> in case of a lost/forgotten key disk, or a way to create a new key disk
> in case of a corrupted image. But I may be way out on this one..)
> 

One key disk for multiple machines is impossible from what I
understand. Passphrase fallback is also currently impossible. 

Creating a backup key disk can be done with dd: 

  dd if=/dev/rsd1c of=keydisk.img bs=1m

Restore with:

  dd if=keydisk.img of=/dev/rsd1c bs=1m



Re: one keydisk to access multiple encrypted systems

2012-08-25 Thread Erling Westenvik
On Sat, Aug 25, 2012 at 09:54:25AM -0600, Aaron Bieber wrote:
> I never intended to imply that -P had anything to do with creation.  I
> simply meant that you would have to run bioctl with the -P option twice,
> once for each partition when changing your passphrase.

Does that imply that one may change the passphrase to be the same on all
machines? Hence solving my question?



Re: one keydisk to access multiple encrypted systems

2012-08-25 Thread Aaron Bieber
On Sat, Aug 25, 2012 at 06:21:58PM +0200, Erling Westenvik wrote:
> On Sat, Aug 25, 2012 at 09:54:25AM -0600, Aaron Bieber wrote:
> > I never intended to imply that -P had anything to do with creation.  I
> > simply meant that you would have to run bioctl with the -P option twice,
> > once for each partition when changing your passphrase.
> 
> Does that imply that one may change the passphrase to be the same on all
> machines? Hence solving my question?
> 

Yes, you could use the same passphrase for different softraid volumes on
different machines.



More sensible and consistent rc.conf.local

2012-08-25 Thread Mikkel Bang
Hello!

Is there a way to make my rc.conf.local more sensible and consistent, i.e. not

pf=YES
sshd=""
named_flags=""

but rather

pf=YES
sshd=YES
named=YES?

Thanks!

Mikkel



Notebook dmesg gathering. Developers, what info do you want?

2012-08-25 Thread Dave Anderson
A year or so ago, as part of selecting a notebook to buy, I gathered
dmesg info from all of the notebooks I could find in local stores
(booting from and saving data to a USB stick) and sent it to
dm...@openbsd.org as well as using it myself.  Since I expect that it
would be useful to the developers to have this info for the current crop
of notebooks, I plan to do another data-gathering session sometime in
the next few weeks.  I'll be using an amd64 snapshot and, as FAQ 4.10
requests, will gather both 'dmesg' and 'sysctl hw.sensors' output using
both the sp and mp kernels for each system.

Since the data collection will be scripted it will be easy to also
gather other information; pcidump, usbdevs and acpidump come to mind.
What would be useful for the developers?  I've got a store which has
several dozen demo notebooks and will let me gather data from them, but
there won't be an opportunity to go back -- I need to get all of the
useful info at once.

So, my questions to the developers:

1) Does it matter which amd64 snapshot I use?  Are there any recent or
forthcoming ones which are especially good or bad for this purpose?

2) What additional information should I collect?  Exact commands and
options, please.  I don't mind installing tools which aren't in base,
but the output needs to go to, or be able to be redirected to, a file.

3) Other than the dmesg/sensor info which will go to dm...@openbsd.org,
where should I send the additional info?  If there's no suitable place,
I can just keep it around and let anyone who needs it ask me for it.

Dave

-- 
Dave Anderson




Re: More sensible and consistent rc.conf.local

2012-08-25 Thread Robert
On Sat, 25 Aug 2012 18:55:00 +0200
Mikkel Bang  wrote:
> Hello!
> 
> Is there a way to make my rc.conf.local more sensible and consistent, i.e. not
> 
> pf=YES
> sshd=""
> named_flags=""
> 
> but rather
> 
> pf=YES
> sshd=YES
> named=YES?
> 
> Thanks!
> 
> Mikkel
> 

pf doesn't have options for start up, but sshd and named have. The
current syntax is perfectly fine.

(For sake of the argument: pfctl has options, maybe they should be a
rc.conf option for it?)

kind regards,
Robert




Как защитить себя и свой бизнес от противоправных действий банка?

2012-08-25 Thread Юридическое противодействие банкам
Þðèäè÷åñêîå ïðîòèâîäåéñòâèå áàíêàì

Êàê çàùèòèòü ñåáÿ è ñâîé áèçíåñ îò ïðîòèâîïðàâíûõ äåéñòâèé áàíêà?
Êàê îñóùåñòâèòü ðàñòîðæåíèå êðåäèòà íà çàêîííûõ îñíîâàíèÿõ?
Êàê èçáåæàòü ñóäà ñ áàíêîì?
Êàê èçáåæàòü àðåñòà èìóùåñòâà?
Êàê ñîâåðøèòü âûâîä èç çàëîãà èìóùåñòâà?

 àäâîêàòñêîé êîìïàíèè Âàì ïîìîãóò â òàêèõ âîïðîñàõ, êàê:
Ðàñòîðæåíèå êðåäèòà (êðåäèòíûõ äîãîâîðîâ) íà çàêîííûõ îñíîâàíèÿõ;
Çàùèòà çàåìùèêîâ è ïîðó÷èòåëåé â ñóäàõ âñåõ èíñòàíöèé Óêðàèíû;
Çàùèòà çàëîãîâîãî èìóùåñòâà îò îò÷óæäåíèÿ;
Âûâîä èç çàëîãà èìóùåñòâà è àêòèâîâ çàåìùèêà;
Ïðèçíàíèå íåäåéñòâèòåëüíîé èñïîëíèòåëüíîé íàäïèñè íîòàðèóñà;
Ïîäà÷à àïåëëÿöèè ïî ðåøåíèþ ñóäà, íàïðàâëåííîìó ïðîòèâ Âàñ;
Çàòÿãèâàíèå ïðîöåññà âçûñêàíèÿ çàëîãà ïî ñóäåáíûì èñêàì îò áàíêîâ;

Ïîëíîå þðèäè÷åñêîå ñîïðîâîæäåíèå íà âñåõ ýòàïàõ ðåøåíèÿ ïðîáëåìû.

Áåñïëàòíàÿ ïåðâè÷íàÿ êîíñóëüòàöèÿ ñ äåòàëüíûì èçó÷åíèåì äîêóìåíòîâ ïî
âîçìîæíûì âàðèàíòàì â êàæäîì êîíêðåòíîì ñëó÷àå.

Íàøè êîíòàêòû:
O×× 219 11 74 Êèåâ
Êèåâñòàð0 98 846 76 5×

Î56 Ç72 83 87 Äíåïðîïåòðîâñê

Î48 73O 53 80 Îäåññà
ÌÒÑ0 95 21× 26 6Î

062 Ç32 Ç5 58 Äîíåöê
ÌÒÑo 99 362 5o 57



Re: More sensible and consistent rc.conf.local

2012-08-25 Thread Alexander Hall

On 08/25/12 21:08, Robert wrote:

On Sat, 25 Aug 2012 18:55:00 +0200
Mikkel Bang  wrote:

Hello!

Is there a way to make my rc.conf.local more sensible and consistent, i.e. not

pf=YES
sshd=""
named_flags=""

but rather

pf=YES



sshd=YES
named=YES?


You may still want to be able to pass special parameters to those.



Thanks!

Mikkel



pf doesn't have options for start up, but sshd and named have. The
current syntax is perfectly fine.

(For sake of the argument: pfctl has options, maybe they should be a
rc.conf option for it?)


pfctl is not a daemon per se, as opposed to e.g. smtpd or httpd.

As far as enabling pf and loading the ruleset, only a subset of the 
pfctl flags are of interest.


Therefore, there is $pf_rules, which is passed with -f to pfctl. Not 
sure what other options would be of use.


There are a few other special cases, such as $spamd_black, which could 
just as well have been configured in $spamd_flags, if it wasn't also 
used to determine whether we should also start spamlogd or not.




kind regards,
Robert




Re: Notebook dmesg gathering. Developers, what info do you want?

2012-08-25 Thread Brett
> 3) Other than the dmesg/sensor info which will go to dm...@openbsd.org,
> where should I send the additional info?  If there's no suitable place,
> I can just keep it around and let anyone who needs it ask me for it.
> 
>   Dave
> 


http://www.nycbug.org/?action=dmesgd&add=1



Re: More sensible and consistent rc.conf.local

2012-08-25 Thread Theo de Raadt
> > (For sake of the argument: pfctl has options, maybe they should be a
> > rc.conf option for it?)
> 
> pfctl is not a daemon per se, as opposed to e.g. smtpd or httpd.
> 
> As far as enabling pf and loading the ruleset, only a subset of the 
> pfctl flags are of interest.
> 
> Therefore, there is $pf_rules, which is passed with -f to pfctl. Not 
> sure what other options would be of use.
> 
> There are a few other special cases, such as $spamd_black, which could 
> just as well have been configured in $spamd_flags, if it wasn't also 
> used to determine whether we should also start spamlogd or not.

The support for options to pfctl was removed intentionally.

If you want to control what pf is doing, do it in the config file.

We removed pfctl options to force that.  It is good practice that
pf works the same if you forget to pass stupid options to it.



Re: Notebook dmesg gathering. Developers, what info do you want?

2012-08-25 Thread Dave Anderson
On Sun, 26 Aug 2012, Brett wrote:

>> 3) Other than the dmesg/sensor info which will go to dm...@openbsd.org,
>> where should I send the additional info?  If there's no suitable place,
>> I can just keep it around and let anyone who needs it ask me for it.
>
>http://www.nycbug.org/?action=dmesgd&add=1

Yes, I know about that site and intend to post the dmesg info there too
(as I did last year).  But my question was about what to do with any
non-dmesg info I capture (whatever the developers tell me might be
useful, perhaps acpidump, usbdevs, pcidump, ...).

Dave

-- 
Dave Anderson