Re: where is the image of openbsd arm ?

[Predrag Punosevac]

http://ftp.openbsd.org/pub/OpenBSD/snapshots/armv7/

http://www.openbsd.org/armv7.html

where is the image of openbsd arm ?

[Tuyosi Takesima]

Hi all .

i now use arm linux as server .
because it needs 5W , so its cost as 24Hr server is very low
and
it's root can be put in hard disk , so big space can be get .

where is the image of openbsd arm ?
( raspberry pi , pine64 or other )
---
regards

Re: videos in httpd

[Nick Holland]

On 06/22/16 07:50, temp+...@frad.ir wrote:
>>  Hi folks
>>   For those of you running http in support of your business, are any of you 
>> providing 
>>videos for your customers ?
>>  If so what packages and set-up are you using?
>>  Any advice guidance appreciated.
> 
> Hi,
> 
> I used httpd for serving file in personal usages. I found that httpd is poor 
> for large
> files and cause consuming resources for that purpose.

This was a somewhat subtle, but interesting problem...and it is now
fixed (in -current, and will be in 6.0).

The problem was, as I recall, not an issue of "large" files itself, but
raised its head mostly on large files.  The problem was when someone
would start a file download and stop it prematurely for any reason, file
descriptors (hope I'm using the right word properly here) were not being
released.  Well, it turns out it is rather difficult to abort the
transfer of a 5k or 20k file...but a 300m file?  Easy.  And if running
something where lots of people download lots of files, seemingly
frequent...resulting in an unhappy system.

I can now say with some confidence, that I this problem has been
squished very effectively, and httpd (now) does a great job of running
at least a few OpenBSD mirrors.

Nick.

pf/routing config for two external interfaces

[Jeremy]

I have a SOHO firewall in production which has been connected to the
net via an ADSL line. We have a new fibre connection which will replace
the ADSL connection once I get the system switched over. I am having
trouble with the pf configuration during the transition period. 

What I would like to achieve is that connections come in on either
external interface and are routed appropriately to the internal network,
where I'm running a mail and web server etc. Outgoing connections should
also be handled via either interface, but this is less important.

Complicating the situation is that this is a remote setup and I need to
modify the configuration without losing connectivity to the server in
the meantime. (It's a long drive if I need to go on-site to correct any
mistakes.) I've been making changes on the fly and rebooting (which
restores defaults) if anything goes wrong.

I have attached my pf.conf where I have attempted to update the
config to handle this situation but I can't get it working correctly.
The LAN is connected on em0. The original ADSL connection is on em1 and
the new fibre link is on em2

The original installation has /etc/mygate containing 172.16.8.1 (adsl
modem)

I'm not sure that I need to modify the routing to handle inbound
connections on both interfaces but have attempted to do the following
via the shell:

# pfctl -f /etc/pf.conf.new
# route add -mpath default 192.168.1.1
# route add -mpath default 172.16.8.1
# sysctl net.inet.ip.multipath=1

I suspect I have issues with the "egress" keyword but I'm not sure how
to correctly/safely activate my configuration without losing
connectivity on one or both interfaces. Generally I can reach services
on the firewall machine itself but cannot access the internal network
services from outside. (Changing the default route usually brings
connections via the associated link, down.)

I don't actually *need* load-balancing or equal cost multipath
routing. I just want a configuration where I have two external
interfaces which both carry traffic and packets flow over the right
interface (so this looks pretty much like the same thing.)


Could someone please cast an eye over what I'm doing and point me in
the right direction. Thanks. Much appreciated.



=/etc/pf.conf.new===
# macros
int_if="em0"
ext_if1="em1"
ext_if2="em2"
ext_gw1="172.16.8.1"
ext_gw2="192.168.1.1"

lan_net="192.168.7.0/24"

tcp_services="{ 22, 113 }"
udp_services="{ 161 }"
mail_services="{ 587, 993, 995 }"
web_services="{ 80, 443 }"

icmp_types="echoreq"

web_server = "192.168.7.77"
mail_server = "192.168.7.77"

# options
set block-policy return
set loginterface egress
set skip on lo

# match rules
match in all scrub (no-df random-id max-mss 1440)
#match out on egress inet from $int_if:network to any nat-to (egress:0)
match out on $ext_if1 from $int_if:network nat-to ($ext_if1)
match out on $ext_if2 from $int_if:network nat-to ($ext_if2)

# filter rules
block in log

pass out quick

# Balance two external interfaces
pass in on $int_if from $int_if:network reply-to \
   { ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin

pass out on $ext_if1 from $ext_if2 reply-to ($ext_if2 $ext_gw2)
pass out on $ext_if2 from $ext_if1 reply-to ($ext_if1 $ext_gw1)

# Allow access to services running on the firewall
pass in on egress inet proto tcp from any to (egress) port \
$tcp_services flags S/SA keep state \
(max-src-conn-rate 5/300) 
pass in on egress inet proto udp from any to (egress) port $udp_services

# Redirect traffic to the interior servers
pass in on egress inet proto tcp from any to (egress) port \
$web_services rdr-to $web_server synproxy state \ 
(max-src-conn-rate 100/10) 
pass in on egress inet proto tcp from any to (egress) port \
$mail_services rdr-to $mail_server

# Forward SNMP on alternative port through to internal server
pass in on egress inet proto udp to (egress) port 162 \
rdr-to $web_server port 161

pass in inet proto icmp all icmp-type $icmp_types
pass in on $int_if
pass in log on $ext_if2

Re: 5.9: tar core dumps extracting a tar created on 4.8

[Listas IT]

> 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!

Re: Booting encrypted drive from another device

[lists]

> attacking the hardware or firmware is hard while attacking the
> bootloader is easy

Until software is abused in unintended ways to give access to firmware.

Remember a computer virus that bricked many main boards in the late
90ties and the response and solution the industry provided to that?

CIH (computer virus)
[https://en.wikipedia.org/wiki/CIH_(computer_virus)]

I think you made a key point here: what is within reach to an adversary
remotely is much more critical than local access exploits.  To conclude:
access and applicability of the respective attack that stays undetected.

> So if it's easy to do and the inconvenience is acceptable, it provides
> protection which is in some cases unnecessary and in some insufficient
> but is neither in all.

I've met no inconvenience applying OpenBSD measures so far, makes all
the difference.  I abandoned some other slightly inconvenient choices.

Re: 5.9: tar core dumps extracting a tar created on 4.8

[Philip Guenther]

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

Re: 5.9: tar core dumps extracting a tar created on 4.8

[trondd]

On Wed, June 22, 2016 3:14 pm, Listas IT wrote:
> 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
>

That's pledge.  Apparently your tarball contains device nodes.

Looks like dpath was added to support nodes but was missed in the pledge
call used when not also gzipping.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/pax/pax.c?rev=1.43=text/x-cvsweb-markup

Tim.

Re: 5.9: tar core dumps extracting a tar created on 4.8

[Edgar Pettijohn]

On 16-06-22 16:14:54, Listas IT wrote:
> 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
> 
It sounds like a pledge issue. Not sure how to fix it other than 
maybe try gtar.
-- 
Edgar Pettijohn

Re: Booting encrypted drive from another device

[lists]

> Ted Unangst:
> > If an adversary gains possession of your hard drive and gives it
> > back to you, throw it away.  
> 
> li...@wrant.com:
> > The advice Ted gives is much more than simply correct, it can
> > further be extended to "do NOT accept electronics from people
> > you can't accept in your trust model"
> 
> Now think about the electronic devices that you bought from people you
> don't know,

Which you choose to trust.  If you know this party is out of your trust
model, simply not accept back any "tampered" device they return to you.

> At the moment we have only small bits of verifiable hardware/OSHW so
> it's impossible to have "one solution" that covers all the threat
> models, unfortunately.

Indeed, but worth trying and eventually enumerate and close more models.
I observe OpenBSD goes to more length than any other open free software.

Re: internet connection issues

[Edgar Pettijohn]

Sent from my iPhone

> On Jun 22, 2016, at 2:05 PM, Sonic  wrote:
>
> Have a client whose Internet connection is less then reliable. It's
> cable service and the cable company always claims there is nothing
> wrong on their end. Of course the service is intermittent and by the
> time the onsite clerk calls the ISP it's usually back up and always by
> the time they get someone sent out.
>
> The problem is ongoing - it was a problem before I took over the
> account, and is still a problem even though the previous firewall has
> been replaced with a shiny OpenBSD box and the previous rented cable
> modem has also been replaced with a shiny new Arris model (separated
> by a few months).
>
> I discovered that when the problem occurs I (of course) cannot connect
> to the firewall remotely, nor can I ping it. However I can ping the
> gateway node. Which to me says the problem is between the ISP gateway
> node and the cable modem. Two cable modems with the same issue lead me
> to discount them as the problem, and two firewalls with the same
> problem are a bit far fetched as well. Plus the OpenBSD firewall logs
> no errors, either in dmesg or any other log file.
>
> I would like to be able to provide a way to document the outage no
> matter when it occurs both via some job running on the firewall and a
> job running remotely - to be positive that when the Internet cannot be
> seen from the firewall the problem is at the suspected gateway node
> and that at the same time the remote job can verify that the gateway
> node can be seen but the firewall cannot, creating logs in both
> systems only during the outage times. All of this possibly under the
> mistaken idea that I can actually get WOW to repair their service.
>
> Would like some suggestions on ways to about this.
>
> Thanks,
>
> Chris
>

Ifstated(8) may be useful. Not really it's purpose, but you can set it up to
ping each box and the outside world. I think it will log it's ping status. Not
sure how the config would look, but I think it's worth a look.

5.9: tar core dumps extracting a tar created on 4.8

[Listas IT]

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

Re: Booting encrypted drive from another device

[Ivan Markin]

Ted Unangst:
> If an adversary gains possession of your hard drive and gives it back to you,
> throw it away.

li...@wrant.com:
> The advice Ted gives is much more than simply correct, it can further
> be extended to "do NOT accept electronics from people you don't know":

Now think about the electronic devices that you bought from people you
don't know, produced by people you don't know using design that is known
only by people you don't know [maybe s/know/trust/g].
At the moment we have only small bits of verifiable hardware/OSHW so
it's impossible to have "one solution" that covers all the threat
models, unfortunately. One should consider their threat models
exaggerating their "depth" to allow the moving towards free hardware.

Moving your bootloader away from semi-trusted encrypted drive is going
to defend you against EvilMaid and friends by *some adversaries* and
within *some threat models*.

--
Ivan Markin

internet connection issues

[Sonic]

Have a client whose Internet connection is less then reliable. It's
cable service and the cable company always claims there is nothing
wrong on their end. Of course the service is intermittent and by the
time the onsite clerk calls the ISP it's usually back up and always by
the time they get someone sent out.

The problem is ongoing - it was a problem before I took over the
account, and is still a problem even though the previous firewall has
been replaced with a shiny OpenBSD box and the previous rented cable
modem has also been replaced with a shiny new Arris model (separated
by a few months).

I discovered that when the problem occurs I (of course) cannot connect
to the firewall remotely, nor can I ping it. However I can ping the
gateway node. Which to me says the problem is between the ISP gateway
node and the cable modem. Two cable modems with the same issue lead me
to discount them as the problem, and two firewalls with the same
problem are a bit far fetched as well. Plus the OpenBSD firewall logs
no errors, either in dmesg or any other log file.

I would like to be able to provide a way to document the outage no
matter when it occurs both via some job running on the firewall and a
job running remotely - to be positive that when the Internet cannot be
seen from the firewall the problem is at the suspected gateway node
and that at the same time the remote job can verify that the gateway
node can be seen but the firewall cannot, creating logs in both
systems only during the outage times. All of this possibly under the
mistaken idea that I can actually get WOW to repair their service.

Would like some suggestions on ways to about this.

Thanks,

Chris

Re: Problem with default route on Carp

[Jean-Daniel Dupas]

> Le 22 juin 2016 à 20:56, rizz2pro .  a écrit :
>
>
> On Jun 22, 2016 12:19 PM, "Jean-Daniel Dupas" > wrote:
> >
> > Hello,
> >
> > I'm trying to configure a basic router with carp enabled (as describe in
the
> > OpenBSD manual).
> >
> > My server has one primary interface (vio0) with an IP used to access it
> > directly (whatever the CARP interface status is): 10.0.11.1/16

> >
> > It provides a shared interface on carp0 with the IP: 10.0.10.1/16

> >
> > I want to set the default route on the carp iface, so the public IP when
> > connecting a remote host is the carp IP.
> >
> > The problem is when I do that, the system completely ignore the default
route
> > and always return a "no route to host" error when I try to access the
> > network.
> >
> > My config is as follow:
> >
> >  ifconfig
> > lo0: flags=8049 mtu 32768
> > priority: 0
> > groups: lo
> > inet6 ::1 prefixlen 128
> > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
> > inet 127.0.0.1 netmask 0xff00
> > vio0: flags=8b43
mtu
> > 1500
> > lladdr 52:54:00:60:00:a2
> > priority: 0
> > media: Ethernet autoselect
> > status: active
> > inet 10.0.11.1 netmask 0x broadcast 10.0.255.255
> > carp0: flags=8843 mtu 1500
> > lladdr 00:00:5e:00:01:f3
> > priority: 15
> > carp: MASTER carpdev vio0 vhid 243 advbase 1 advskew 0
> > groups: carp egress
> > status: master
> > inet 10.0.10.1 netmask 0x broadcast 10.0.255.255
> >
> >  netstat -rn
> > Routing tables
> >
> > Internet:
> > DestinationGatewayFlags   Refs  Use   Mtu  Prio
Iface
> > default10.0.0.1   UGS48 -23
carp0
> > 10.0/1610.0.11.1  UCP2  396 - 4
vio0
> > 10.0/1610.0.10.1  UCP00 - 4
carp0
> > 10.0.0.1   00:00:5e:00:01:01  UHLc   0  129 - 4
vio0
> > 10.0.3.10  ac:87:a3:1d:3f:9d  UHLc   1   50 - 4
vio0
> > 10.0.10.1  00:00:5e:00:01:f3  UHLl   0  444 - 1
carp0
> > 10.0.11.1  52:54:00:60:00:a2  UHLl   0  118 - 1
vio0
> > 10.0.255.255   10.0.11.1  UHPb   0   40 - 1
vio0
> > 10.0.255.255   10.0.10.1  UHPb   00 - 1
carp0
> > 127/8  127.0.0.1  UGRS   00 32768 8
lo0
> > 127.0.0.1  127.0.0.1  UHl00 32768 1
lo0
> > 224/4  127.0.0.1  URS0  976 32768 8
lo0
> >
> >  ping 8.8.8.8
> > PING 8.8.8.8 (8.8.8.8): 56 data bytes
> > ping: sendto: No route to host
> >
> > -- uname -a
> > OpenBSD hostname 6.0 GENERIC.MP#2208  amd64
> >
> > Note: that config work perfectly on OpenBSD 5.7 but fails on OpenBSD 5.9
and
> > current
> >
> Can you post your pf.conf?
>
pf is disabled. I did that to remove it from the equation until I solve that
issue.

Re: Booting encrypted drive from another device

[lists]

> If an adversary gains possession of your hard drive and gives it back
> to you, throw it away.

The advice Ted gives is much more than simply correct, it can further
be extended to "do NOT accept electronics from people you don't know":

OHM2013 Hard disks: More than just block devices
[https://www.youtube.com/watch?v=0Da6OARhgXk]

This video shows what you could find out independently about storage
controller boards: they've become as complex as separate computers..

At any rate the device could just crash, fry or burn down physically.
Or plain sleep, snoop or in other ways be that remote control vector.

Re: Booting encrypted drive from another device

[Theodoros]

It doesn't have to be always thrown away.

After some thinking, it could make a good entrapment technique.

1) create an unencrypted /boot volume and save a healthy offline
(usb?) backup you can use for comparison
2) hashcheck (from a usb-boot environment) and then boot normally the
system if check is OK
3) repeat 2 until check is NOT OK, make copy of failed /boot volume and examine.
4) win.




On 22 June 2016 at 19:52, Ted Unangst  wrote:
> Theodoros wrote:
>> Fair point!
>> It would make it more complicated for an adversary, but not impossible.
>
> If an adversary gains possession of your hard drive and gives it back to you,
> throw it away.

Re: Booting encrypted drive from another device

[Ted Unangst]

Theodoros wrote:
> Fair point!
> It would make it more complicated for an adversary, but not impossible.

If an adversary gains possession of your hard drive and gives it back to you,
throw it away.

Problem with default route on Carp

[Jean-Daniel Dupas]

Hello,

I'm trying to configure a basic router with carp enabled (as describe in the
OpenBSD manual).

My server has one primary interface (vio0) with an IP used to access it
directly (whatever the CARP interface status is): 10.0.11.1/16

It provides a shared interface on carp0 with the IP: 10.0.10.1/16

I want to set the default route on the carp iface, so the public IP when
connecting a remote host is the carp IP.

The problem is when I do that, the system completely ignore the default route
and always return a "no route to host" error when I try to access the
network.

My config is as follow:

 ifconfig
lo0: flags=8049 mtu 32768
priority: 0
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
inet 127.0.0.1 netmask 0xff00
vio0: flags=8b43 mtu
1500
lladdr 52:54:00:60:00:a2
priority: 0
media: Ethernet autoselect
status: active
inet 10.0.11.1 netmask 0x broadcast 10.0.255.255
carp0: flags=8843 mtu 1500
lladdr 00:00:5e:00:01:f3
priority: 15
carp: MASTER carpdev vio0 vhid 243 advbase 1 advskew 0
groups: carp egress
status: master
inet 10.0.10.1 netmask 0x broadcast 10.0.255.255

 netstat -rn
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default10.0.0.1   UGS48 -23 carp0
10.0/1610.0.11.1  UCP2  396 - 4 vio0
10.0/1610.0.10.1  UCP00 - 4 carp0
10.0.0.1   00:00:5e:00:01:01  UHLc   0  129 - 4 vio0
10.0.3.10  ac:87:a3:1d:3f:9d  UHLc   1   50 - 4 vio0
10.0.10.1  00:00:5e:00:01:f3  UHLl   0  444 - 1 carp0
10.0.11.1  52:54:00:60:00:a2  UHLl   0  118 - 1 vio0
10.0.255.255   10.0.11.1  UHPb   0   40 - 1 vio0
10.0.255.255   10.0.10.1  UHPb   00 - 1 carp0
127/8  127.0.0.1  UGRS   00 32768 8 lo0
127.0.0.1  127.0.0.1  UHl00 32768 1 lo0
224/4  127.0.0.1  URS0  976 32768 8 lo0

 ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: No route to host

-- uname -a
OpenBSD hostname 6.0 GENERIC.MP#2208 amd64

Note: that config work perfectly on OpenBSD 5.7 but fails on OpenBSD 5.9 and
current

ospfd failed to form adjacency on interface bnx0

[Marko Cupać]

Hi,

I am getting these in my daemon log:

Jun 22 15:40:33 nat1 ospfd[30419]: nbr_adj_timer: failed to form adjacency
with 192.168.225.1 on interface bnx0
Jun 22 15:40:36 nat1 ospfd[30419]: recv_db_description: neighbor ID
192.168.225.1: invalid seq num, mine a2654368 his a2645af6
Jun 22 15:40:46 nat1 ospfd[30419]: recv_db_description: neighbor ID
192.168.225.1: invalid seq num, mine a2654368 his a2645af6
Jun 22 15:40:48 nat1 ospfd[30419]: recv_db_description: neighbor ID
192.168.225.1: invalid seq num, mine a2654368 his a2645af7
Jun 22 15:41:10 nat1 last message repeated 4 times

This is on 5.9 with errata patches up to 011 applied.

ospfd.conf is quite basic:

router-priority 0
router-id 192.168.225.2
area 0.0.0.0 {
interface bnx0 { metric 100 }
}

Here's dmesg:

OpenBSD 5.9 (GENERIC.MP) #4: Wed Jun 15 21:44:03 CEST 2016
pac...@nat1.example.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2128887808 (2030MB)
avail mem = 2060226560 (1964MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xee000 (69 entries)
bios0: vendor HP version "P58" date 05/02/2011
bios0: HP ProLiant DL360 G5
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP SPCR MCFG HPET SPMI ERST APIC  BERT HEST SSDT
acpi0: wakeup devices PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 2500.46 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM
2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,LONG,LAHF,PERF,SENSOR
cpu0: 6MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 333MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 2000.08 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM
2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,LONG,LAHF,PERF,SENSOR
cpu1: 6MB 64b/line 16-way L2 cache
cpu1: smt 0, core 2, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 2500.09 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM
2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,LONG,LAHF,PERF,SENSOR
cpu2: 6MB 64b/line 16-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 2500.09 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM
2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,LONG,LAHF,PERF,SENSOR
cpu3: 6MB 64b/line 16-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
ioapic1 at mainbus0: apid 9 pa 0xfec8, version 20, 24 pins
acpiprt0 at acpi0: bus 1 (IP2P)
acpiprt1 at acpi0: bus 11 (IPE1)
acpiprt2 at acpi0: bus 10 (IPE4)
acpiprt3 at acpi0: bus 16 (P2P2)
acpiprt4 at acpi0: bus 9 (PT02)
acpiprt5 at acpi0: bus 6 (PT03)
acpiprt6 at acpi0: bus 19 (PT04)
acpiprt7 at acpi0: bus 3 (NB01)
acpiprt8 at acpi0: bus 5 (NB02)
acpiprt9 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: !C3(250@17 io@0x915), C1(1000@1 halt)
acpicpu1 at acpi0: !C3(250@17 io@0x915), C1(1000@1 halt)
acpicpu2 at acpi0: !C3(250@17 io@0x915), C1(1000@1 halt)
acpicpu3 at acpi0: !C3(250@17 io@0x915), C1(1000@1 halt)
acpitz0 at acpi0: critical temperature is 31 degC
ipmi at mainbus0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 5000P Host" rev 0xb1
ppb0 at pci0 dev 2 function 0 "Intel 5000 PCIE" rev 0xb1
pci1 at ppb0 bus 9
ppb1 at pci1 dev 0 function 0 "Intel 6321ESB PCIE" rev 0x01
pci2 at ppb1 bus 10
ppb2 at pci2 dev 0 function 0 "Intel 6321ESB PCIE" rev 0x01
pci3 at ppb2 bus 11
ppb3 at pci2 dev 1 function 0 "Intel 6321ESB PCIE" rev 0x01
pci4 at ppb3 bus 14
ppb4 at pci2 dev 2 function 0 "Intel 6321ESB PCIE" rev 0x01
pci5 at ppb4 bus 15
ppb5 at pci1 dev 0 function 3 "Intel 6321ESB PCIE-PCIX" rev 0x01
pci6 at ppb5 bus 16
ppb6 at pci0 dev 3 function 0 "Intel 5000 PCIE" rev 0xb1
pci7 at ppb6 bus 6
ciss0 at pci7 dev 0 function 0 "Hewlett-Packard Smart Array" rev 0x04: apic 8
int 16
ciss0: 1 LD, HW rev 4, FW 7.24/7.24, 64bit fifo
scsibus1 at ciss0: 1 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed
sd0: 139979MB, 512 bytes/sector, 286677120 sectors
ppb7 at pci0 dev 4 function 0 "Intel 5000 PCIE x8" rev 0xb1
pci8 at ppb7 bus 19
em0 at pci8 dev 0 function 0 

Re: videos in httpd

[lists]

On 6/22/2016 6:51 AM, temp+...@frad.ir wrote:
> I used httpd for serving file in personal usages. I found that httpd is poor 
> for large
> files and cause consuming resources for that purpose.
> 
> I recommend using another http server, like nginx (I don't test that) or 
> write a cgi
> (fcgi) for that purpose.

I found that adding the file extensions to mime types into httpd.conf
solved my problem and allowed streaming of video and music files.

I was serving lots of large files and they would eat up all my ram and
crashing httpd. I compared nginx's mime types to httpd and added in the
ones for my large files and have never had another issue.

Re: videos in httpd

[Kevin Chadwick]

> >  Hi folks
> >   For those of you running http in support of your business, are any of you 
> > providing 
> >videos for your customers ?
> >  If so what packages and set-up are you using?
> >  Any advice guidance appreciated.  
> 
> Hi,
> 
> I used httpd for serving file in personal usages. I found that httpd is poor 
> for large
> files and cause consuming resources for that purpose.
> 
> I recommend using another http server, like nginx (I don't test that) or 
> write a cgi
> (fcgi) for that purpose.


Really? Is this unstated resource consumption saturated before your
bandwidth is?

If you expect your users to actually watch your whole video then
streaming isn't really required to save bandwidth and so you can avoid
javascript with a simple html5  element and just httpd is
required.

Otherwise why not host it on youtube and just add the link to your site?

-- 

KISSIS - Keep It Simple So It's Securable

Re: Long life on SSD in a firewall environment

[Kenneth Gober]

On Tue, Jun 21, 2016 at 10:47 AM, Gregory Edigarov  wrote:
> well, but why not just settup syslogd to fan logs out to some other server?

the reason I don't do that is because the sites where I have such firewalls
deployed don't have any other servers.  I don't want to ship logs over VPN
links because those links are not particularly fast.

at my 'main' site the firewall is a bigger box with a bigger disk and
I don't use
MFS for /var/log there.  if I were doing so I would certainly consider having
syslogd forward logs elsewhere because in general it's a good practice.

-ken

Re: videos in httpd

[temp+101]

>  Hi folks
>   For those of you running http in support of your business, are any of you 
> providing 
>videos for your customers ?
>  If so what packages and set-up are you using?
>  Any advice guidance appreciated.

Hi,

I used httpd for serving file in personal usages. I found that httpd is poor 
for large
files and cause consuming resources for that purpose.

I recommend using another http server, like nginx (I don't test that) or write 
a cgi
(fcgi) for that purpose.

Re: IPv6 fragmentation woes

[Laurent CARON]

Hi,

After some more tests:

Source: Linux machine with IPv6: 2a02:27d0:0:5e0d:1a03:73ff:feba:50b4
Destination: Linux machine with IPv6: 2a02:27d0:0:5e0d:428d:5cff:fea5:501e

source# ping6 -M do -s 1300 2a02:27d0:0:5e0d:428d:5cff:fea5:501e
destination# tcpdump -ni enp3s0 host 2a02:27d0:0:5e0d:1a03:73ff:feba:50b4
09:38:55.735387 IP6 2a02:27d0:0:5e0d:1a03:73ff:feba:50b4 > 
2a02:27d0:0:5e0d:428d:5cff:fea5:501e: ICMP6, echo request, seq 1, length 1308
09:38:55.735826 IP6 2a02:27d0:0:5e0d:428d:5cff:fea5:501e > 
2a02:27d0:0:5e0d:1a03:73ff:feba:50b4: ICMP6, echo reply, seq 1, length 1308
09:38:56.736882 IP6 2a02:27d0:0:5e0d:1a03:73ff:feba:50b4 > 
2a02:27d0:0:5e0d:428d:5cff:fea5:501e: ICMP6, echo request, seq 2, length 1308
09:38:56.736998 IP6 2a02:27d0:0:5e0d:428d:5cff:fea5:501e > 
2a02:27d0:0:5e0d:1a03:73ff:feba:50b4: ICMP6, echo reply, seq 2, length 1308
...

Source: Linux machine with IPv6: 2a02:27d0:0:5e0d:1a03:73ff:feba:50b4
Destination machine OpenBSD 5.8 with IPv6: 2a02:27d0:0:5e0c:d6be:d9ff:fe95:a236

source# ping6 -M do -s 1300 2a02:27d0:0:5e0c:d6be:d9ff:fe95:a236
destination# tcpdump -ni bge0 host 2a02:27d0:0:5e0d:1a03:73ff:feba:50b4
17:58:03.040184 2a02:27d0:0:5e0d:1a03:73ff:feba:50b4 > 
2a02:27d0:0:5e0c:d6be:d9ff:fe95:a236: icmp6: echo request [flowlabel 0x467ca]
17:58:03.040295 2a02:27d0:0:5e0c:d6be:d9ff:fe95:a236 > 
2a02:27d0:0:5e0d:1a03:73ff:feba:50b4: frag (0x04183a32:1232@0+) icmp6: echo 
reply
17:58:03.040296 2a02:27d0:0:5e0c:d6be:d9ff:fe95:a236 > 
2a02:27d0:0:5e0d:1a03:73ff:feba:50b4: frag (0x04183a32:76@1232)
17:58:04.034362 2a02:27d0:0:5e0d:1a03:73ff:feba:50b4 > 
2a02:27d0:0:5e0c:d6be:d9ff:fe95:a236: icmp6: echo request [flowlabel 0x467ca]
17:58:04.034430 2a02:27d0:0:5e0c:d6be:d9ff:fe95:a236 > 
2a02:27d0:0:5e0d:1a03:73ff:feba:50b4: frag (0x36bc0632:1232@0+) icmp6: echo 
reply
17:58:04.034432 2a02:27d0:0:5e0c:d6be:d9ff:fe95:a236 > 
2a02:27d0:0:5e0d:1a03:73ff:feba:50b4: frag (0x36bc0632:76@1232)

source: Linux machine with IPv6: 2a02:27d0:0:5e0d:1a03:73ff:feba:50b4
Destination machine OpenBSD 5.8 with IPv6: 2a02:27d0:0:5e0c:d6be:d9ff:fe95:a236

source# ping6 -M do -s 1232 2a02:27d0:0:5e0c:d6be:d9ff:fe95:a236
leads to answers fitting in one packet only (1280 byte) with no
fragmentation whatsoever.

source# ping6 -M do -s 1233 leads to fragmentation

==
I wonder why ICMPv6 answers bigger than 1232 are always fragmented.
==

# netstat -rnf inet6 | grep bge0
defaultfe80::42b4:f0ff:fec6:7201%bge0 UG 0  
211 -56 bge0 
2a02:27d0:0:5e0c::/64  fe80::d6be:d9ff:fe95:a236%bge0 UC 0  
  0 - 4 bge0 
fe80::%bge0/64 fe80::d6be:d9ff:fe95:a236%bge0 UC 1  
  0 - 4 bge0 
fe80::42b4:f0ff:fec6:7201%bge0 40:b4:f0:c6:72:01  UHLc   1  
 13 - 4 bge0 
fe80::d6be:d9ff:fe95:a236%bge0 d4:be:d9:95:a2:36  UHLl   0  
  0 - 1 lo0  
ff01::%bge0/32 fe80::d6be:d9ff:fe95:a236%bge0 UC 0  
  0 - 4 bge0 
ff02::%bge0/32 fe80::d6be:d9ff:fe95:a236%bge0 UC 0  
  0 - 4 bge0 

Please note, replacing bge0 with em0 leads to the very same result,
ruling out a difference of ICMPv6 handling between the 2 drivers.