Re: unnecessary quotes in .Nd lines
On Tue, Aug 13, 2013 at 05:30:37PM +0059, Jason McIntyre wrote: > On Mon, Aug 12, 2013 at 10:05:14PM +0200, Jan Stary wrote: > > Some manpages use one-line descriptions such as > > > > .Nd "VAX console interface" > > > > The double quotes, if I am not mistaken, are unnecessary; > > the diff below removes them throughout the tree. > > (Were these required at some point in the past?) > > > > the double quotes are from the past when groff macros could not handle > more than 9 args. we had to double quote wordy Nd lines. > > that's no longer an issue, right enough. i'll commit these when i can > grab some time. > > jmc now committed. jmc
Re: OpenBSD pxe automated install
- Original Message - | On Tue, Aug 13, 2013 at 9:48 AM, Marian Hettwer | wrote: | > Hi Loic, | > | > | > Am 13.08.13 15:43, schrieb � Blot: | > | >> Hello Marian, | >> i think you are right, because bsd.rd is required for last chance | >> to | >> repair system, among others. | >> | > | > right. And I'd like to leave it untouched. This hopefully also | > increases the | > possibility that whatever we come up with might get added | > upstream... ;) | | There's nothing preventing you from building your own installer | within | the RAMDISK kernel. I've done it in the past to handle some | personalized extensions. This isn't the point though. Debian, RedHat, Suse, all of these OSs include support for network installs by default, no customization of the installer required. OpenBSD does not, but it would be VERY nice if it did, even if it was just noting that it was PXE booting and should look at the location where it PXE booted (a mirror) and then looked for install.netboot for network boot instructions, fetched it and ran it. This wouldn't require any changes on behalf of an end user to make this process happen. If install.netboot doesn't exist, carry on with an interactive install, else fetch it and run it. No building of a custom RAMDISK required. | > I agree that the most pressing point is automatic network | > configuration in | > order to be able to download additional configs, like disk config, | > package | > config, ... | | It's doable within the base tools, if you assemble things correctly. | No reason to not have these stuff off of NFS or TFTP to pull in the | config. There is reason not to do this. HTTP based booting being one of them. VMs without NFS access being another. The complete inability to use NFS due to policy being another. I think the point is that the end user shouldn't have to build/modify the base installer to get this functionality. The diffs presented show that it could be possible and other OSs already offer this. Maybe not on the floppy disk versions but certainly the CD version should offer it. -- James A. Peltier Manager, IT Services - Research Computing Group Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : jpelt...@sfu.ca Website : http://www.sfu.ca/itservices “A successful person is one who can lay a solid foundation from the bricks others have thrown at them.” -David Brinkley via Luke Shaw
Use .Bx instead of BSD in manpages
The diff below replaces the occurences of "BSD" in the manpages with the .Bx macro where appropriate. (Some might be overkill though.) Specifically, it does not put .Bx inside .%T lines and the like, e.g. ".%T Design and Implementation of 4.4 BSD", as discussed off-list with jmc@ The following files /usr/src/lib/libc/sys/sigaction.2 /usr/src/share/man/man4/multicast.4 /usr/src/usr.bin/cvs/cvsintro.7 are left untouched because I am not sure what would be the best way to markup "BSD-derived" and similar. It unifies "BSD Authentication" and "BSD authentication" to .Bx Authentication - the capitalized form seemed to be in the majority (don't know why). crontab(5) says (BSD can't do this) which I rewrote as .Po .Bx can't do this .Pc but I don't think it's true; surely BSD can mail the result of a cronjob to the user. Also, it mentions "ATT" which I assumed was meant to be AT&T UNIX (and typed it as .At). Should factually .At also be the one that "can't do this" above? /usr/src/share/man/man7/mdoc.7 which describes .Bx and others does not itself use .Bx and others - for example, it says .Ss \&Bx Format the BSD version provided as an argument ... instead of .Ss \&Bx Format the .Bx version provided as an argument ... Is this on purpose? This replacement should probably be done for other system names as well (occurences of "BSD/OS" not done with .Bsx etc). Occasionaly, SunOS is mentioned which does not have its own macro. Would it make sense to have one? Similarly for HP-UX, IRIX ... Jan Index: bin/stty/stty.1 === RCS file: /cvs/src/bin/stty/stty.1,v retrieving revision 1.38 diff -u -p -u -p -r1.38 stty.1 --- bin/stty/stty.1 3 Sep 2011 22:59:08 - 1.38 +++ bin/stty/stty.1 13 Aug 2013 21:21:59 - @@ -66,7 +66,7 @@ as per .It Fl e Display all the current settings for the terminal to standard output in the traditional -.Tn BSD +.Bx .Dq all and .Dq everything Index: lib/libc/gen/auth_subr.3 === RCS file: /cvs/src/lib/libc/gen/auth_subr.3,v retrieving revision 1.20 diff -u -p -u -p -r1.20 auth_subr.3 --- lib/libc/gen/auth_subr.35 Jun 2013 03:39:22 - 1.20 +++ lib/libc/gen/auth_subr.313 Aug 2013 21:22:19 - @@ -104,14 +104,19 @@ .Ft void .Fn auth_setstate "auth_session_t *as" "int state" .Sh DESCRIPTION -These functions provide the lower level interface to the BSD +These functions provide the lower level interface to the +.Bx Authentication system. -They all operate on a BSD Authentication session pointer, +They all operate on a +.Bx +Authentication session pointer, .Fa as , which is returned by .Fn auth_open . The session pointer -must be passed to all other BSD Authentication functions called. +must be passed to all other +.Bx +Authentication functions called. The .Fn auth_open function returns @@ -173,9 +178,13 @@ is called. .Pp The remaining functions are described in alphabetical order. .Pp -The fundamental function for doing BSD Authentication is +The fundamental function for doing +.Bx +Authentication is .Fn auth_call . -In addition to the pointer to the BSD Authentication session, it takes +In addition to the pointer to the +.Bx +Authentication session, it takes the following parameters: .Bl -tag -width indent .It Ar path @@ -372,7 +381,9 @@ The latest challenge, if any, set for th The class of the user, as defined by the .Pa /etc/login.conf file. -This value is not directly used by BSD Authentication, rather, it is +This value is not directly used by +.Bx +Authentication, rather, it is passed to the login scripts for their possible use. .It Dv AUTH_INTERACTIVE If set to any value, then the session is tagged as interactive. Index: lib/libc/gen/authenticate.3 === RCS file: /cvs/src/lib/libc/gen/authenticate.3,v retrieving revision 1.14 diff -u -p -u -p -r1.14 authenticate.3 --- lib/libc/gen/authenticate.3 5 Jun 2013 03:39:22 - 1.14 +++ lib/libc/gen/authenticate.3 13 Aug 2013 21:22:19 - @@ -68,8 +68,9 @@ .Ft auth_session_t * .Fn auth_verify "auth_session_t *as" "char *style" "char *name" "..." .Sh DESCRIPTION -These functions provide a simplified interface to the BSD Authentication -system +These functions provide a simplified interface to the +.Bx +Authentication system .Pq see Xr bsd_auth 3 . The .Fn auth_userokay @@ -130,9 +131,13 @@ The .Fn auth_usercheck function operates the same as the .Fn auth_userokay -function except that it does not close the BSD Authentication session created. +function except that it does not close the +.Bx +Authentication session created. Rather than returning the status of the session, it returns -a pointer to the newly created BSD Authenticati
Re: ABI break - a question
Hi Janne!
Am 13.08.2013 15:35 schrieb Janne Johansson:
I don't think the upgrade will mess with files in /root ever, so it
should be as safe as /home/other-user.
Yes, I agree - but my question relates to a "fresh install" of the
system.
If you install-and-wipe-your-disks-accidentally I'd think /home is in
the same kind of danger.
Of course, you are quite right: "Accidentially" this can always happen
(and has happend to me before).
But as "Step 1" is for upgrading _and_ a fresh install my question
aimed at the less experienced who might feel that it is time to
reinstall. I just remembered one of the best advices the OpenBSD-FAQ has
to offer in http://www.openbsd.org/faq/faq4.html#Multibooting: "Note:
this is a really good time to remind you that blindly typing commands in
you don't understand is a really bad idea." :-)
All the best,
STEFAN
2013/8/13 Stefan Wollny
Hi there,
I usually follow -current installing snapshots as soon as they
become available.
Being just an ordinary though happy user I know OpenBSD is not for
the mindless and carefully check and read (and at least try to
understand) what is written on the wall on openbsd.org/faq/current
[1]. The latest entry and advice on the ABI break catched my
attention:
The first step is to save the info on the packages installed - but:
Is saving this info in /root a good idea when doing a fresh install?
Wouldn't /home/{user}/ be more advisable as /home should be on a
seperate partition not to be touched when mindfully doing a fresh
install as implicitly advised in step 3?
Just curious if I understood the advice - I do know how to do it.
I should not finish without a BIG THANKYOU to the devs!
Regards,
STEFAN
---
GnuPG-Key ID: 0x9C26F1D0
--
May the most significant bit of your life be positive.
Links:
--
[1] http://openbsd.org/faq/current
Re: OpenBSD pxe automated install
Hello James, you are right users may have choice. I'm working to build a distrib for pxebooting (pxeboot + bsd.rd generation). After i will try to implement those patches, which are very interesting for OpenBSD http://nbender.com/install.netboot/netboot.diff I only think we musnt't download a script and execute what it is on it. We must use variables to pass to already existing install script -- Best regards, Loïc BLOT, UNIX systems, security and network expert http://www.unix-experience.fr Le mardi 13 août 2013 à 14:16 -0700, James A. Peltier a écrit : > - Original Message - > | On Tue, Aug 13, 2013 at 9:48 AM, Marian Hettwer > | wrote: > | > Hi Loic, > | > > | > > | > Am 13.08.13 15:43, schrieb � Blot: > | > > | >> Hello Marian, > | >> i think you are right, because bsd.rd is required for last chance > | >> to > | >> repair system, among others. > | >> > | > > | > right. And I'd like to leave it untouched. This hopefully also > | > increases the > | > possibility that whatever we come up with might get added > | > upstream... ;) > | > | There's nothing preventing you from building your own installer > | within > | the RAMDISK kernel. I've done it in the past to handle some > | personalized extensions. > > This isn't the point though. Debian, RedHat, Suse, all of these OSs include support for network installs by default, no customization of the installer required. OpenBSD does not, but it would be VERY nice if it did, even if it was just noting that it was PXE booting and should look at the location where it PXE booted (a mirror) and then looked for install.netboot for network boot instructions, fetched it and ran it. This wouldn't require any changes on behalf of an end user to make this process happen. If install.netboot doesn't exist, carry on with an interactive install, else fetch it and run it. No building of a custom RAMDISK required. > > | > I agree that the most pressing point is automatic network > | > configuration in > | > order to be able to download additional configs, like disk config, > | > package > | > config, ... > | > | It's doable within the base tools, if you assemble things correctly. > | No reason to not have these stuff off of NFS or TFTP to pull in the > | config. > > There is reason not to do this. HTTP based booting being one of them. VMs without NFS access being another. The complete inability to use NFS due to policy being another. > > I think the point is that the end user shouldn't have to build/modify the base installer to get this functionality. The diffs presented show that it could be possible and other OSs already offer this. Maybe not on the floppy disk versions but certainly the CD version should offer it. [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: ESI Julia XTe soundcard
ESI Julia XTe places Envy24HT-S on PCIe via TENOR TE7009 PCI-to-PCIe bridge, which is transparent bridge. so, it should work right away, because PCIe-to-PCI conversion is entirely transparent from audio driver point of view - it will be recognized by the driver as ESI Julia on PCI, i.e. exactly like the old card. however, one potential problem (but it's very unlikely) is issues with PCIe-to-PCI chip in use in OpenBSD - i have such in the past, even though that was on different favor of *BSD, as well it was many years ago and it could be already fixed, but here is the old case for reference: http://lists.freebsd.org/pipermail/freebsd-drivers/2007-December/000584.html --konstantin On Tue, Aug 13, 2013 at 8:36 PM, Martijn Rijkeboer wrote: > Hi, > > According to the envy(4) manpage the ESI Julia is supported. Is the > ESI Julia XTe [1], which is the PCIe version of the Julia, known or expected > to work? > > Kind regards, > > > Martijn Rijkeboer > > > [1] http://www.esi-audio.com/products/juliaxte/
Re: OpenBSD pxe automated install
Hello Don, I haven't any problem with iPXE (used on my libvirt/KVM hypervisor). Yesterday i have booted on a pxelinux which chainload a OpenBSD pxeboot.0 (because i have made a menu for tests to choose automated debian install or OpenBSD. I will look at Nick's word tonight, but i think it's one very good way to do this. -- Best regards, Loïc BLOT, UNIX systems, security and network expert http://www.unix-experience.fr Le mardi 13 août 2013 à 10:05 -0700, Don Jackson a écrit : > On Aug 13, 2013, at 9:48 AM, Marian Hettwer wrote: > > > > I believe it's save to assume that a DHCP server is around, since this one > is needed anyways to pxeboot the box. > > So after the boot of our netboot.rd kernel, we need to figure out which > interface was used for pxe config and then do a dhclient on this interface. > > I thought Nick's work did much/all of this. > > > If we got an IP address, dhcp should probably give extra options, like the > config server url where we then can find and download the additional configs. > > > We could and probably should use DHCP options, since as stated above, dhcp > servers are available for the pxeboot anyways. > > Nick's work definitely did this. > > > Should we take this discussion off the list now? > > If so, who would like to be part of the next emails? > > I'd guess Loic, me, phessler (?), Nick Bender (?) and I will also add a > colleague some might know (Uwe Stuehler ). > > I would like to be included in any further discussion either at this email > address or don dot jackson at gmail > > Here are two additional links that provide historical context, and links to > past work: > > https://groups.google.com/d/topic/mailing.openbsd.tech/X01IcFJ0MVU/discussion > > https://groups.google.com/d/topic/mailing.openbsd.tech/h1-jrS36lqo/discussion > > And lastly, IMHO, optionally, it would be nice if the eventual solution was > capable of being pxebooted via > > iPXE - open source boot firmware [start] > > At present, I have not been able to get bsd.rd or any sort of OpenBSD > installer to run via ipxe > > Best regards, > > Don [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
ESI Julia XTe soundcard
Hi, According to the envy(4) manpage the ESI Julia is supported. Is the ESI Julia XTe [1], which is the PCIe version of the Julia, known or expected to work? Kind regards, Martijn Rijkeboer [1] http://www.esi-audio.com/products/juliaxte/
Re: OpenBSD pxe automated install
Am 13.08.2013 um 19:08 schrieb Johan Beisser : > On Tue, Aug 13, 2013 at 9:48 AM, Marian Hettwer wrote: >> Hi Loic, >> >> >> Am 13.08.13 15:43, schrieb � Blot: > >> >> PS.: personal opinion: I like FAI (www.fai.org) much more then debians >> preseed.cfg... check it out ;) > > http://fai-project.org/ is the correct URL. I've had some interesting > problems with FAI in the past. Once it's working, it's quite > wonderful. Oops. Sorry for taking the wrong URL... And thanks for correcting me :) Wrt fai and OpenBSD, I just like the concept of FAI. The several stages it uses. And everywhere one can hook in, if one needs something special. For instance are we using FAI to setup raid, do inventory run of new hardware or firmware upgrades of existing ones. For the latter too, FAI doesn't touch the disks... :)
Re: OpenBSD pxe automated install
On Tue, Aug 13, 2013 at 9:48 AM, Marian Hettwer wrote: > Hi Loic, > > > Am 13.08.13 15:43, schrieb � Blot: > >> Hello Marian, >> i think you are right, because bsd.rd is required for last chance to >> repair system, among others. >> > > right. And I'd like to leave it untouched. This hopefully also increases the > possibility that whatever we come up with might get added upstream... ;) There's nothing preventing you from building your own installer within the RAMDISK kernel. I've done it in the past to handle some personalized extensions. > I agree that the most pressing point is automatic network configuration in > order to be able to download additional configs, like disk config, package > config, ... It's doable within the base tools, if you assemble things correctly. No reason to not have these stuff off of NFS or TFTP to pull in the config. > > PS.: personal opinion: I like FAI (www.fai.org) much more then debians > preseed.cfg... check it out ;) http://fai-project.org/ is the correct URL. I've had some interesting problems with FAI in the past. Once it's working, it's quite wonderful.
Re: OpenBSD pxe automated install
On Aug 13, 2013, at 9:48 AM, Marian Hettwer wrote: > > I believe it's save to assume that a DHCP server is around, since this one is needed anyways to pxeboot the box. > So after the boot of our netboot.rd kernel, we need to figure out which interface was used for pxe config and then do a dhclient on this interface. I thought Nick's work did much/all of this. > If we got an IP address, dhcp should probably give extra options, like the config server url where we then can find and download the additional configs. > We could and probably should use DHCP options, since as stated above, dhcp servers are available for the pxeboot anyways. Nick's work definitely did this. > Should we take this discussion off the list now? > If so, who would like to be part of the next emails? > I'd guess Loic, me, phessler (?), Nick Bender (?) and I will also add a colleague some might know (Uwe Stuehler ). I would like to be included in any further discussion either at this email address or don dot jackson at gmail Here are two additional links that provide historical context, and links to past work: https://groups.google.com/d/topic/mailing.openbsd.tech/X01IcFJ0MVU/discussion https://groups.google.com/d/topic/mailing.openbsd.tech/h1-jrS36lqo/discussion And lastly, IMHO, optionally, it would be nice if the eventual solution was capable of being pxebooted via iPXE - open source boot firmware [start] At present, I have not been able to get bsd.rd or any sort of OpenBSD installer to run via ipxe Best regards, Don
Re: OpenBSD pxe automated install
Hi Loic, Am 13.08.13 15:43, schrieb � Blot: Hello Marian, i think you are right, because bsd.rd is required for last chance to repair system, among others. right. And I'd like to leave it untouched. This hopefully also increases the possibility that whatever we come up with might get added upstream... ;) My vision is to have a system like we have in debian, i think it's proper. In fact, the problem is not to modify the installer to use the configuration file, it's to setup network automaticly to get this file. On debian, URL is passed by a kernel variable on pxelinux (url=http/ftp/tftp://...). If we can pass this variable to OpenBSD boot.conf file (used for PXE), and setup URL + network method (we need to set the config URL, and network methods (iface + dhcp/static) to get this file), we can modify install script to use some obtained variabled, loaded into this file. Many people want this function, i think we must think together to see what everybody want. What do you think about my proposed method ? I agree that the most pressing point is automatic network configuration in order to be able to download additional configs, like disk config, package config, ... I believe it's save to assume that a DHCP server is around, since this one is needed anyways to pxeboot the box. So after the boot of our netboot.rd kernel, we need to figure out which interface was used for pxe config and then do a dhclient on this interface. IIRC detection of available NICs is part of install.sub, so we might just use that routine. If we got an IP address, dhcp should probably give extra options, like the config server url where we then can find and download the additional configs. From there it should be easy to do the fully automated installation. After that, before the reboot we might want to be able to set up things like: - serial console - some default/random root pw - some root ssh key - maybe additional packages (like puppet) then reboot. We can also pass config file by DHCP (string record ?) or DNS (special TXT record ?) but it's not really automated because it doesn't resolve the networking connection problem. We could and probably should use DHCP options, since as stated above, dhcp servers are available for the pxeboot anyways. Should we take this discussion off the list now? If so, who would like to be part of the next emails? I'd guess Loic, me, phessler (?), Nick Bender (?) and I will also add a colleague some might know (Uwe Stuehler ). Cheers, ./Marian PS.: personal opinion: I like FAI (www.fai.org) much more then debians preseed.cfg... check it out ;)
Re: unnecessary quotes in .Nd lines
On Tue, Aug 13, 2013 at 06:37:48PM +0200, Jan Stary wrote: > On Aug 13 17:30:37, j...@kerhand.co.uk wrote: > > On Mon, Aug 12, 2013 at 10:05:14PM +0200, Jan Stary wrote: > > > Some manpages use one-line descriptions such as > > > > > > .Nd "VAX console interface" > > > > > > The double quotes, if I am not mistaken, are unnecessary; > > > the diff below removes them throughout the tree. > > > (Were these required at some point in the past?) > > > > > > > the double quotes are from the past when groff macros could not handle > > more than 9 args. we had to double quote wordy Nd lines. > > Thanks for the insight. > > There seems to be more, in .%T lines and elsewhere; > more of these removals later. > there will be. and then of course this stuff gets copied and pasted everywhere, even when it's not needed. jmc
Re: unnecessary quotes in .Nd lines
On Aug 13 17:30:37, j...@kerhand.co.uk wrote: > On Mon, Aug 12, 2013 at 10:05:14PM +0200, Jan Stary wrote: > > Some manpages use one-line descriptions such as > > > > .Nd "VAX console interface" > > > > The double quotes, if I am not mistaken, are unnecessary; > > the diff below removes them throughout the tree. > > (Were these required at some point in the past?) > > > > the double quotes are from the past when groff macros could not handle > more than 9 args. we had to double quote wordy Nd lines. Thanks for the insight. There seems to be more, in .%T lines and elsewhere; more of these removals later.
Re: unnecessary quotes in .Nd lines
On Mon, Aug 12, 2013 at 10:05:14PM +0200, Jan Stary wrote: > Some manpages use one-line descriptions such as > > .Nd "VAX console interface" > > The double quotes, if I am not mistaken, are unnecessary; > the diff below removes them throughout the tree. > (Were these required at some point in the past?) > the double quotes are from the past when groff macros could not handle more than 9 args. we had to double quote wordy Nd lines. that's no longer an issue, right enough. i'll commit these when i can grab some time. jmc
Re: infnan.3 not installed
On Tue, Aug 13, 2013 at 06:13:25PM +0200, Jan Stary wrote: > We have /usr/src/lib/libm/man/infnan.3 > but infnan(3) doesn't seem to be installed > on any system I looked at. Is that intended? > > Jan > man -k should give you a clue... jmc
infnan.3 not installed
We have /usr/src/lib/libm/man/infnan.3 but infnan(3) doesn't seem to be installed on any system I looked at. Is that intended? Jan
Re: remove .Tn abuse
This diff removes .Tn abuse from usr.sbin - more to come.
I am not sure about /usr/src/usr.sbin/dev_mkdb/dev_mkdb.8
where I removed the .Tn's from
Keys are a structure containing a
.Tn mode_t
followed by a
.Tn dev_t ,
(as these are clearly not "tradenames") -
but maybe we have a macro for defined structures
such as mode_t and dev_t?
On the other hand, I added some ".Tn Sun Microsystems";
and also corrected some typos and inconsistencies.
Jan
Index: amd/amd/amd.8
===
RCS file: /cvs/src/usr.sbin/amd/amd/amd.8,v
retrieving revision 1.22
diff -u -p -u -p -r1.22 amd.8
--- amd/amd/amd.8 16 Jul 2013 11:13:33 - 1.22
+++ amd/amd/amd.8 13 Aug 2013 15:50:00 -
@@ -68,8 +68,7 @@ appear to be quiescent.
.Pp
.Nm amd
operates by attaching itself as an
-.Tn NFS
-server to each of the specified
+NFS server to each of the specified
.Ar directories .
Lookups within the specified directories
are handled by
@@ -155,8 +154,7 @@ it.
Specify the
.Ar interval ,
in tenths of a second, between
-.Tn NFS/RPC/UDP
-retries.
+NFS/RPC/UDP retries.
The default is 0.8 seconds.
The second value alters the retransmit counter.
Useful defaults are supplied if either or both
@@ -175,14 +173,10 @@ Specify run-time logging options.
The options are a comma separated
list chosen from: fatal, error, user, warn, info, map, stats, all.
.It Fl y Ar YP-domain
-Specify an alternative
-.Tn NIS
-domain from which to fetch the
-.Tn NIS
-maps.
+Specify an alternative NIS domain
+from which to fetch the NIS maps.
The default is the system domain name.
-This option is ignored if
-.Tn NIS
+This option is ignored if NIS
support is not available.
This variable is available inside the configuration file as
.Va ${domain} .
@@ -214,20 +208,14 @@ Department of Computing, Imperial Colleg
.Sh CAVEATS
Some care may be required when creating a mount map.
.Pp
-Symbolic links on an
-.Tn NFS
+Symbolic links on an NFS
filesystem can be incredibly inefficient.
-In most implementations of
-.Tn NFS ,
+In most implementations of NFS,
their interpolations are not cached by
the kernel and each time a symbolic link is
encountered during a
.Em lookuppn
-translation it costs an
-.Tn RPC
-call to the
-.Tn NFS
-server.
+translation it costs an RPC call to the NFS server.
A large improvement in real-time
performance could be gained by adding a cache somewhere.
Replacing
Index: amd/amq/amq.8
===
RCS file: /cvs/src/usr.sbin/amd/amq/amq.8,v
retrieving revision 1.13
diff -u -p -u -p -r1.13 amq.8
--- amd/amq/amq.8 16 Jul 2013 11:13:33 - 1.13
+++ amd/amq/amq.8 13 Aug 2013 15:50:00 -
@@ -51,8 +51,7 @@
provides a simple way of determining the current state of the
.Xr amd 8
program.
-Communication is by
-.Tn RPC .
+Communication is by RPC.
Three modes of operation are supported by the current protocol.
By default a list of mount points and auto-mounted filesystems
is output.
@@ -71,10 +70,8 @@ Request automounter to flush the interna
Query alternate host
.Ar hostname .
By default the local host is used.
-In an
-.Tn HP-UX
-cluster, the root server is queried by default, since
-that is the system on which the automounter is normally run.
+In an HP-UX cluster, the root server is queried by default,
+since that is the system on which the automounter is normally run.
.It Fl m
Request the automounter to provide a list of mounted filesystems,
including the number of references to each filesystem and any error
@@ -101,8 +98,7 @@ option.
.Sh FILES
.Bl -tag -width amq.x -compact
.It Pa amq.x
-.Tn RPC
-protocol description
+RPC protocol description
.El
.Sh SEE ALSO
.Xr amd 8
@@ -114,9 +110,9 @@ Department of Computing, Imperial Colleg
.\" .At
.Sh CAVEATS
.Nm amq
-uses a Sun registered
-.Tn RPC
-program number (300019 decimal) which may not
-be in the
+uses a
+.Tn Sun
+registered RPC program number (300019 decimal)
+which may not be in the
.Pa /etc/rpc
database.
Index: dev_mkdb/dev_mkdb.8
===
RCS file: /cvs/src/usr.sbin/dev_mkdb/dev_mkdb.8,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 dev_mkdb.8
--- dev_mkdb/dev_mkdb.8 31 May 2007 19:20:23 - 1.6
+++ dev_mkdb/dev_mkdb.8 13 Aug 2013 15:50:01 -
@@ -52,10 +52,7 @@ directory, using the file type and the
.Va st_rdev
field as the key.
.Pp
-Keys are a structure containing a
-.Tn mode_t
-followed by a
-.Tn dev_t ,
+Keys are a structure containing a mode_t followed by a dev_t,
with any padding zeroed out.
The former is the type of the file
.Pq st_mode & S_IFMT ,
Index: dhcpd/dhcp-options.5
===
RCS file: /cvs/src/usr.sbin/dhcpd/dhcp-options.5,v
retrieving revision 1.17
diff -u -p -u -p -r1.17 dhcp-options.5
--- dhcpd/dhcp-options.516 Jul
remove entry from spamdb greylist
Hello, I am using spamd in greylisting mode and would like to delete the following entry: GREY|207.126.144.121|eu1sys200aog106.obsmtp.com|||1376398715|1376400232|1376413115|4|0 I tried the following command: spamdb -d 207.126.144.121 Unfortunately it does not remove the entry as it is still there. Any ideas what could be wrong? Regards, M.L.
Re: Man page that explains the file format of man pages?
Extended Backus-Naur Form! That is exactly what I was looking for Andreas. Thank you. I really didn't know what this was called or if there was a formal definition or not. Lol, the wikipedia page says that it does not have a single dialect. The IEEE standard is a good reference for quirks of the unix usage of EBNF. I think that if one starts with the wikipedia page and gets the basics and then can use the IEEE 1003.1 ch. 12 Errata page it's actually pretty clear. Thank you again! Evan Root, CCNA 505.226.1319 On Tue, Aug 13, 2013 at 1:40 AM, Andres Perera wrote: > he's not talking about the source level mandoc/man macros > > the subject is about the SYNOPSIS section language for utilities > > e.g. > > in ``grep [ file ]'' the [ ] operator signifies 0 or 1 > > in ``rm file...'' the ... operator signifies 1 or more > > > On Tue, Aug 13, 2013 at 2:58 AM, Jan Stary wrote: > >> On Mon, Aug 12, 2013 at 9:21 PM, Anthony J. Bentley >wrote: > >> > Evan Root writes: > >> > > Hello Misc, > >> > > I tried man 5 man for an explanation of the synopsis section of the > man > >> > > page and it says there isn't a manual for the file format > conventions of > >> > > manual pages. Sometimes I have difficulty with the syntax of the > synopsis > >> > > sections, is there a document I can refer to? > >> > > >> > OpenBSD manuals are written in the mdoc macro language. There is a > page > >> > describing it, in section 7 (not 5). It is mentioned in the "SEE ALSO" > >> > section of man(1). > >> > > >> > man 7 mdoc > >> > > >> > There is also a man(7) page, describing the older "man" macros, but > these > >> > are not used for new manuals in OpenBSD. mdoc has the advantage of > being > >> > a semantic format, unlike the old man language where the commands > mostly > >> > change only the presentation. > > > > On Aug 12 22:19:58, cellarr...@gmail.com wrote: > >> I don't think you understood. I am not looking to write a man page. I > was > >> just wondering if the system came with an explanation of the manual page > >> synopsis section language syntax. > > > > Which is exactly what Anthony pointed you to: > > The mdoc(7) describes the language syntax in great detail. > > > >> Sometimes I get confused by the language > >> and am not sure if I understand the synopsis sections of the man pages. > >> Also I am concerned that people who I might recommend OpenBSD to will > find > >> that an undocumented part of the system is the man pages. > > > > The mandoc people could probably take this as an offence. > > The manual system, as other parts of OpenBSD, is thoroughly documented. > > > >> Even the welcome message from Theo says "This message attempts to > describe > >> the most basic initial questions that a > >> system administrator of an OpenBSD box might have. If you are not > >> familiar with how to read man pages, type > >> "man man" at a shell prompt and read the entire thing." > > > > Well have you? That points you to mdoc(7) in SEE ALSO. > > > > "How to read man pages" in the welcome message refers > > to the the rendered manpages - as presented to the user with man(1). > > You are asking about the language syntax - how the manpages are written. > > > >> I think that this post on stack exchange presents my question better.. > the > >> answers are all pretty short and non-committal though. > >> > http://stackoverflow.com/questions/8716047/is-there-a-specification-for-a-man-pages-synopsis-section > > > > So you _are_ looking to write a manpage; > > mdoc(7) has a section called "MANUAL STRUCTURE" > > with a subsection called "SYNOPIS". Have you missed it? > > > > After you write it, don't forget to 'mandoc -Tlint'.
Re: OpenBSD pxe automated install
On Tue, Aug 13, 2013 at 6:45 AM, Jiri B wrote: > On Tue, Aug 13, 2013 at 02:38:36PM +0200, Peter Hessler wrote: > > On 2013 Aug 13 (Tue) at 14:27:40 +0200 (+0200), Marian Hettwer wrote: > > :Looks like it's time to do this. And maybe I can sync up with some > > :others in this thread and we could work together. > > > > I'm looking at the diffs originally from Nick Bender (links are earlier > > in the thread), and will try to review and work this in. I and some > > other developers want this for our own projects as well. > > Wouldn't be better to work on install.sub[1] and also maybe to > move networking setup more in the beginning of install process > so one could download some setup script from network? > > [1] > http://www.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub?rev=1.683 > > jirib > > Redux is mostly a set of patches against the standard install scripts ( http://hiqu.biz/redux). I'm not apposed to doing more work on it if there is interest...
Re: ABI break - a question
On 08/13/2013 08:33 AM, Stefan Wollny wrote:
Hi there,
I usually follow -current installing snapshots as soon as they become
available.
Being just an ordinary though happy user I know OpenBSD is not for
the mindless and carefully check and read (and at least try to
understand) what is written on the wall on openbsd.org/faq/current.
The latest entry and advice on the ABI break catched my attention:
The first step is to save the info on the packages installed - but:
Is saving this info in /root a good idea when doing a fresh install?
Wouldn't /home/{user}/ be more advisable as /home should be on a
seperate partition not to be touched when mindfully doing a fresh
install as implicitly advised in step 3?
Just curious if I understood the advice - I do know how to do it.
IF you are doing a FRESH INSTALL, then yes, you want to put the package
list "elsewhere" other than /root. Probably on another machine.
But I think you misunderstand -- the primary thrust of the article is
for UPGRADING an existing system. If you are completely rebuilding from
scratch, you don't have much to worry about (except, perhaps, blindly
restoring binary or password files from backup!). I don't see the
"implicit advice" to do a fresh install of the entire system over an
upgrade.
Nick.
Re: OpenBSD pxe automated install
Hello Marian, i think you are right, because bsd.rd is required for last chance to repair system, among others. My vision is to have a system like we have in debian, i think it's proper. In fact, the problem is not to modify the installer to use the configuration file, it's to setup network automaticly to get this file. On debian, URL is passed by a kernel variable on pxelinux (url=http/ftp/tftp://...). If we can pass this variable to OpenBSD boot.conf file (used for PXE), and setup URL + network method (we need to set the config URL, and network methods (iface + dhcp/static) to get this file), we can modify install script to use some obtained variabled, loaded into this file. Many people want this function, i think we must think together to see what everybody want. What do you think about my proposed method ? We can also pass config file by DHCP (string record ?) or DNS (special TXT record ?) but it's not really automated because it doesn't resolve the networking connection problem. -- Best regards, Loïc BLOT, Engineering UNIX Systems, Security and Networks http://www.unix-experience.fr Le mardi 13 août 2013 à 13:09 +0200, Marian Hettwer a écrit : > Hi loic, > > > Sorry for top posting. > I need exactly the same for OpenBSD. Maybe we could work together... > In my example all I need on top of it is some same network config and > a first puppet run after reboot... > But I hesitated to modify bsd.rd... > Maybe it's more wise to create a "netboot.rd" and let bsd.rd alone. > > > A starting point could be http://www.hiqu.biz/redux > > > PM me if you have interest to work together with me :-) > > > Cheers > Marian > > -- > sent via my mobile C64 > > Am 13.08.2013 um 08:37 schrieb Loïc BLOT > : > > > > Hello Tito, > > thanks to give me another time the FAQ, you think i have never read. > > This boot process is okay for me but the problem is NOT the PXE boot > > process. The problem is to automate the installation. > > My OpenBSD pxeboot is chained after a pxelinux which already deserve > > automated installed debian. Now the goal is to deserve automated > > installed OpenBSD. > > > > I don't know if i don't choose the rights words to explain my need, > > or > > if nobody read all my answers to already answered questions... but i > > give a list of precision for future answers: > > > > 1. My problem is NOT PXE boot > > (http://www.openbsd.org/faq/faq6.html#PXE > > => NO) > > 2. My problem is NOT siteXX.tgz and customized installations with > > this > > mean (http://openbsd.org/faq/faq4.html#site => NO) > > 3. What i want is something like this: > > https://wiki.debian.org/DebianInstaller/Preseed or this > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5 > > /html/Installation_Guide/ch-kickstart2.html > > > > Then i ask @misc to know if an existing process exists, but now i > > think > > this doesn't exist and i must create a special bsd.rd PXE to do this > > (and share it to OpenBSD community, it will be great for deploy > > OpenBSD > > on several machines without doing anything. > > > > Have a nice day :) > > > > -- > > Best regards, > > Loïc BLOT, > > UNIX systems, security and network expert > > http://www.unix-experience.fr > > > > > > Le mardi 13 août 2013 à 06:29 +0800, Tito Mari Francis Escaño a > > écrit : > > > Please read http://www.openbsd.org/faq/faq6.html#PXE and hope this > > > helps. You'd have been told with deliberately unpleasant choice of > > > words if next time you don't research well before asking in the > > > list. > > > > > > > > > > > > On Tue, Aug 13, 2013 at 4:57 AM, Loïc BLOT > > > wrote: > > >Thanks for the precision James, you confirmed what i have > > >understood. > > >I will search tomorrow. > > >-- > > >Best regards, > > >Loïc BLOT, > > >UNIX systems, security and network expert > > >http://www.unix-experience.fr > > > > > > > > > > > >Le lundi 12 août 2013 à 12:23 -0700, James A. Peltier a > > >écrit : > > > > - Original Message - > > > > | read the FAQ, Loic. > > > > | > > > > | http://openbsd.org/faq/faq4.html#site > > > > | > > > > | Site*.tgz, install.site and upgrade.site are a good > > >starting point. > > > > | > > > > | On Mon, Aug 12, 2013 at 11:59 AM, Loïc BLOT > > > > | wrote: > > > > | > Hello @misc. > > > > | > > > > > | > Today i'm working on automated deploy with PXE. I have > > >successful > > > > | > found > > > > | > and made automated PXE install on Debian with pxelinux. > > > > | > > > > > | > I know OpenBSD have a pxe boot image to netinstall the > > >system > > > > | > > > > > > http://www.cyberciti.biz/faq/openbsd-boot-install-using-pxe-preboot-execution > > > > | > -environment/ > > > > | > > > > > | > Is there any options to automate the installation ? > > > > | > I want a machine to boot on bsd.rd, read a configuration > > >file (url > > > > | > passed by etc/boot.co
Re: ABI break - a question
I don't think the upgrade will mess with files in /root ever, so it should
be as safe as /home/other-user.
If you install-and-wipe-your-disks-accidentally I'd think /home is in the
same kind of danger.
2013/8/13 Stefan Wollny
> Hi there,
>
> I usually follow -current installing snapshots as soon as they become
> available.
>
> Being just an ordinary though happy user I know OpenBSD is not for the
> mindless and carefully check and read (and at least try to understand) what
> is written on the wall on openbsd.org/faq/current. The latest entry and
> advice on the ABI break catched my attention:
> The first step is to save the info on the packages installed - but: Is
> saving this info in /root a good idea when doing a fresh install? Wouldn't
> /home/{user}/ be more advisable as /home should be on a seperate partition
> not to be touched when mindfully doing a fresh install as implicitly
> advised in step 3?
>
> Just curious if I understood the advice - I do know how to do it.
>
> I should not finish without a BIG THANKYOU to the devs!
>
> Regards,
> STEFAN
>
> ---
> GnuPG-Key ID: 0x9C26F1D0
>
>
--
May the most significant bit of your life be positive.
Re: npppd sessions log
It was my fault. I started "npppd -d" (for test only), so logs went to stdout and there was nothing in /var/log/*. If I start it as a daemon, session logs go to /var/log/daemon and /var/log/messages. >I do accounting, as well as authentication, by help of radius server. VPN with RADIUS - it's in my TODO list. Thanks! On Tue, 13 Aug 2013 07:33:20 -0500 Vijay Sankar wrote: > Quoting Radek : > > > Hi @misc, > > > > I can't find any way/option to log npppd sessions on a VPN gateway. > > What I need to log: > > - username > > - user's source_IP > > - user's VPN_internal_IP > > - session start_time > > - session end_time > > > > Current npppd sessions I can see via "npppctl session all/brief" but > > I need a history log. > > > > Thanks for help, > > Radek > > > > > > /var/log/messages or /var/log/daemon has all those details. > > > > Vijay Sankar, M.Eng., P.Eng. > ForeTell Technologies Limited > vsan...@foretell.ca > > - > This message was sent using ForeTell-POST 4.9 > > Radek
Re: OpenBSD pxe automated install
On Tue, Aug 13, 2013 at 01:07:29PM +0100, Andy wrote: > Hi +1 > We need this too! > > We need a fully automated OpenBSD install including partitioning > etc, as we need to do installs on sites where an engineer cannot go > (cheaply). Hi. In the company I work for (M:Tier), we do fully automated OpenBSD installations on servers, appliances and workstations. We use a modified bsd.rd kernel for that. Then at the very end, a puppet client is run to handle post-installation tasks (although that part can obviously be done by other means). Cheers! -- Antoine
Re: npppd sessions log
On Tue, 13 Aug 2013 14:24:49 +0200 Radek wrote: > Hi @misc, > > I can't find any way/option to log npppd sessions on a VPN gateway. > What I need to log: > - username > - user's source_IP > - user's VPN_internal_IP > - session start_time > - session end_time I do accounting, as well as authentication, by help of radius server. -- Marko Cupać
Re: OpenBSD pxe automated install
On Tue, Aug 13, 2013 at 02:38:36PM +0200, Peter Hessler wrote: > On 2013 Aug 13 (Tue) at 14:27:40 +0200 (+0200), Marian Hettwer wrote: > :Looks like it's time to do this. And maybe I can sync up with some > :others in this thread and we could work together. > > I'm looking at the diffs originally from Nick Bender (links are earlier > in the thread), and will try to review and work this in. I and some > other developers want this for our own projects as well. Wouldn't be better to work on install.sub[1] and also maybe to move networking setup more in the beginning of install process so one could download some setup script from network? [1] http://www.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub?rev=1.683 jirib
Re: OpenBSD pxe automated install
On 2013 Aug 13 (Tue) at 14:27:40 +0200 (+0200), Marian Hettwer wrote: :Looks like it's time to do this. And maybe I can sync up with some :others in this thread and we could work together. I'm looking at the diffs originally from Nick Bender (links are earlier in the thread), and will try to review and work this in. I and some other developers want this for our own projects as well. -- Admiration, n.: Our polite recognition of another's resemblance to ourselves. -- Ambrose Bierce, "The Devil's Dictionary"
ABI break - a question
Hi there,
I usually follow -current installing snapshots as soon as they become available.
Being just an ordinary though happy user I know OpenBSD is not for the mindless
and carefully check and read (and at least try to understand) what is written
on the wall on openbsd.org/faq/current. The latest entry and advice on the ABI
break catched my attention:
The first step is to save the info on the packages installed - but: Is saving
this info in /root a good idea when doing a fresh install? Wouldn't
/home/{user}/ be more advisable as /home should be on a seperate partition not
to be touched when mindfully doing a fresh install as implicitly advised in
step 3?
Just curious if I understood the advice - I do know how to do it.
I should not finish without a BIG THANKYOU to the devs!
Regards,
STEFAN
---
GnuPG-Key ID: 0x9C26F1D0
Re: npppd sessions log
Quoting Radek : Hi @misc, I can't find any way/option to log npppd sessions on a VPN gateway. What I need to log: - username - user's source_IP - user's VPN_internal_IP - session start_time - session end_time Current npppd sessions I can see via "npppctl session all/brief" but I need a history log. Thanks for help, Radek /var/log/messages or /var/log/daemon has all those details. Vijay Sankar, M.Eng., P.Eng. ForeTell Technologies Limited vsan...@foretell.ca - This message was sent using ForeTell-POST 4.9
Re: OpenBSD pxe automated install
Hi Nick, well, obviously you have a different opinion on automated installations. For me it's even crucial with just 10 boxes. I'm taking into account that I want to introduce more OpenBSD installations at work and that I also need to install QA environments. All of our infrastructure (2000+ servers) are fully automated installable. The lack of doing the same with OpenBSD is one reason to not introduce more OpenBSD installations. Long story short, your opinion on this topic differs to mine. Between OpenBSD 4.7 and 5.1 I had my own set of install scripts but I never came around to actually modify bsd.rd, or rather build my own one which starts the installation automatically. Looks like it's time to do this. And maybe I can sync up with some others in this thread and we could work together. Cheers, Marian PS.: For the interested reader, I always liked FAI for debian. My first scripted OpenBSD install was based on that. Am 13.08.13 13:52, schrieb Nick Holland: On 08/13/13 07:13, Marian Hettwer wrote: ... This is sad :-/ For any mass deployment I need this... I was okay with doing it semi automated for the first three boxes at work. But nowadays it's 10 boxes and we are going for full automation. Hm hm... Marian ten boxes. Um. Lets see. An OpenBSD install takes less than ten minutes (assuming small file systems. Yes the newfs step can take a while on big file systems). You can also do several installs at the same time. So you are trying to save at most 100 minutes. dang, I'm gonna spend much of that telling you how to do it. Sounds like you are about to spend a few weeks trying to save a few minutes. Do you think you can write some custom build scripting system in under two hours? Do you think you can LEARN a custom building system in under two hours? This isn't a long, painful, massively interactive Linux or Solaris install, your return on investment of time here is not going to come in 10 boxes. I doubt it would be there for 100 boxes (if you include the setup and infrastructure). Keep in mind, the OpenBSD install process is fairly simple. 1: (assuming appropriate) create fdisk partition. Most common case can be done on the command line. 2: disklabel (can be scripted; see softraid(4) man page. can also use a pre-defined template file, and "predefined" means "before running disklabel"). 3: newfs all partitions 4: mount 'em somewhere, presumably hanging off /mnt 5: untar all desired file sets 6: record a few key config files (network, machine name, etc.) 6a: might as well add your admin users? 7: MAKEDEV all 8: install boot loader (I probably forgot something. that was all from early morning memory) This is all easily scriptable. So, if you can define your task appropriately, you can write an install script, stick it in your own bsd.rd (yes, you will name it something other than bsd.rd) or build a install kernel which fetches the script from a master install server, and away you go. I can't get too excited about this, as your bulk install needs are probably very different than mine, and the marginal time savings per machine are going to be small. Nick.
npppd sessions log
Hi @misc, I can't find any way/option to log npppd sessions on a VPN gateway. What I need to log: - username - user's source_IP - user's VPN_internal_IP - session start_time - session end_time Current npppd sessions I can see via "npppctl session all/brief" but I need a history log. Thanks for help, Radek
Re: OpenBSD pxe automated install
On Tue, Aug 13, 2013 at 07:52:02AM -0400, Nick Holland wrote: > Lets see. An OpenBSD install takes less than ten minutes (assuming > small file systems. Yes the newfs step can take a while on big file > systems). You can also do several installs at the same time. So you > are trying to save at most 100 minutes. dang, I'm gonna spend much of > that telling you how to do it. Sounds like you are about to spend a few > weeks trying to save a few minutes. A bit OT, maybe, but couldn't help it: http://xkcd.com/1205/ (I definitely should look at this chart more often...) --
Re: OpenBSD pxe automated install
Hi +1 We need this too! We need a fully automated OpenBSD install including partitioning etc, as we need to do installs on sites where an engineer cannot go (cheaply). I know the dev work is more than 2 hours.. Obviously.. But their are tens of thousands of OpenBSD users with /many/ servers each out there who would use this and collectively could save hundreds and hundreds and hundreds of hours by being able to have automated deploys. BUT, that said, looking at the bigger picture.. for the limited OpenBSD developers I would rather they spent their time on removing the GIANT kernel lock, and reworking ALTQ and PF to name our worst and most serious pain points than have them work on stuff that we can easily 'work around'.. :) Andy On Tue 13 Aug 2013 12:52:02 BST, Nick Holland wrote: On 08/13/13 07:13, Marian Hettwer wrote: ... This is sad :-/ For any mass deployment I need this... I was okay with doing it semi automated for the first three boxes at work. But nowadays it's 10 boxes and we are going for full automation. Hm hm... Marian ten boxes. Um. Lets see. An OpenBSD install takes less than ten minutes (assuming small file systems. Yes the newfs step can take a while on big file systems). You can also do several installs at the same time. So you are trying to save at most 100 minutes. dang, I'm gonna spend much of that telling you how to do it. Sounds like you are about to spend a few weeks trying to save a few minutes. Do you think you can write some custom build scripting system in under two hours? Do you think you can LEARN a custom building system in under two hours? This isn't a long, painful, massively interactive Linux or Solaris install, your return on investment of time here is not going to come in 10 boxes. I doubt it would be there for 100 boxes (if you include the setup and infrastructure). Keep in mind, the OpenBSD install process is fairly simple. 1: (assuming appropriate) create fdisk partition. Most common case can be done on the command line. 2: disklabel (can be scripted; see softraid(4) man page. can also use a pre-defined template file, and "predefined" means "before running disklabel"). 3: newfs all partitions 4: mount 'em somewhere, presumably hanging off /mnt 5: untar all desired file sets 6: record a few key config files (network, machine name, etc.) 6a: might as well add your admin users? 7: MAKEDEV all 8: install boot loader (I probably forgot something. that was all from early morning memory) This is all easily scriptable. So, if you can define your task appropriately, you can write an install script, stick it in your own bsd.rd (yes, you will name it something other than bsd.rd) or build a install kernel which fetches the script from a master install server, and away you go. I can't get too excited about this, as your bulk install needs are probably very different than mine, and the marginal time savings per machine are going to be small. Nick.
Re: OpenBSD pxe automated install
On 08/13/13 07:13, Marian Hettwer wrote: ... > This is sad :-/ For any mass deployment I need this... I was okay > with doing it semi automated for the first three boxes at work. But > nowadays it's 10 boxes and we are going for full automation. Hm > hm... > > Marian > ten boxes. Um. Lets see. An OpenBSD install takes less than ten minutes (assuming small file systems. Yes the newfs step can take a while on big file systems). You can also do several installs at the same time. So you are trying to save at most 100 minutes. dang, I'm gonna spend much of that telling you how to do it. Sounds like you are about to spend a few weeks trying to save a few minutes. Do you think you can write some custom build scripting system in under two hours? Do you think you can LEARN a custom building system in under two hours? This isn't a long, painful, massively interactive Linux or Solaris install, your return on investment of time here is not going to come in 10 boxes. I doubt it would be there for 100 boxes (if you include the setup and infrastructure). Keep in mind, the OpenBSD install process is fairly simple. 1: (assuming appropriate) create fdisk partition. Most common case can be done on the command line. 2: disklabel (can be scripted; see softraid(4) man page. can also use a pre-defined template file, and "predefined" means "before running disklabel"). 3: newfs all partitions 4: mount 'em somewhere, presumably hanging off /mnt 5: untar all desired file sets 6: record a few key config files (network, machine name, etc.) 6a: might as well add your admin users? 7: MAKEDEV all 8: install boot loader (I probably forgot something. that was all from early morning memory) This is all easily scriptable. So, if you can define your task appropriately, you can write an install script, stick it in your own bsd.rd (yes, you will name it something other than bsd.rd) or build a install kernel which fetches the script from a master install server, and away you go. I can't get too excited about this, as your bulk install needs are probably very different than mine, and the marginal time savings per machine are going to be small. Nick.
Re: OpenBSD pxe automated install
Am 13.08.2013 um 10:07 schrieb Don Jackson : > Later, Nick did this: > > redux - fully automated OpenBSD installation - hiqu.biz > > We failed to get any sort of buy in to this approach into the main > distribution… > This is sad :-/ For any mass deployment I need this... I was okay with doing it semi automated for the first three boxes at work. But nowadays it's 10 boxes and we are going for full automation. Hm hm... Marian
Re: OpenBSD pxe automated install
Hi loic, Sorry for top posting. I need exactly the same for OpenBSD. Maybe we could work together... In my example all I need on top of it is some same network config and a first puppet run after reboot... But I hesitated to modify bsd.rd... Maybe it's more wise to create a "netboot.rd" and let bsd.rd alone. A starting point could be http://www.hiqu.biz/redux PM me if you have interest to work together with me :-) Cheers Marian -- sent via my mobile C64 Am 13.08.2013 um 08:37 schrieb Loïc BLOT : > Hello Tito, > thanks to give me another time the FAQ, you think i have never read. > This boot process is okay for me but the problem is NOT the PXE boot > process. The problem is to automate the installation. > My OpenBSD pxeboot is chained after a pxelinux which already deserve > automated installed debian. Now the goal is to deserve automated > installed OpenBSD. > > I don't know if i don't choose the rights words to explain my need, or > if nobody read all my answers to already answered questions... but i > give a list of precision for future answers: > > 1. My problem is NOT PXE boot (http://www.openbsd.org/faq/faq6.html#PXE > => NO) > 2. My problem is NOT siteXX.tgz and customized installations with this > mean (http://openbsd.org/faq/faq4.html#site => NO) > 3. What i want is something like this: > https://wiki.debian.org/DebianInstaller/Preseed or this > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5 > /html/Installation_Guide/ch-kickstart2.html > > Then i ask @misc to know if an existing process exists, but now i think > this doesn't exist and i must create a special bsd.rd PXE to do this > (and share it to OpenBSD community, it will be great for deploy OpenBSD > on several machines without doing anything. > > Have a nice day :) > > -- > Best regards, > Loïc BLOT, > UNIX systems, security and network expert > http://www.unix-experience.fr > > > Le mardi 13 août 2013 à 06:29 +0800, Tito Mari Francis Escaño a écrit : >> Please read http://www.openbsd.org/faq/faq6.html#PXE and hope this >> helps. You'd have been told with deliberately unpleasant choice of >> words if next time you don't research well before asking in the list. >> >> >> >> On Tue, Aug 13, 2013 at 4:57 AM, Loïc BLOT >> wrote: >>Thanks for the precision James, you confirmed what i have >>understood. >>I will search tomorrow. >>-- >>Best regards, >>Loïc BLOT, >>UNIX systems, security and network expert >>http://www.unix-experience.fr >> >> >> >>Le lundi 12 août 2013 à 12:23 -0700, James A. Peltier a >>écrit : >>> - Original Message - >>> | read the FAQ, Loic. >>> | >>> | http://openbsd.org/faq/faq4.html#site >>> | >>> | Site*.tgz, install.site and upgrade.site are a good >>starting point. >>> | >>> | On Mon, Aug 12, 2013 at 11:59 AM, Loïc BLOT >>> | wrote: >>> | > Hello @misc. >>> | > >>> | > Today i'm working on automated deploy with PXE. I have >>successful >>> | > found >>> | > and made automated PXE install on Debian with pxelinux. >>> | > >>> | > I know OpenBSD have a pxe boot image to netinstall the >>system >>> | > > http://www.cyberciti.biz/faq/openbsd-boot-install-using-pxe-preboot-execution >>> | > -environment/ >>> | > >>> | > Is there any options to automate the installation ? >>> | > I want a machine to boot on bsd.rd, read a configuration >>file (url >>> | > passed by etc/boot.conf, for example) and install with >>the read >>> | > parameters. >>> | > Is there any issue to do this or i do it myself ? >>> | > >>> | > Thanks for advance >>> | > -- >>> | > Best regards, >>> | > Loïc BLOT, >>> | > UNIX systems, security and network expert >>> | > http://www.unix-experience.fr >>> | > >>> | > [demime 1.01d removed an attachment of type >>> | > application/pgp-signature which had a name of >>signature.asc] >>> >>> If you are looking for automated partitioning and the like >>the site.install >>and site.upgrade don't apply whatsoever. In order to fully >>automate the >>installation you will need to modify the bsd.rd file contents >>in order to do >>that. site.install and site.upgrade can be used to do other >>things like >>install packages or upgrade the OS as necessary. >> >>[demime 1.01d removed an attachment of type >>application/pgp-signature which had a name of signature.asc] > > [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: /etc/mail/spamd.key permissions/ownership?
On 2013-08-09 Fri 14:23 PM |, Peter N. M. Hansteen wrote: > > I checked the nearest couple of spamd equipped boxes, and it tends to be > > [Fri Aug 09 14:21:47] peter@skapet:~/www_sider$ ls -l /etc/mail/spamd.key > -rw-r--r-- 1 root wheel 2048 Nov 1 2009 /etc/mail/spamd.key > It's been syncing OK for a few days now as this (under RCS control): $ ls -l /etc/mail/spamd.key -r--r--r-- 1 postmaster postmasters 1574 Aug 10 01:54 /etc/mail/spamd.key Thanks Peter, -- Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7
Re: OpenBSD pxe automated install
On Aug 12, 2013, at 11:37 PM, Loïc BLOT wrote: > 3. What i want is something like this: > https://wiki.debian.org/DebianInstaller/Preseed or this > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5 > /html/Installation_Guide/ch-kickstart2.html > > Then i ask @misc to know if an existing process exists, but now i think > this doesn't exist and i must create a special bsd.rd PXE to do this > (and share it to OpenBSD community, it will be great for deploy OpenBSD > on several machines without doing anything. Using the initial version of ânbender.com/install.netboot/install.html I have/had a completely automated OpenBSD install. I pxeboot this modified bsd.rd, and it discovers/downloads special installer support via DHCP/etc. Later, Nick did this: redux - fully automated OpenBSD installation - hiqu.biz We failed to get any sort of buy in to this approach into the main distribution⦠Don
Re: Man page that explains the file format of man pages?
he's not talking about the source level mandoc/man macros the subject is about the SYNOPSIS section language for utilities e.g. in ``grep [ file ]'' the [ ] operator signifies 0 or 1 in ``rm file...'' the ... operator signifies 1 or more On Tue, Aug 13, 2013 at 2:58 AM, Jan Stary wrote: >> On Mon, Aug 12, 2013 at 9:21 PM, Anthony J. Bentley wrote: >> > Evan Root writes: >> > > Hello Misc, >> > > I tried man 5 man for an explanation of the synopsis section of the man >> > > page and it says there isn't a manual for the file format conventions of >> > > manual pages. Sometimes I have difficulty with the syntax of the synopsis >> > > sections, is there a document I can refer to? >> > >> > OpenBSD manuals are written in the mdoc macro language. There is a page >> > describing it, in section 7 (not 5). It is mentioned in the "SEE ALSO" >> > section of man(1). >> > >> > man 7 mdoc >> > >> > There is also a man(7) page, describing the older "man" macros, but these >> > are not used for new manuals in OpenBSD. mdoc has the advantage of being >> > a semantic format, unlike the old man language where the commands mostly >> > change only the presentation. > > On Aug 12 22:19:58, cellarr...@gmail.com wrote: >> I don't think you understood. I am not looking to write a man page. I was >> just wondering if the system came with an explanation of the manual page >> synopsis section language syntax. > > Which is exactly what Anthony pointed you to: > The mdoc(7) describes the language syntax in great detail. > >> Sometimes I get confused by the language >> and am not sure if I understand the synopsis sections of the man pages. >> Also I am concerned that people who I might recommend OpenBSD to will find >> that an undocumented part of the system is the man pages. > > The mandoc people could probably take this as an offence. > The manual system, as other parts of OpenBSD, is thoroughly documented. > >> Even the welcome message from Theo says "This message attempts to describe >> the most basic initial questions that a >> system administrator of an OpenBSD box might have. If you are not >> familiar with how to read man pages, type >> "man man" at a shell prompt and read the entire thing." > > Well have you? That points you to mdoc(7) in SEE ALSO. > > "How to read man pages" in the welcome message refers > to the the rendered manpages - as presented to the user with man(1). > You are asking about the language syntax - how the manpages are written. > >> I think that this post on stack exchange presents my question better.. the >> answers are all pretty short and non-committal though. >> http://stackoverflow.com/questions/8716047/is-there-a-specification-for-a-man-pages-synopsis-section > > So you _are_ looking to write a manpage; > mdoc(7) has a section called "MANUAL STRUCTURE" > with a subsection called "SYNOPIS". Have you missed it? > > After you write it, don't forget to 'mandoc -Tlint'.
Re: OpenBSD pxe automated install
On Mon, Aug 12, 2013 at 03:31:44PM -0400, Kenneth R Westerback wrote: > On Mon, Aug 12, 2013 at 08:59:27PM +0200, Lo?c BLOT wrote: > > Hello @misc. > > > > Today i'm working on automated deploy with PXE. I have successful found > > and made automated PXE install on Debian with pxelinux. > > > There is no 'offical' method. If you check the mailing list archives you'll > find a few people have come up with something that works for them. There is an official method but not fully completed I would say. Check install.sub, it offers couple of variables and functions which could be overriden by you to have your own installation (sets, partitioning, console...). But this is just for installer, for rest one should use siteXX.tgz, install.site and rc.firsttime. jirib
Re: Man page that explains the file format of man pages?
> On Mon, Aug 12, 2013 at 9:21 PM, Anthony J. Bentley wrote: > > Evan Root writes: > > > Hello Misc, > > > I tried man 5 man for an explanation of the synopsis section of the man > > > page and it says there isn't a manual for the file format conventions of > > > manual pages. Sometimes I have difficulty with the syntax of the synopsis > > > sections, is there a document I can refer to? > > > > OpenBSD manuals are written in the mdoc macro language. There is a page > > describing it, in section 7 (not 5). It is mentioned in the "SEE ALSO" > > section of man(1). > > > > man 7 mdoc > > > > There is also a man(7) page, describing the older "man" macros, but these > > are not used for new manuals in OpenBSD. mdoc has the advantage of being > > a semantic format, unlike the old man language where the commands mostly > > change only the presentation. On Aug 12 22:19:58, cellarr...@gmail.com wrote: > I don't think you understood. I am not looking to write a man page. I was > just wondering if the system came with an explanation of the manual page > synopsis section language syntax. Which is exactly what Anthony pointed you to: The mdoc(7) describes the language syntax in great detail. > Sometimes I get confused by the language > and am not sure if I understand the synopsis sections of the man pages. > Also I am concerned that people who I might recommend OpenBSD to will find > that an undocumented part of the system is the man pages. The mandoc people could probably take this as an offence. The manual system, as other parts of OpenBSD, is thoroughly documented. > Even the welcome message from Theo says "This message attempts to describe > the most basic initial questions that a > system administrator of an OpenBSD box might have. If you are not > familiar with how to read man pages, type > "man man" at a shell prompt and read the entire thing." Well have you? That points you to mdoc(7) in SEE ALSO. "How to read man pages" in the welcome message refers to the the rendered manpages - as presented to the user with man(1). You are asking about the language syntax - how the manpages are written. > I think that this post on stack exchange presents my question better.. the > answers are all pretty short and non-committal though. > http://stackoverflow.com/questions/8716047/is-there-a-specification-for-a-man-pages-synopsis-section So you _are_ looking to write a manpage; mdoc(7) has a section called "MANUAL STRUCTURE" with a subsection called "SYNOPIS". Have you missed it? After you write it, don't forget to 'mandoc -Tlint'.
Re: Install drivers
On 08/13/13 08:52, David Coppa wrote:
> On Tue, Aug 13, 2013 at 2:23 AM, Alexander Hall
> wrote:
>> On 08/12/13 18:49, Peter Hessler wrote:
>>> this isn't a lesser operating system. all such drivers are
>>> included out of the box.
>>>
>>> the only thing that may be missing, is the various firmware
>>> files. Check out how fw_update(8) works to fetch those.
>>
>> This diff lets you pinpoint specific drivers, or use '-a' to
>> install/update them all. I've been wanting to cook something like
>> this up for a long time. Man page bits still missing.
>
> Nice! I like it.
>
Ah, and then I even sent an old version. No functional difference IIRC,
but anyway, here's what I intended to send.
/Alexander
Index: fw_update.sh
===
RCS file: /cvs/src/usr.sbin/fw_update/fw_update.sh,v
retrieving revision 1.12
diff -u -p -r1.12 fw_update.sh
--- fw_update.sh17 Sep 2012 18:28:43 - 1.12
+++ fw_update.sh13 Aug 2013 07:09:50 -
@@ -22,7 +22,7 @@ DRIVERS="acx athn bwi ipw iwi iwn malo o
PKG_ADD="pkg_add -I -D repair"
usage() {
- echo "usage: ${0##*/} [-nv]" >&2
+ echo "usage: ${0##*/} [-anv] [driver ...]" >&2
exit 1
}
@@ -30,26 +30,33 @@ verbose() {
[ "$verbose" ] && echo "${0##*/}: $@"
}
+setpath() {
+ set -- $(sysctl -n kern.version |
+ sed 's/^OpenBSD \([0-9]\.[0-9]\)\([^ ]*\).*/\1 \2/;q')
+
+ local version=$1 tag=$2
+
+ [[ $tag == -!(stable) ]] && version=snapshots
+ export PKG_PATH=http://firmware.openbsd.org/firmware/$version/
+}
+
+all=false
verbose=
nop=
-while getopts 'nv' s "$@" 2>/dev/null; do
+while getopts 'anv' s "$@" 2>/dev/null; do
case "$s" in
+ a) all=true;;
v) verbose=${verbose:--}v ;;
n) nop=-n ;;
*) usage ;;
esac
done
-# No additional arguments allowed
-[ $# = $(($OPTIND-1)) ] || usage
-
-set -- $(sysctl -n kern.version | sed 's/^OpenBSD \([0-9]\.[0-9]\)\([^
]*\).*/\1 \2/;q')
+shift $((OPTIND - 1))
-version=$1
-tag=$2
+$all && set -- $DRIVERS
-[[ $tag == -!(stable) ]] && version=snapshots
-export PKG_PATH=http://firmware.openbsd.org/firmware/$version/
+setpath
installed=$(pkg_info -q)
dmesg=$(cat /var/run/dmesg.boot; echo; dmesg)
@@ -59,10 +66,12 @@ update=
extra=
for driver in $DRIVERS; do
+ [ $# = 0 ] || printf "%s\n" "$@" | fgrep -qx "$driver" || continue
if print -r -- "$installed" | grep -q "^${driver}-firmware-"; then
update="$update ${driver}-firmware"
extra="$extra -Dupdate_${driver}-firmware"
- elif print -r -- "$dmesg" | grep -q "^${driver}[0-9][0-9]* at "; then
+ elif [ $# != 0 ] ||
+ print -r -- "$dmesg" | grep -q "^${driver}[0-9][0-9]* at "; then
install="$install ${driver}-firmware"
fi
done
Re: Bind with GSSAPI
Jeff Powell wrote: > I've been tearing my hair out trying to get this to work. I'm running > OpenBSD 5.3 x64 and I'm trying to build isc-bind from ports using the > -with-gssapi in the Makefile (I want to have the -g option in nsupdate so > I can use iscp-dhcp to register dynamic DNS updates against a secure > Windows nameserver). > I've specified --with-gssapi=/usr in the Makefile. Now, OpenBSD seems to > put the gssapi.h in /usr/include/kerberosV, and krb5.h is there too. You need to tell the compiler to look for include files in that directory. Setting up CFLAGS to do so might help. Scanning the ports tree to see how other ports deal with this may be worthwhile too. > Yet, when I make the port it gives the following errors: > > checking for GSSAPI library... looking in /usr/lib checking gssapi.h > usability... no checking gssapi.h presence... no checking for gssapi.h... > no checking gssapi/gssapi.h usability... no checking gssapi/gssapi.h > presence... no checking for gssapi/gssapi.h... no configure: error: > gssapi.h not found > If the above doesn't help, did you check the output of config.log ? It may give you a more exact reason for this failure. > I've tried adding symlinks here and there, but nothing works. I also see > that the configure script wants to tack /lib onto the end of whatever path > I enter for --with-gssapi=, even though the .h files aren't located in any > such folder. > Did you check whether this option actually modifies the include file search path in any way ? If it somehow sets a hardcoded path you probably need to cook up a patch yourself. > Am I doing something wrong? I'd appreciate any insights. > You're posting too often in too many places on a short notice. > Thanks, > > Jeff
