Re: 5.9: tar core dumps extracting a tar created on 4.8
> On Wed, Jun 22, 2016 at 12:14 PM, Listas IT wrote: >> When I try to extract a tar created by 4.8 base tar on a fresh installed >> 5.9 it dies with core dump and this message on syslog: >> >> Jun 22 16:08:52 un1 /bsd: tar(9316): syscall 14 "dpath" >> Jun 22 16:09:11 un1 /bsd: tar(19504): syscall 14 "dpath" >> Jun 22 16:10:55 un1 /bsd: tar(22328): syscall 14 "dpath" >> >> I'm using tar cf file.tar directory on source, ie no gzip. >> >> What's next? > > As others have noted, "dpath" points at it trying to create a device > or fifo. Currently, extracting those is only permitted if the -p > option is also given. In practice, if you're extracting devices then > you are trying to copy a root filesystem and *REALLY WANT* the -p > option already. > > > Philip Guenther > > Yes, there where some *random devices. It worked with -p! Thank you all!
5.9: tar core dumps extracting a tar created on 4.8
Hello When I try to extract a tar created by 4.8 base tar on a fresh installed 5.9 it dies with core dump and this message on syslog: Jun 22 16:08:52 un1 /bsd: tar(9316): syscall 14 "dpath" Jun 22 16:09:11 un1 /bsd: tar(19504): syscall 14 "dpath" Jun 22 16:10:55 un1 /bsd: tar(22328): syscall 14 "dpath" I'm using tar cf file.tar directory on source, ie no gzip. What's next? Thanks! J
Show us your /etc/profile
Hello everybody
How do you customize your environment?
What aliases or custom functions do you use?
Here's my /etc/profile I think you can find one or two interesting things
in it.
Show us yours!
(in case wordwrapping breaks long lines: http://pastie.org/10322761)
#
hname=`hostname`
hname=${hname%%.*}
# You are here
test ! -f ~/.hushlogin && test -t 0 && banner $hname
# complete path
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/u/system/bin:
export PATH
# system defaults
PAGER=less
export PAGER
EDITOR=vi
test -x "/usr/local/bin/vim" && EDITOR=vim
export EDITOR
# confort
alias more=less
alias ls='ls -Fca'
alias l='ls -l'
alias wget='wget -c'
alias _tf='tail -20 -f '
alias tf='_tf /var/log/messages'
alias tfm='_tf /var/log/maillog'
alias tfd='_tf /var/log/daemon'
alias ducks='du -cks * |sort -rn |head -11'
alias pid='ps awx | grep -v grep | egrep -- '
test -x "`which pgrep 2> /dev/null`" && alias pid='pgrep -lf '
pidof()
{
pgrep $1
}
pkey()
{
cat ~/.ssh/id_dsa.pub | \
ssh $1 "(mkdir ~/.ssh > /dev/null 2>&1; cat - >> ~/.ssh/authorized_keys)"
}
# windozise
#alias rm='rm -i'
#alias mv='mv -i'
#alias cp='cp -i'
# www
alias gohtdocs='cd /var/www/htdocs'
alias gosite='cd /var/www/htdocs/site/'
alias httpd_restart='/etc/rc.d/httpd restart'
# OpenBSD CVS
CVSROOT=anon...@anoncvs.openbsd.org:/cvs
export CVSROOT
CVS_RSH=/usr/bin/ssh
export CVS_RSH
# OpenBSD packages
export PKG_PATH="http://ftp.openbsd.org/pub/OpenBSD/`uname
-r`/packages/`uname -m`/"
export PKG_PATH
# ui
if [ "${SHELL}" = "/bin/ksh" ]
then
PS1=$hname':$PWD{!}'
if [ "$USER" == "root" ]
then
export PS1="$PS1# "
alias p='export PS1="# "'
else
export PS1="$PS1 "
alias p='export PS1="$ "'
fi
set -o emacs# heh
set -o vi-tabcomplete # bashishhh
bind ^B=backward-word
bind ^N=forward-word
fi
unset hname
# ui
if [ -t 0 ]
then
stty erase ^?
stty status ^T # for dd(1)
fi
#
alias fw_log='tcpdump -ttt -nle -i pflog0'
alias openports='fstat | grep internet| grep -v 127.0.0 | sort -u | awk "{
print \$9 }" | sort -u'
xtitle()
{
printf "\\033]0;$1\\007"
}
alias unspam='sa-learn --ham --dbpath /var/amavisd/.spamassassin -u _vscan'
alias idspam='sudo -u _vscan /bin/sh -l'
function spamtrap
{
test -z "$1" && echo 'usage: spamtrap ' && return 1
spamdb | grep "$1" | cut -d\| -f 2 | while read x ; do spamdb -t -a $x;
done
}
export http_proxy="http://157.92.192.253:8080/";
export https_proxy=$http_proxy
export ftp_proxy=$http_proxy
test -f /etc/profile.local && . /etc/profile.local
Re: 5.7: dhclient ignoring routers option (SOLVED?)
According to this:
http://undeadly.org/cgi?action=article&sid=20140204080515&mode=expanded
This is expected behaviour as:
"Note that classless-static-routes overrides the router option, and that a
default route must always be specified!"
There's no such warning in the man pages for dhclient or dhcpd.
So, options like this (notice 0.0.0.0/0 and def gw first) seems to work:
option classless-static-routes 0.0.0.0/0 172.16.192.119, 192.168.10.0/24
172.16.192.149;
option classless-ms-static-routes 0.0.0.0/0 172.16.192.119,
192.168.10.0/24 172.16.192.149;
I think this could be made clear in the dhcp-options(5) man page.
Now it reads:
option classless-static-routes ip/prefix ip [, ip/prefix ip ...];
This option specifies a list of static routes in CDIR notation,
which should be sent to the client.
option classless-ms-static-routes ip/prefix ip [, ip/prefix ip ...];
This option does the same as classless-static-routes, but uses
option code 249 instead of 121, since Windows XP and Windows
Server 2003 ignore option 121.
Something in the line of:
Note: classless-static-routes overrides the router option and a default
route must always be specified!
The syntax for a route is '1.2.3.4/13 5.6.7.8', which says that the
gateway 5.6.7.8 is the way to get to the subnet 1.2.3.4/13. Thus in
dhclient.conf you can say 'default classless-static-routes 0/0 5.6.7.9,
1.2.3.4/13 5.6.7.8;'. i.e. the default route is 5.6.7.9 and the gateway
for 1.2.3.4/13 is 5.6.7.8.
Similarly you can specify the value that dhcpd supplies to clients.
Thanks
Juan
> Hello
>
> dhclient on 5.7 won't set the client default gateway if other static
> routes are present (same problem exists on 5.6, at least).
>
> dhcpd server is running 5.6 stable with aprox 400 workstations and
> appliances/printers with mixed OSs and versions all working fine.
>
> At least both -windows and linux- are able to get and set default gw and
> static routes.
>
>
> The dhcpd.conf
>
> subnet 172.16.192.0 netmask 255.255.254.0 {
>
> # default gw
> option routers 172.16.192.119;
>
> # static route to new building
> option classless-static-routes 192.168.10.0/24 172.16.192.149;
> option classless-ms-static-routes 192.168.10.0/24 172.16.192.149;
>
> # Ips we assign
> range 172.16.192.153 172.16.192.249;
>
>
> host stratus { hardware ethernet 00:00:00:00:00:01; fixed-address
> 172.16.192.219; }
>
> ... other host declarations ...
> }
>
>
> With the config as it is above, the routers option will be ignored, while
> the 192.168.10.0/24 route will be set correctly.
>
> If I comment out both classless-* options and restart the server,
> "routers" will be honored and a default gateway set.
>
>
> This is dhclient config:
>
> testrat:/root{3}# cat /etc/dhclient.conf
> #request subnet-mask, broadcast-address, routers, domain-name,
> domain-name-servers;
>
> require routers;
> testrat:/root{4}#
>
> No luck with and empty dhclient.conf.
>
>
> Any ideas?
>
> Thanks
>
> Juan
5.7: dhclient ignoring routers option
Hello
dhclient on 5.7 won't set the client default gateway if other static
routes are present (same problem exists on 5.6, at least).
dhcpd server is running 5.6 stable with aprox 400 workstations and
appliances/printers with mixed OSs and versions all working fine.
At least both -windows and linux- are able to get and set default gw and
static routes.
The dhcpd.conf
subnet 172.16.192.0 netmask 255.255.254.0 {
# default gw
option routers 172.16.192.119;
# static route to new building
option classless-static-routes 192.168.10.0/24 172.16.192.149;
option classless-ms-static-routes 192.168.10.0/24 172.16.192.149;
# Ips we assign
range 172.16.192.153 172.16.192.249;
host stratus { hardware ethernet 00:00:00:00:00:01; fixed-address
172.16.192.219; }
... other host declarations ...
}
With the config as it is above, the routers option will be ignored, while
the 192.168.10.0/24 route will be set correctly.
If I comment out both classless-* options and restart the server,
"routers" will be honored and a default gateway set.
This is dhclient config:
testrat:/root{3}# cat /etc/dhclient.conf
#request subnet-mask, broadcast-address, routers, domain-name,
domain-name-servers;
require routers;
testrat:/root{4}#
No luck with and empty dhclient.conf.
Any ideas?
Thanks
Juan
Re: How pf chooses nics on bridges?
>> 06:19:08.497855 rule 17/(match) block in on vether0: 192.168.193.41.3138 >> > >> 77.234.44.65.80: tcp 0 (DF) >> 06:19:08.546275 rule 17/(match) block in on fxp0: 192.168.193.28.59751 > >> 77.234.44.76.443: tcp 0 (DF) >> 06:19:08.582708 rule 17/(match) block in on fxp0: 192.168.192.146.61276 >> > >> 23.202.94.13.80: tcp 0 (DF) >> 06:19:08.869587 rule 17/(match) block in on vether0: 192.168.193.12.2103 >> > >> 77.234.44.77.443: tcp 0 (DF) >> 06:19:08.872942 rule 17/(match) block in on vether0: 192.168.193.12.2104 >> > >> 77.234.42.76.443: tcp 0 (DF) >> 06:19:09.000769 rule 17/(match) block in on vether0: 192.168.193.41.3138 >> > >> 77.234.44.65.80: tcp 0 (DF) >> 06:19:09.046083 rule 17/(match) block in on fxp0: 192.168.193.28.59751 > >> 77.234.44.76.443: tcp 0 (DF) >> >> >> Why is it that blocked packets appear sometimes on fxp0 and sometimes on >> vether0? > > it's simply the interface the packet came in on. > Thank you. I get that. The question is why sometimes it logs fxp0 and sometimes is vether0 as both are the same physical nic?
How pf chooses nics on bridges?
Hello We have a 5.6-stable box doing transparent filtering with pf. blog log all is default on ruleset. The bridge is composed of fxp0 and vether0 on int net 192.168.192/23 and xl0 (internet). While doing normal work pflog0 shows this: 06:19:08.497855 rule 17/(match) block in on vether0: 192.168.193.41.3138 > 77.234.44.65.80: tcp 0 (DF) 06:19:08.546275 rule 17/(match) block in on fxp0: 192.168.193.28.59751 > 77.234.44.76.443: tcp 0 (DF) 06:19:08.582708 rule 17/(match) block in on fxp0: 192.168.192.146.61276 > 23.202.94.13.80: tcp 0 (DF) 06:19:08.869587 rule 17/(match) block in on vether0: 192.168.193.12.2103 > 77.234.44.77.443: tcp 0 (DF) 06:19:08.872942 rule 17/(match) block in on vether0: 192.168.193.12.2104 > 77.234.42.76.443: tcp 0 (DF) 06:19:09.000769 rule 17/(match) block in on vether0: 192.168.193.41.3138 > 77.234.44.65.80: tcp 0 (DF) 06:19:09.046083 rule 17/(match) block in on fxp0: 192.168.193.28.59751 > 77.234.44.76.443: tcp 0 (DF) vether0 is 192.168.192.119 ie in the same net as fxp0 and def gw for the net. There are no static rules for any of those destination sites. Why is it that blocked packets appear sometimes on fxp0 and sometimes on vether0? Thanks
