Re: one keydisk to access multiple encrypted systems
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
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
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
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
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
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?
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
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
Как защитить себя и свой бизнес от противоправных действий банка?
Þðèäè÷åñêîå ïðîòèâîäåéñòâèå áàíêàì Êàê çàùèòèòü ñåáÿ è ñâîé áèçíåñ îò ïðîòèâîïðàâíûõ äåéñòâèé áàíêà? Êàê îñóùåñòâèòü ðàñòîðæåíèå êðåäèòà íà çàêîííûõ îñíîâàíèÿõ? Êàê èçáåæàòü ñóäà ñ áàíêîì? Êàê èçáåæàòü àðåñòà èìóùåñòâà? Êàê ñîâåðøèòü âûâîä èç çàëîãà èìóùåñòâà?  àäâîêàòñêîé êîìïàíèè Âàì ïîìîãóò â òàêèõ âîïðîñàõ, êàê: Ðàñòîðæåíèå êðåäèòà (êðåäèòíûõ äîãîâîðîâ) íà çàêîííûõ îñíîâàíèÿõ; Çàùèòà çàåìùèêîâ è ïîðó÷èòåëåé â ñóäàõ âñåõ èíñòàíöèé Óêðàèíû; Çàùèòà çàëîãîâîãî èìóùåñòâà îò îò÷óæäåíèÿ; Âûâîä èç çàëîãà èìóùåñòâà è àêòèâîâ çàåìùèêà; Ïðèçíàíèå íåäåéñòâèòåëüíîé èñïîëíèòåëüíîé íàäïèñè íîòàðèóñà; Ïîäà÷à àïåëëÿöèè ïî ðåøåíèþ ñóäà, íàïðàâëåííîìó ïðîòèâ Âàñ; Çàòÿãèâàíèå ïðîöåññà âçûñêàíèÿ çàëîãà ïî ñóäåáíûì èñêàì îò áàíêîâ; Ïîëíîå þðèäè÷åñêîå ñîïðîâîæäåíèå íà âñåõ ýòàïàõ ðåøåíèÿ ïðîáëåìû. Áåñïëàòíàÿ ïåðâè÷íàÿ êîíñóëüòàöèÿ ñ äåòàëüíûì èçó÷åíèåì äîêóìåíòîâ ïî âîçìîæíûì âàðèàíòàì â êàæäîì êîíêðåòíîì ñëó÷àå. Íàøè êîíòàêòû: 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
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?
> 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
> > (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?
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