Re: [PATCH] pcap manpages
Committed, thanks. On Mon, Apr 06, 2015 at 07:30:46PM +0200, Jan Stary wrote: > Any comments? > > On Mar 29 22:24:41, h...@stare.cz wrote: > > The diff below fixes what seem to be errors in pcap.3, > > either in factuality or markup or grammar. > > > > Jan > > > > > > > > --- pcap.3.orig Sun Mar 29 22:06:49 2015 > > +++ pcap.3 Sun Mar 29 22:16:50 2015 > > @@ -169,7 +169,7 @@ at packets on the network. > > .Fa source > > is a string that specifies the network device to open. > > .Fa snaplen > > -specifies the maximum number of bytes to capture. > > +specifies the maximum number of bytes to capture from one packet. > > .Fa promisc > > specifies if the interface is to be put into promiscuous mode. > > (Note that even if this parameter is false, the interface > > @@ -209,7 +209,7 @@ for writing. > > The name > > .Ql - > > is a synonym for > > -.Dv stdin . > > +.Dv stdout . > > .Dv NULL > > is returned on failure. > > .Fa p > > @@ -229,7 +229,7 @@ can be used to get the error text. > > .Pp > > .Fn pcap_dump_fopen > > allows the use of savefile functions on the already-opened stream > > -.Dq f . > > +.Fa f . > > .Pp > > .Fn pcap_lookupdev > > returns a pointer to a network device suitable for use with > > @@ -276,7 +276,7 @@ pointer which is passed in from > > .Fn pcap_dispatch , > > a pointer to the > > .Fa pcap_pkthdr > > -struct (which precede the actual network headers and data), > > +struct (which precedes the actual network headers and data), > > and a > > .Fa u_char > > pointer to the packet data. > > @@ -351,7 +351,7 @@ return when live read timeouts occur. > > Rather, specifying a non-zero read timeout to > > .Fn pcap_open_live > > and then calling > > -.Fn pcap_dispatch > > +.Fn pcap_loop > > allows the reception and processing of any packets that arrive when the > > timeout occurs. > > A negative > > @@ -490,10 +490,11 @@ It is typically used when just using libpcap for compi > > .Pp > > .Fn pcap_fopen_offline > > may be used to read dumped data from an existing open stream > > -.Dq fp . > > +.Fa fp . > > .Pp > > .Fn pcap_lib_version > > returns a string describing the version of libpcap. > > +.Pp > > .Fn pcap_datalink_val_to_name > > and > > .Fn pcap_datalink_val_to_description >
Fwd: CVS: cvs.openbsd.org: src
A heads up on this commit: if you're following -current and using any perl modules that pull in threaded libraries from packages, such as mysql/mariadb integration via DBD::mysql, then you may want to wait the day or so until the ports package builds have caught up with the change. The perl in base built against libpthread.19.0 cannot load the mysql.so shared object linked against libpthread.18.1 Philip Guenther -- Forwarded message -- From: Philip Guenther Date: Mon, Apr 6, 2015 at 6:27 PM Subject: CVS: cvs.openbsd.org: src To: source-chan...@cvs.openbsd.org CVSROOT:/cvs Module name:src Changes by: guent...@cvs.openbsd.org2015/04/06 19:27:07 Modified files: lib/csu: crtbegin.c crtbeginS.c lib/libc : shlib_version lib/libc/arch/alpha: SYS.h lib/libc/arch/alpha/sys: fork.S lib/libc/arch/amd64: SYS.h lib/libc/arch/amd64/sys: fork.S lib/libc/arch/arm: SYS.h lib/libc/arch/arm/sys: fork.S lib/libc/arch/hppa: SYS.h lib/libc/arch/hppa/sys: fork.S lib/libc/arch/hppa64: SYS.h lib/libc/arch/hppa64/sys: fork.S lib/libc/arch/i386: SYS.h lib/libc/arch/i386/sys: fork.S lib/libc/arch/m88k: SYS.h lib/libc/arch/m88k/sys: fork.S lib/libc/arch/mips64: SYS.h lib/libc/arch/mips64/sys: fork.S lib/libc/arch/powerpc: SYS.h lib/libc/arch/powerpc/sys: fork.S lib/libc/arch/sh: SYS.h lib/libc/arch/sh/sys: fork.S lib/libc/arch/sparc: SYS.h lib/libc/arch/sparc/sys: fork.S lib/libc/arch/sparc64: SYS.h lib/libc/arch/sparc64/sys: fork.S lib/libc/arch/vax: SYS.h lib/libc/arch/vax/sys: fork.S lib/libc/include: thread_private.h lib/libc/stdlib: atexit.c lib/libc/sys : Makefile.inc lib/libc/thread: Makefile.inc unithread_malloc_lock.c lib/librthread : rthread.c rthread_fork.c rthread_libc.c shlib_version regress/lib/csu/callbacks: Makefile regress/lib/csu/callbacks/pthread_atfork: Makefile pthread_atfork_test.c Added files: lib/libc/include: atfork.h lib/libc/sys : w_fork.c lib/libc/thread: atfork.c regress/lib/csu/callbacks/pthread_atfork: expected_child.out expected_parent.out Log message: Make pthread_atfork() track the DSO that called it like atexit() does, unregistering callbacks if the DSO is unloaded. Move the callback handling from libpthread to libc, though libpthread still overrides the inner call to handle locking and thread-library reinitialization. Major version bump for both libc and libpthread. verification that this fixes various ports ajacoutot@ asm assistance miod@; ok millert@ deraadt@
Re: autoinstall(8) tweaks
On Mon, Apr 06, 2015 at 09:48:58PM +0800, Nathanael Rensen wrote:
> A couple of autoinstall(8) tweaks that I find useful.
>
> I find it convenient to be able to specify a path to the response file.
> I also prefer to use the DHCP supplied hostname rather than the MAC
> address.
Actually, these ideas are quite interesting...
Being able to use the hostname seems to be a good addition, easy enough
to implement and doesn't interfere with existing functionality.
Using the filename DHCP option to carry over the path to the response
file on the webserver is possible, but that needs some extra setup.
If the responsefile is in /path/to, like:
/var/www/htdocs/path/to/install.conf
The tftp setup would need to be setup like this:
/tftpboot/etc/boot.conf
/tftpboot/pxeboot
/tftpboot/path/to/auto_install -> ../../pxeboot
/tftpboot/path/to/auto_upgrade -> ../../pxeboot
> It's handy for the log to remain on the host as a reference. Sometimes the
> email gets lost (e.g. caught in a spam trap).
Not sure about this yet.
I've attached a slighly modified diff for the hostname and path addition
leaving out the manpage parts for now.
Lightly tested, but seems to work.
Index: install.sub
===
RCS file: /home/cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.830
diff -p -u -r1.830 install.sub
--- install.sub 6 Apr 2015 13:34:23 - 1.830
+++ install.sub 6 Apr 2015 16:46:54 -
@@ -304,7 +304,7 @@ retrap() {
# Fetch response file for autoinstall.
get_responsefile() {
- local _rf _ifdev _mac _mode _server _lf
+ local _rf _ifdev _mac _mode _server _lf _hn _path
action=
[[ -f /auto_upgrade.conf ]] && _rf=/auto_upgrade.conf _mode=upgrade
@@ -328,16 +328,19 @@ get_responsefile() {
[[ -n $_ifdev ]] && dhclient $_ifdev || break
_lf=/var/db/dhclient.leases.$_ifdev
_server=$(sed "/^ *next-server /!d;s///;s/;$//;q" $_lf)
- _mode=$(sed -E '/^ *filename
"auto_(install|upgrade)";$/!d;s//\1/;q' $_lf)
- hostname "$(sed -E '/^ *option host-name "(.*)";$/!d;s//\1/;q'
$_lf)"
+ _mode=$(sed -E '/^ *filename
"(.*\/)?auto_(install|upgrade)";$/!d;s//\2/;q' $_lf)
+ _path=$(sed -E '/^ *filename "(.*\/)[^/]+";$/!d;s//\1/;q' $_lf)
+ _hn=$(sed -E '/^ *option host-name "(.*)";$/!d;s//\1/;q' $_lf)
+ hostname "$_hn"
done
# Fetch response file if server and mode are known, otherwise tell which
- # one was missing. First try to fetch mac-mode.conf, then mode.conf.
+ # one was missing. First try to fetch mac-mode.conf, then
+ # hostname-mode.conf, and finally mode.conf.
if [[ -n $_server && -n $_mode ]]; then
_mac=$(ifconfig $_ifdev | sed 's/.*lladdr \(.*\)/\1/p;d')
- for _rf in {$_mac-,}$_mode; do
- _url=http://$_server/$_rf.conf
+ for _rf in {$_mac-,${_hn:+$_hn-,}}$_mode; do
+ _url=http://$_server/$_path$_rf.conf
echo "Fetching $_url"
if ftp -Vo "/ai.$_mode.conf" "$_url" 2>/dev/null; then
action=$_mode
--
-=[rpe]=-
Re: Compiling ports tree on older architecture question
On 5 April 2015 at 08:35, Peter Hessler wrote: > I do the 32bit sparc packages builds. > > We hvae a cluster of 5 machines, and they take roughly 3 weeks to build > if there are no crashes or other issues. Right now thought, not all > machines are able to build, so it will be closer to 5 weeks. On 5 April 2015 at 09:58, Landry Breuil wrote: > Pending hardware & kernel reliability.. have some numbers: > macppc: 3 hosts (Xserve G4, 2 MP running SP), around 15 days for ~8400 pkgs > alpha: 2 hosts (DS20L MP running SP + DS10L), around 18/20 days for ~6900 pkgs > sparc64: 3 SP hosts (2 v210 +, 1 v215), around 17 days for ~8300 pkgs > hppa: 2 MP hosts (J6000 + J6700), around 9/10 days for ~6700 pkgs Thanks for posting those figures. Do you guys make any changes to the system configuration? In this scenario, the user the build was running under was made a member of the staff login class, home directory was mounted with softdep & kern.bufcachepercent increased to 50. pkgsrc has the ability to do unprivileged builds where the target is the users home directory & the host operating system remains untouched. There are facilities for doing distributing the workload across multiple hosts or parallelising on a single host but 1) I've not got my head around this process at all 2) lack of nullfs support meant lots of duplication 3) didn't want to resort to using NFS as this would need privileges to configure / mount. The most painful part in pkgsrc can be the initial scan stage which the entire contents of the pkgsrc directory is crawled to generate a list of whats there & what dependencies there are, as this was running as a single process, it took a long time, it did not help that a bad commit after the tree was unlocked caused the build to fail, the other item which we lost a day one was a build which had hung and as there was no restriction on CPU time, the build was held up, the process was killed & ulimit -t 7200 added to the config. The bulkbuild on amd64 came to an end a few hours ago, the bulkbuild on sparc64 is still in progress, the scan stage is extremely painful there. http://mail-index.netbsd.org/pkgsrc-bulk/2015/04/06/msg011484.html The full report contains the logs generated at each stage of a failed package (inside the link above). Thanks to Ian for providing access to his machine. Sevan / Venture37
Re: [PATCH] pcap manpages
Any comments? On Mar 29 22:24:41, h...@stare.cz wrote: > The diff below fixes what seem to be errors in pcap.3, > either in factuality or markup or grammar. > > Jan > > > > --- pcap.3.orig Sun Mar 29 22:06:49 2015 > +++ pcap.3Sun Mar 29 22:16:50 2015 > @@ -169,7 +169,7 @@ at packets on the network. > .Fa source > is a string that specifies the network device to open. > .Fa snaplen > -specifies the maximum number of bytes to capture. > +specifies the maximum number of bytes to capture from one packet. > .Fa promisc > specifies if the interface is to be put into promiscuous mode. > (Note that even if this parameter is false, the interface > @@ -209,7 +209,7 @@ for writing. > The name > .Ql - > is a synonym for > -.Dv stdin . > +.Dv stdout . > .Dv NULL > is returned on failure. > .Fa p > @@ -229,7 +229,7 @@ can be used to get the error text. > .Pp > .Fn pcap_dump_fopen > allows the use of savefile functions on the already-opened stream > -.Dq f . > +.Fa f . > .Pp > .Fn pcap_lookupdev > returns a pointer to a network device suitable for use with > @@ -276,7 +276,7 @@ pointer which is passed in from > .Fn pcap_dispatch , > a pointer to the > .Fa pcap_pkthdr > -struct (which precede the actual network headers and data), > +struct (which precedes the actual network headers and data), > and a > .Fa u_char > pointer to the packet data. > @@ -351,7 +351,7 @@ return when live read timeouts occur. > Rather, specifying a non-zero read timeout to > .Fn pcap_open_live > and then calling > -.Fn pcap_dispatch > +.Fn pcap_loop > allows the reception and processing of any packets that arrive when the > timeout occurs. > A negative > @@ -490,10 +490,11 @@ It is typically used when just using libpcap for compi > .Pp > .Fn pcap_fopen_offline > may be used to read dumped data from an existing open stream > -.Dq fp . > +.Fa fp . > .Pp > .Fn pcap_lib_version > returns a string describing the version of libpcap. > +.Pp > .Fn pcap_datalink_val_to_name > and > .Fn pcap_datalink_val_to_description
autoinstall(8) tweaks
A couple of autoinstall(8) tweaks that I find useful.
I find it convenient to be able to specify a path to the response file.
I also prefer to use the DHCP supplied hostname rather than the MAC
address.
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.829
diff -u -p -r1.829 install.sub
--- install.sub 5 Apr 2015 12:37:14 - 1.829
+++ install.sub 6 Apr 2015 13:33:02 -
@@ -304,7 +304,7 @@ retrap() {
# Fetch response file for autoinstall.
get_responsefile() {
- local _rf _ifdev _mac _mode _server _lf
+ local _rf _ifdev _mac _mode _server _lf _path
action=
[[ -f /auto_upgrade.conf ]] && _rf=/auto_upgrade.conf _mode=upgrade
@@ -328,16 +328,18 @@ get_responsefile() {
[[ -n $_ifdev ]] && dhclient $_ifdev || break
_lf=/var/db/dhclient.leases.$_ifdev
_server=$(sed "/^ *next-server /!d;s///;s/;$//;q" $_lf)
- _mode=$(sed -E '/^ *filename
"auto_(install|upgrade)";$/!d;s//\1/;q' $_lf)
+ _mode=$(sed -E '/^ *filename
"(.*\/)?auto_(install|upgrade)";$/!d;s//\2/;q' $_lf)
+ _path=$(sed -E '/^ *filename "(.*\/)[^/]+";$/!d;s//\1/;q' $_lf)
hostname "$(sed -E '/^ *option host-name "(.*)";$/!d;s//\1/;q'
$_lf)"
done
# Fetch response file if server and mode are known, otherwise tell which
- # one was missing. First try to fetch mac-mode.conf, then mode.conf.
+ # one was missing. First try to fetch mac-mode.conf, then
+ # hostname-mode.conf, and finally mode.conf.
if [[ -n $_server && -n $_mode ]]; then
_mac=$(ifconfig $_ifdev | sed 's/.*lladdr \(.*\)/\1/p;d')
- for _rf in {$_mac-,}$_mode; do
- _url=http://$_server/$_rf.conf
+ for _rf in {$_mac-,$(hostname -s)-,}$_mode; do
+ _url=http://$_server/$_path$_rf.conf
echo "Fetching $_url"
if ftp -Vo "/ai.$_mode.conf" "$_url" 2>/dev/null; then
action=$_mode
Index: autoinstall.8
===
RCS file: /cvs/src/share/man/man8/autoinstall.8,v
retrieving revision 1.11
diff -u -p -r1.11 autoinstall.8
--- autoinstall.8 23 Oct 2014 21:33:21 - 1.11
+++ autoinstall.8 6 Apr 2015 13:31:22 -
@@ -47,22 +47,16 @@ It behaves as if the user selected '(A)u
always fetches the response file via the netboot interface.
.Ss Fetching the response file
.Nm
-uses HTTP to fetch one of the files
-.Pa install.conf
-or
-.Ar MAC_address Ns - Ns Pa install.conf
-for install answers, or one of
-.Pa upgrade.conf
-or
-.Ar MAC_address Ns - Ns Pa upgrade.conf
-for upgrade answers.
-The URL used to fetch the file is constructed from information provided in
-the
+uses HTTP to fetch a response file which provides answers to
+install or upgrade questions.
+The URL used to fetch the response file is constructed from
+information provided in the
.Xr dhcpd.conf 5
-statements
-.Ic next-server
+.Ic next-server ,
+.Ic filename
and
-.Ic filename .
+.Ic host-name
+options.
If the
.Ar filename
is
@@ -71,6 +65,7 @@ then the URLs tried are, in order:
.Sm off
.Bd -unfilled -offset indent
.No http:// Ar next-server No / Ar MAC_address No -install.conf
+.No http:// Ar next-server No / Ar host-name No -install.conf
.No http:// Ar next-server No /install.conf
.Ed
.Sm on
@@ -79,7 +74,7 @@ where
.Ar MAC_address
is a string of six hex octets separated by colons
representing the MAC
-address of the interface being used to fetch the files.
+address of the interface being used to fetch the response file.
.Pp
If the
.Ar filename
@@ -89,9 +84,15 @@ the URLs tried are, in order:
.Sm off
.Bd -unfilled -offset indent
.No http:// Ar next-server No / Ar MAC_address No -upgrade.conf
+.No http:// Ar next-server No / Ar host-name No -upgrade.conf
.No http:// Ar next-server No /upgrade.conf
.Ed
.Sm on
+.Pp
+If the
+.Ar filename
+includes a parent directory it will be used as a server relative
+path in the http URL to fetch the response file.
.Pp
On architectures where the
.Ic filename
It's handy for the log to remain on the host as a reference. Sometimes the
email gets lost (e.g. caught in a spam trap).
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.829
diff -u -p -r1.829 install.sub
--- install.sub 5 Apr 2015 12:37:14 - 1.829
+++ install.sub 6 Apr 2015 13:33:02 -
@@ -2305,13 +2318,12 @@ elif [[ -z $RESPFILE ]]; then
if [[ -f /ai.done ]]; then
# Generate unique filename and let rc.firsttime feed it to
# whatever mail system we have at hand by then.
- while _lf=/mnt/var/log/ai.log.$RANDOM && test -e $_lf
Re: OpenSMTPD with fewer semicolons
On Mon, Apr 06, 2015 at 01:12:05PM +0200, Mike Burns wrote: > On 2015-04-04 18.24.38 -0700, Philip Guenther wrote: > > the original diff is fine and should be applied. > > Thanks. Any other OKs/anyone want to apply this? > Yes, this is ok, I'll apply -- Gilles Chehade https://www.poolp.org @poolpOrg
Re: OpenSMTPD with fewer semicolons
On 2015-04-04 18.24.38 -0700, Philip Guenther wrote: > the original diff is fine and should be applied. Thanks. Any other OKs/anyone want to apply this? -Mike
Re: [PATCH] bsd.port.mk - make relation between GH_TAGNAME & GH_COMMIT more apparent (prevent actual bug regression)
Stuart Henderson said: > I think we should remove the existing ones and make it an error to > specify both GH_TAGNAME and GH_COMMIT. Thoughts? If people think this > is a good idea I'll do the ports mop-up. I'd rather see a warning saying that GH_COMMIT is ignored and should be removed. I see no reason to bump all ports that currently specify both. -- Dmitrij D. Czarkoff
Re: Proposed small change for ping(8) -- updated diff
On 04/06/2015 07:02 AM, Philip Guenther wrote: On Mon, Mar 30, 2015 at 9:19 AM, Gregory Edigarov wrote: After discussing with Sven Falempin changed the message to "Packet timed out" to be more exact updated diff: What's the output when ping packets or their replies are reordered? Well, it should at first output the "packet timed out" but then it will show the normal output.. And this is the intended behaviour. -- With best regards, Gregory Edigarov
