Re: growfs(8) to lower offset
On Tue, Nov 06, 2018 at 09:18:27AM -0500, David Higgs wrote: > > As the FAQ entry states, you can use growfs(8) if the empty space > > is after the existing partition, not prior. You can only grow a > > partition "down", never "up". What you want to do would require the > > following steps: > > > > 1. Create a new partition on the free space > > 2. Move all data to the new partition > > 3. Remove the existing /project partition > > 4. Use growfs(8) on the new partition to include the space from the old > >/project partition > > You appear to be right - I see it now. I had not read closely enough, > and had focused more on what I could change with the 'm' disklabel(8) > command. It would be nice if this info were made explicit in the > growfs(8) man page as well. > > I had already successfully rearranged some partitions using the method > you propose, but unfortunately the amount of data in /project is > slightly too big to be easily shifted into my remaining free space. > I'll try to compress it or temporarily move the data off-system. > I use growfs a lot. I try to plan ahead of time to put partitions that I can sacrifice when I desperately need to possibly grow something like /usr/local or some other important partition. Sometimes I have a partition for the PKG_CACHE when I need to avoid downloading the packages twice for another computer. This is a partition, for me, that I can sacrifice and use to grow the preceding partition. Buy a bigger disk is not always a practical answer. If you haven't already done it, taking a picture of disklabel, fstab and df never hurt. Easier than writing it down. Well, I've been in your position pulling out hairs many times. Worst case is having a small useless partition stuck in the middle somewhere. Good Luck, Chris Bennett
Re: performance of intel multithreading
On 11/05/18 23:51, Kihaguru Gathura wrote: > Hi, > > From a security standpoint, > which platform will offer better performance huh? What's your priority, security or performance? > solution in web and database now that OpenBSD > multithreading is switched off for Intel? > > > (Fujitsu PRIMEPOWER 250 - Version F - 2 X SPARC64 V 1.98 GHz) a very old, SCSI based computer. > or > (Fujitsu PRIMERGY RX300 S6 - 2 X Xeon 6 core 12 thread E5620 2.4 > GHz) A not quite as old SATA/SAS system (but still hardly new). If you have both, do your own benchmarks. If you have one and no budget to buy something ...um... modern, use it. If you have neither, buy something ELSE. My guess is that the Intel powered system will outrun the SPARC system in raw performance in every measure you make. Probably won't even need to use a stopwatch to compare. And a modern laptop will embarrass both of them, multi-threading or not. I'd not put a SCSI system into production as you won't find too many drives less than ten years old, and they are tiny, power hungry, and slow by modern disk standards. At least the SAS based system, you can get new drives for, or even stock it with SSDs and really have fun. Security? Eh. I suspect you aren't getting ROM updates for either. If someone pops your system security and tries to run a binary on it, the UltraSPARC will probably give them a bigger surprise. But if you are running web services, you are probably running apps written by someone without any idea what they are doing in an interpreted language like PHP, and the exact same exploits will take out either platform, because the exploits will be at a much higher level than the processor. Nick.
malloc.conf heads up
Hi, We are moving away from the /etc/malloc.conf symbolic link to a new sysctl: $ sysctl vm.malloc_conf vm.malloc_conf=C This will allow unveiled and chrooted processes to access the malloc options without having to do anything special in the code or chroot dir. As I often get this question: for some extra protection, use C or CJ, accept some performance impact. For development, bug hunting and/or extra securty use S, with more performance impact. Note that with default options, malloc already has quite some protection features. Upcoming snapshots will contain this. -Otto
Re: malloc.conf heads up
On Wed, Nov 07, 2018 at 07:26:21AM +0100, Otto Moerbeek wrote: > Hi, > > We are moving away from the /etc/malloc.conf symbolic link to a new sysctl: > > $ sysctl vm.malloc_conf > vm.malloc_conf=C > > This will allow unveiled and chrooted processes to access the malloc > options without having to do anything special in the code or chroot > dir. > > As I often get this question: for some extra protection, use C or CJ, I meant to type C or CF! > accept some performance impact. For development, bug hunting and/or > extra securty use S, with more performance impact. > > Note that with default options, malloc already has quite some > protection features. > > Upcoming snapshots will contain this. > > -Otto >
Re: [OpenIKED] Is it impossible to differentiate the policies by dstid?
I am by no means an expert, but for my setup, in order to get multiple policies working, I had to specify both srcid and dstid for each policy on the passive peer. And then I set srcid and dstid for the policies on the active peers.
Re: [OpenIKED] Is it impossible to differentiate the policies by dstid?
The source ID does default yes, but I have a tunnel gateway for multiple VPN and I HAD to specify the dstid on the passive side as well or ONLY the last rule was picked up for the 0.0.0.0/0 of some of them as an example for all the traffic flowing via the VPN. Any overlapping routes where not going as one might think if not dstid specified. example: ikev2 "test1-flow" passive from 0.0.0.0/0 to 1.2.3.4/28 peer any dstid test1.example.com ikev2 "test2-flow" passive from 0.0.0.0/0 to 1.3.3.4/28 peer any dstid test2.example.com ikev2 "test3-flow" passive from 0.0.0.0/0 to 1.4.3.4/28 peer any dstid test3.example.com ..etc If no dstid was specified, then you didn't have all 3 above as an example working. May be it is suppose to, that I can't say for sure as the idea of it, but it sure wasn't and isn't if I remove the dstid with everything else staying the same. So what he suggested to you was valid and true. But it is your setup and you sure can do as you see fit. Hope this help anyway. Daniel On 11/6/18 3:16 PM, 雷致强 wrote: > Thanks for the input, however, I think srcid defaults to the hostname when > it’s omitted. Explicitly setting it didn’t give me any luck. > >> On Nov 7, 2018, at 2:33 AM, J Evans <3...@startmail.com> wrote: >> >> I am by no means an expert, but for my setup, in order to get multiple >> policies working, I had to specify both srcid and dstid for each policy on >> the passive peer. And then I set srcid and dstid for the policies on the >> active peers. >> >
Re: [OpenIKED] Is it impossible to differentiate the policies by dstid?
Thanks for the input, however, I think srcid defaults to the hostname when it’s omitted. Explicitly setting it didn’t give me any luck. > On Nov 7, 2018, at 2:33 AM, J Evans <3...@startmail.com> wrote: > > I am by no means an expert, but for my setup, in order to get multiple > policies working, I had to specify both srcid and dstid for each policy on > the passive peer. And then I set srcid and dstid for the policies on the > active peers. >
Re: ikev2 and road warriors setup
Hello Kim, > My question was concerning the VPN_server, is the server NATed? A.B.C.0/23 is not NATed, it is a public pool. VPN_server is not NATed. > How is A.B.C.0/23 connected to the 'rest' of the world? Router/Firewall ... I only have switches in my building. All routers/firewalls of my network are in another building, I do not know the whole network structure, devices, security policies... but I have never noticed that any ports were blocked. I can setup a IKEV2 site-to-site VPN A.B.C.D/23 <--> !A.B.C.0/23 and it works like a charm. https://community.riocities.com/openike_openbsd.html But I can not setup a VPN_server for road warriors. I have just set up a VPN_L2TP_serv on Mikrotik (A.B.C.75/23). I can connect my Win7_warrior from !A.B.C.0/23 (currently testing on GSM network). L2TP and IKEV2 use 500, 4500 ports. If L2TP works fine so I conclude that it is not any Router/FW problem. On Tue, 6 Nov 2018 07:48:37 +0100 Kim Zeitler wrote: > Good morning Radek, > > I have a suspicion ... > > > For (1), (2) and (3) VPN is working just fine with Win7_warrior and > > puffy_warrior if they are connecting from A.B.C.0/23 (it does not matter if > > warrior has public IP or it is behind NAT). The rest of the world fails to > > connect the VPN_server. > My question was concerning the VPN_server, is the server NATed? > How is A.B.C.0/23 connected to the 'rest' of the world? Router/Firewall ... > > Cheers, > Kim > > -- radek
Re: cannot perform newline in sed substitution
On Tue, Nov 06, 2018 at 09:50:09AM +0100, Damien Thiriet wrote: > Hello misc@, > > > This is OpenBSD 6.4 stable. Since 6.3, I have troubles with > newline insersion in sed replacement pattern. I remember > doing it in previous versions. I bet I forgot the good way > to do it, but I am not sure. > When I do > > echo \\page > foo > sed "s/\\page/\ > \\stopDiapo/" foo > The output is > une \stopDiapo > > I expected > une > \stopDiapo > > I tried this both in st and xterm. > echo $LC_CTYPE gives fr_FR.UTF-8 > > What am I doing wrong? > Thanks, > > > Damien Thiriet > The newline has to be escaped with \\ since the sed expression is within double quotes. sed "s/\\page/\\ \\stopDiapo/" foo Or, use single quotes: sed 's/\\page/\ \\stopDiapo/' foo -- Andreas Kusalananda Kähäri, National Bioinformatics Infrastructure Sweden (NBIS), Uppsala University, Sweden.
Re: ldap search fails with Let's Encrypt certificate
Le 05/11/2018 17:07, Stuart Henderson a écrit : On 2018/11/05 17:02, Joel Carnat wrote: Le 05/11/2018 16:38, Stuart Henderson a écrit : > On 2018-11-05, Joel Carnat wrote: > > Le 05/11/2018 13:48, Stuart Henderson a écrit : > > > On 2018-11-05, Joel Carnat wrote: > > > > Hi, > > > > > > > > I'm using ldap(1) to query a remote Synology Directory Server > > > > (OpenLDAP > > > > 2.4.x). > > > > Unfortunately, it fails saying: > > > >TLS failed: handshake failed: error:14004410:SSL > > > > routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure > > > >ldap: LDAP connection failed > > > > > > > > When I use the OpenLDAP ldapsearch, same arguments, I succeeds. > > > > > > > > Using openssl s_client, I could confirm that the OpenLDAP server > > > > accept > > > > TLS: > > > >New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384 > > > >Server public key is 2048 bit > > > >Secure Renegotiation IS supported > > > >Compression: NONE > > > >Expansion: NONE > > > >No ALPN negotiated > > > >SSL-Session: > > > >Protocol : TLSv1.2 > > > > (...) > > > > > > If this were a cert problem you'd get a message like this from > > > ldap(1) > > > > > > TLS failed: certificate verification failed: unable to get local > > > issuer certificate > > > ldap: LDAP connection failed > > > > > > or > > > > > > TLS failed: name `XX' not present in server certificate > > > > > > So it's not that. > > > > > > ldap(1) uses libtls which defaults to only allowing secure ciphers, > > > specifically TLSv1.2+AEAD+ECDHE:TLSv1.2+AEAD+DHE. > > > > > > ldap(1) doesn't provide a way to weaken that, though you could add > > > a call to tls_config_set_ciphers(tls_config, "compat") in > > > ldapc_connect() > > > to test if it would work. > > > > > > Or an s_client command that would force these ciphers: > > > > > > openssl s_client -cipher TLSv1.2+AEAD+ECDHE:TLSv1.2+AEAD+DHE -CAfile > > > /etc/ssl/cert.pem -connect $hostname:636 > > > > > > If not, perhaps the Synology box is using old OpenSSL without support > > > for these ciphers, or perhaps the cipher config is forcing only old > > > ciphers. FWIW this is what I am currently using on OpenBSD slapd: > > > > > > olcTLSCipherSuite: TLSv1.2+AEAD+ECDHE:TLSv1.2+AEAD+DHE > > > > olcTLSCipherSuite is, by default, empty. > > I could change it to > > "HIGH:+SSLv3:+TLSv1:MEDIUM:+SSLv2:@STRENGTH:+SHA:+MD5:!NULL" which > > doesn't solve the problem. > > When I try to set it as yours, it says: > >dn: cn=config > >changetype: modify > >replace: olcTLSCipherSuite > >olcTLSCipherSuite: TLSv1.2+AEAD+ECDHE:TLSv1.2+AEAD+DHE > > > >modifying entry "cn=config" > >ldap_modify: Other (e.g., implementation specific) error (80) > > > > From OpenBSD, the openssl commands returns: > > CONNECTED(0003) > > 13559346237984:error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 > > alert handshake failure:/usr/src/lib/libssl/ssl_pkt.c:1200:SSL alert > > number 40 > > 13559346237984:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl > > handshake failure:/usr/src/lib/libssl/ssl_pkt.c:585: > > --- > > no peer certificate available > > --- > > No client certificate CA names sent > > --- > > SSL handshake has read 7 bytes and written 0 bytes > > --- > > New, (NONE), Cipher is (NONE) > > Secure Renegotiation IS NOT supported > > Compression: NONE > > Expansion: NONE > > No ALPN negotiated > > SSL-Session: > > Protocol : TLSv1.2 > > Cipher: > > Session-ID: > > Session-ID-ctx: > > Master-Key: > > Start Time: 1541425938 > > Timeout : 7200 (sec) > > Verify return code: 0 (ok) > > --- > > > > On the syno, I can see: > > # openssl version > > OpenSSL 1.0.2o-fips 27 Mar 2018 > > # openssl ciphers -v TLSv1.2+AEAD+ECDHE:TLSv1.2+AEAD+DHE > > Error in cipher list > > 139812538357392:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no > > cipher match:ssl_lib.c:1383: > > > > Does this definitively indicates "ldap search" won't work with > > OpenLDAP/OpenSSL shipped in Synology DSM ? > > > > > > Oh, I see this cipher list syntax wasn't available in 1.0.x, > to check you'll need to expand it (on libressl or openssl 1.1) and > pass the whole string in. e.g. try this > > openssl ciphers > ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256 > > and see which if any are available with their 1.0.2o-fips build. > > If there's no common cipher then "ldap search" can't work with > TLS without patching. This gives: # openssl ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256
cannot perform newline in sed substitution
Hello misc@, This is OpenBSD 6.4 stable. Since 6.3, I have troubles with newline insersion in sed replacement pattern. I remember doing it in previous versions. I bet I forgot the good way to do it, but I am not sure. When I do echo \\page > foo sed "s/\\page/\ \\stopDiapo/" foo The output is une \stopDiapo I expected une \stopDiapo I tried this both in st and xterm. echo $LC_CTYPE gives fr_FR.UTF-8 What am I doing wrong? Thanks, Damien Thiriet
Re: growfs(8) to lower offset
On Tue, Nov 6, 2018 at 8:58 AM Bruno Flueckiger wrote: > > On 05.11.18 19:47, David Higgs wrote: > > I read both the FAQ section and the growfs(8) man page but I am not > > yet confident that what I want to do is supported / safe. > > > > http://www.openbsd.org/faq/faq14.html#GrowPartition > > > > I started with a number of partitions and a bunch of free space. I > > later needed the free space and allocated a /project partition that > > went to the end of my disk. More recently, I emptied the /data > > partition immediately prior. Now I would like to use growfs(8) to > > merge this unused space with the /project partition without losing any > > of the existing data. > > > > See disklabel output below. I have only grown partitions "down", > > never in the other direction. Am I being overly paranoid? > > > > Thanks. > > > > --david > > > > As the FAQ entry states, you can use growfs(8) if the empty space > is after the existing partition, not prior. You can only grow a > partition "down", never "up". What you want to do would require the > following steps: > > 1. Create a new partition on the free space > 2. Move all data to the new partition > 3. Remove the existing /project partition > 4. Use growfs(8) on the new partition to include the space from the old >/project partition You appear to be right - I see it now. I had not read closely enough, and had focused more on what I could change with the 'm' disklabel(8) command. It would be nice if this info were made explicit in the growfs(8) man page as well. I had already successfully rearranged some partitions using the method you propose, but unfortunately the amount of data in /project is slightly too big to be easily shifted into my remaining free space. I'll try to compress it or temporarily move the data off-system. Thanks for the clue-stick. --david
Re: growfs(8) to lower offset
On 05.11.18 19:47, David Higgs wrote: > I read both the FAQ section and the growfs(8) man page but I am not > yet confident that what I want to do is supported / safe. > > http://www.openbsd.org/faq/faq14.html#GrowPartition > > I started with a number of partitions and a bunch of free space. I > later needed the free space and allocated a /project partition that > went to the end of my disk. More recently, I emptied the /data > partition immediately prior. Now I would like to use growfs(8) to > merge this unused space with the /project partition without losing any > of the existing data. > > See disklabel output below. I have only grown partitions "down", > never in the other direction. Am I being overly paranoid? > > Thanks. > > --david > As the FAQ entry states, you can use growfs(8) if the empty space is after the existing partition, not prior. You can only grow a partition "down", never "up". What you want to do would require the following steps: 1. Create a new partition on the free space 2. Move all data to the new partition 3. Remove the existing /project partition 4. Use growfs(8) on the new partition to include the space from the old /project partition Cheers, Bruno
