Re: warn: smtpd: parent_forward_open
Hello Edgar,
Thank you for your answser. I created the user exactly as written on the page
you specified.
The smtpd.conf has nothing really special that's why I posted the only lines
that were of interest.
But you are right, if smtpd is looking for the .forward in the user's home
directory the error message doesn't surprise me.
=>> Maybe the error message could be a bit more explicit because we tend to
search what's going wrong in the smtpd.conf file
The idea behind is that I don't want to have my mails in /var. I wanted my
mails to be on a specific partition and also on a different machine with a nfs
share
* The logs
Jan 7 11:16:30 serv1 smtpd[46249]: e3402a16880c5076 mta event=connecting
address=smtp://127.0.0.1:10023 host=localhost
Jan 7 11:16:30 serv1 smtpd[46249]: e3402a16880c5076 mta event=connected
Jan 7 11:16:30 serv1 clamsmtpd: 11: accepted connection from: 127.0.0.1
Jan 7 11:16:30 serv1 smtpd[46249]: e3402a17756e7ba5 smtp event=connected
address=127.0.0.1 host=localhost
Jan 7 11:16:30 serv1 smtpd[60943]: warn: smtpd: parent_forward_open:
/var/mail/_vmail: No such file or directory
* The configuration
table domaines file:/etc/mail/domaines
table spamdomaines file:/etc/mail/spamdomaines
table aliases file:/etc/mail/aliases
table utilisateurs file:/etc/mail/utilisateurs
table courriels file:/etc/mail/courriels
table passwords file:/etc/mail/passwords
table clients file:/etc/mail/clients
table gmail_secrets file:/etc/mail/gmail.passwords
# Les messages expires depuis 4h sont renvoyes a l'emetteur
expire 4h
max-message-size 50M
# Evite ipv6 pour le domaine gmail.com
limit mta for domain gmail.com inet4
pki serv1.domaine1.net certificate
"/etc/ssl/certs/serv1.domaine1.net_chaine.crt"
pki serv1.domaine1.net key "/etc/ssl/private/serv1.domaine1.net.key"
pki serv1.domaine2.fr certificate "/etc/ssl/certs/serv1.domaine1.fr_chaine.crt"
pki serv1.domaine2 key "/etc/ssl/private/serv1.domaine1.fr.key"
#
# CONFIGURATION POUR COURRIELS ENTRANTS #
#
listen on 127.0.0.1 port 10024 tag CLAM_IN # Emails provenant de Clamav
listen on 127.0.0.1 port 10028 tag DKIM_IN # Emails provenant de dkimproxy
# Rejette les domaines spammers
reject sender for any
# Accepte la reception pour tous les vdoms et vusers au format maildir
accept tagged CLAM_IN for domain virtual deliver to
maildir "/home/mail/%{dest.domain:lowercase}/%{dest.user:lowercase}/Maildir"
accept tagged CLAM_IN for local alias deliver to maildir
"/home/mail/%{rcpt.domain:lowercase}/%{dest.user:lowercase}/Maildir"
accept tagged DKIM_IN for any relay via smtp://127.0.0.1:10023
accept from source for domain relay via
smtp://127.0.0.1:10027
accept from any sender ! for domain relay via
smtp://127.0.0.1:10027
#
# CONFIGURATION POUR COURRIELS SORTANTS #
#
listen on 127.0.0.1
listen on 127.0.0.1 port 10026 tag CLAM_OUT # Emails provenant de Clamav
listen on 127.0.0.1 port 10030 tag DKIM_OUT # Emails provenant de dkimproxy
listen on 10.255.89.250 port 25
listen on 10.255.89.250 port 587 tls-require pki serv1.domaine1.net auth
# Emails recus du site web avec l adresse t...@tata.fr, on s authentifie sur
GMail
accept tagged CLAM_OUT from source sender " t...@domaine2.fr" for any
relay via tls+auth://la...@smtp.gmail.com:587 auth
# Les mails taggues CLAM_OUT recus depuis Clamav_out sont relayes vers dkimproxy
accept tagged CLAM_OUT for any relay via smtp://127.0.0.1:10029
accept tagged DKIM_OUT for any relay
# Les mails recu des clients locaux ou sur des reseaux autorises sont envoyes a
clamsmtpd-out pour inspection
accept from local for any relay via smtp://127.0.0.1:10025
accept from source for any relay via smtp://127.0.0.1:10025
Le samedi 6 janvier 2018 à 17:00:55 UTC+1, Edgar Pettijohn
a écrit :
On Sat, Jan 06, 2018 at 02:40:00PM +, Mik J wrote:
> Hello Edgar,
> I just found that the path is related to the home directory of the virtual
> user that is specified in /etc/passwd
> If you have a configuration that uses virtual users and that relies on a unix
> user _vmail then this unix user has an entry in /etc/passwd
> So the smtpd deamon uses the home directory path specified in /etc/passwd
> although it's might not be specified in the smtpd.confIs it normal that the
> home directory of that user should be used ?
>
That depends on how you have the system set up. Hard to begin without
the smtpd.conf though. How did you create this _vmail user?
# useradd -what -options _vmail
How are your users mapped to the _vmail user?
Some logs would probably help.
Basically smtpd is looking for a .forward file in /var/mail/_vmail and
warning you that there isn't one. It can probably be ignored. You should
take a look at https://opensmtpd.org/faq/example1.html.
>
>
> Le samedi 6 janvier 2018 ?? 00:52:15 UTC+1, Edgar Pettijohn
> a ??crit :
>
Re: Performance issues as KVM guest?
Same problem here. While we did have significant differences in cpu usage between FreeBSD and OpenBSD (basic OS without configuration: FreeBSD ~ 33min CPU time, OpenBSD ~ 474min CPU time - both started at the same time), with the latest kernel patches for Ubuntu 17.04 (our test environments all run Ubuntu 17.04 for KVM VMs), OpenBSD now becomes practically unusable: as soon as I su or login on the console with su, cpu usage is at 100% - the system freezes. :-/ guess we need some dedicated BSD machines to host some test-VMs ;-) Regards, Robert > Gesendet: Donnerstag, 11. Januar 2018 um 20:32 Uhr > Von: "Kirill Miazine" > An: misc@openbsd.org > Betreff: Re: Performance issues as KVM guest? > > * Kent Watsen [2018-01-11 17:38]: > [...] > > > > Since my hosting provider https://www.bytemark.co.uk/cloud-hosting/ > > > > patched for Meltdown last weekend I'm seeing significant performance > > > > issues with an OpenBSD virtual instance there. It seems okay after a > > > > fresh reboot but then progressively returns to being very slow: for > > > > example "sleep 1" may take four seconds, then five, six, seven, then > > > > rather more. Curiously it does tend to be an integral multiplier. > > > > > > > > I wondered, is anybody else seeing significant performance problems with > > > > OpenBSD (or other BSDs) virtual instances since Meltdown patching? Is > > > > there anything to tweak at my end or am I reliant on the provider? > > > > > > > > -- Mark > > > > > > > There are a ton of threads talking about this issue, and it's not meltdown > > > specific. Please search the archives. > > > > > > -ml > > > > [...] > > Also, Mark, could you say some more about the issue. For instance, how long > > after a reboot does it take until you start to notice the issue, and how > > quickly does it get worse? > > I'm another customer of Bytemark experiencing the same issue. I'm taking > care of one VM there and I'm primarly noticing it in two situations: > sleep() takes a long time (e.g. sleep(1) might take up to 40 seconds) > and the clock slows down. > > Right now, 9 hours after reboot, the clock on VM is 3 hours behind real > clock. And sleep(1) takes 13 secs: > > km@buildfarm ~ $ time sleep 1 > 0m13.85s real 0m00.00s user 0m00.01s system > > This all started after the host was patched and VM rebooted. > > Bytemark guys are looking at the issue and doing their own debugging. > Here're findings so far: > > I spun a few OpenBSD VMs up and left them overnight - looks like the > clock isn't drifting but there's still the 'time sleep 1' issue. > My testing results seemed to concur with User_4574's, virtio was slowing > down only a few minutes after a fresh install whereas compatibility > would stick at 1s, jump to 2s, etc. > > > > > Thanks, > > Kent > > > > -- > -- Kirill Miazine > >
Re: Writing "ones" instead of "zeroes" when wiping disk
Thanks to all of you for either useful tips or good-to-read rants. :-) I’ll try out tips from Nick & Todd, let’s see where that takes me. BR, Andreas fre 12 jan. 2018 kl. 05:22 skrev Todd C. Miller : > On Thu, 11 Jan 2018 22:09:32 -0500, "trondd" wrote: > > > A 1 is too narrow to fully cover the original data. > > You need to use an 8 to wipe out all seven segments. > > - todd > >
Fix for Otter Browser
Just a help here for those of you using the Otter-Browser on OpenBSD. Problem: YouTube and other videos will not play in the Otter-Browser. Solution: Install gstreamer1-plugins-good-1.* #pkg_add gstreamer1-plugins-good-1.* install gstreamer1-plugins-libav-1.* #pkg_add gstreamer1-plugins-libav-1.* Otter-Browser will now play YouTube and other videos -- Kind Regards, Jonathan
Re: After a failed checksum: What options remain?
Hello Charlie,
There is no correct way to wear a tinfoil hat. Do you trust your current
installation of Windows? And why? Do you trust your computer hardware?
Intel has proven something along those lines a couple of times in recent
history. Based on what premise do you trust OpenBSD?
Suspicion can be a good thing, but you need to balance your security
with other factors in life like usability, stability, compatibility and
probably some other ity's.
I love OpenBSD. Both for its security, but also its simplicity and
usability. But I'm also aware that even OpenBSD isn't without its quirks
and bugs. It's also still based on the premises that you trust other
components on which OpenBSD was build around. Even the mathematical
principles behind signature verification.
In other words choose something that works for you and where you feel
confident enough that it won't try to kill your kittens.
As for the checking a signature you can start by downloading OpenBSD 6.2
and verifying its signature:
$ cat /etc/signify/openbsd-62-base.pub
untrusted comment: openbsd 6.2 base public key
RWRVWzAMgtyg7g27STK1h1xA6RIwtjex6Vr5Y9q5SC5q5+b0GN4lLhfu
You can compare that string to any other sources, among others:
- https://www.openbsd.org/62.html
- https://twitter.com/phessler/status/914414877539803136
- ...
If you need signify I found a Windows port here[0], but since I don't
run Windows, so I haven't tested any of it (nor checked the diff). I
found that it is an older release, so the diff (against my personal
OpenBSD cvs account checkout) below also includes changes in OpenBSD's
current signify. But I guess this release will still work and the diff
is still small enough to manually verify if something funky has been
done with this port (still a pain though).
Nevertheless, it runs on Windows, so you have to trust your Windows
installation, which runs on
Once OpenBSD is installed it'll automatically install the keys for the
next release and which will be verified with the current key.
Finally your usability question. I find it easy to use, but that's a
combination of years of experience and liking the minimal footprint.
A lot of people seem to be unable to work with the removal of a lot
of abstraction layers, I find it liberating and it gives me more
peace of mind that not a lot more happens than I request of the system.
If it works for you, is for you to find out. Just install it and take it
for a test run. OpenBSD's FAQ[1] is quite good and covers quite a lot of
subjects. You can use the FAQ to guide you to the man pages and if that
doesn't satisfy you, you can always turn to the source. Feel free to
send in some patches if you find something quirky in the source. :-)
Hope this helps.
martijn@
[0] https://github.com/stoeckmann/signify-windows
[1] https://www.openbsd.org/faq/
Only in /home/martijn/src/OpenBSD/usr.bin/signify: CVS
Only in /home/martijn/src/OpenBSD/usr.bin/signify: Makefile
Only in /tmp/signify-windows/patched-src: base64.c
diff -ru /home/martijn/src/OpenBSD/usr.bin/signify/crypto_api.c
/tmp/signify-windows/patched-src/crypto_api.c
--- /home/martijn/src/OpenBSD/usr.bin/signify/crypto_api.c Wed Jan 8
04:59:46 2014
+++ /tmp/signify-windows/patched-src/crypto_api.c Fri Jan 12 11:07:34 2018
@@ -3,6 +3,8 @@
* Public domain. Author: Ted Unangst
* API compatible reimplementation of functions from nacl
*/
+#include "mingw.h"
+
#include
#include
Only in /tmp/signify-windows/patched-src: err.c
Only in /tmp/signify-windows/patched-src: errx.c
Only in /tmp/signify-windows/patched-src: explicit_bzero.c
Only in /tmp/signify-windows/patched-src: sha2.c
Only in /tmp/signify-windows/patched-src: sha2.h
Only in /home/martijn/src/OpenBSD/usr.bin/signify: signify.1
diff -ru /home/martijn/src/OpenBSD/usr.bin/signify/signify.c
/tmp/signify-windows/patched-src/signify.c
--- /home/martijn/src/OpenBSD/usr.bin/signify/signify.c Wed Jul 12 01:27:13 2017
+++ /tmp/signify-windows/patched-src/signify.c Fri Jan 12 11:07:34 2018
@@ -1,4 +1,4 @@
-/* $OpenBSD: signify.c,v 1.128 2017/07/11 23:27:13 tedu Exp $ */
+/* $OpenBSD: signify.c,v 1.100 2015/01/16 06:16:12 tedu Exp $ */
/*
* Copyright (c) 2013 Ted Unangst
*
@@ -14,11 +14,10 @@
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
+#include "mingw.h"
+
#include
-#include
-#include
-
#include
#include
#include
@@ -26,15 +25,10 @@
#include
#include
#include
-#include
-#include
#include
-#include
-#include
#include
#include "crypto_api.h"
-#include "signify.h"
#define SIGBYTES crypto_sign_ed25519_BYTES
#define SECRETBYTES crypto_sign_ed25519_SECRETKEYBYTES
@@ -71,7 +65,9 @@
uint8_t sig[SIGBYTES];
};
-static void __dead
+char *__progname = "signify";
+
+static void
usage(const char *error)
{
if (error)
@@ -80,14 +76,13 @@
#ifndef VERIFYONLY
"\t%1$s -C [-q] -p pubkey -x sigfile [file ...]\n"
Strange message from syspatch
Strange message from syspatch: # syspatch ftp: SSL write error: no OCSP URLs in peer certificate # what does this message mean and what to check? OpenBSD 6.2-stable GENERIC.MP#2 amd64 we have a fortinet in the middle. Previously, it did not interfere with the utility, since I added its certificate -- Dmitry Orlov
Re: Writing "ones" instead of "zeroes" when wiping disk
On 11/01/18 14:45, Andreas Thulin wrote: in order to achieve paranoid disk-wiping? I don't have a solution to offer for existing disks, but that made me just think that it would be probably easy to create two partitions on a disk, one that will be a keydisk (https://www.openbsd.org/faq/faq14.html#softraidFDEkeydisk) and one that would be the real partition holding the data, and the day you need to wipe the disk, the only thing you need to wipe (a few times if you're paranoid) is the keydisk partition, and the data will be unrecoverable. Does that sound sensible, or am I missing something? -- Étienne
Re: Writing "ones" instead of "zeroes" when wiping disk
On Thu, Jan 11, 2018 at 11:16:28AM -0600, L. V. Lammert wrote: > On Thu, 11 Jan 2018, STeve Andre' wrote: > > > Don't bother. Wiping the disk twice is enough. If you are storing state > > secrets melt the disk. > > > An anvil big hammer also works well and gives some exercise in the > process. Or a screwdriver and a pair of pliers if you want less excersise. > > Lee -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: Performance issues as KVM guest?
Hi, I don't see this issue on my Debian system, but please try two things: * disable kvm_intel.preemption_timer on the host (see /sys/module/kvm_intel/parameters/preemption_timer ) This seems to be buggy in linux 4.10 and newer * enable hpet in the vm config: Make sure there is no in your libvirt xml (or don't pass -ho-hpet to qemu). Unfortunately, newer libvirt versions seem to disable hpet by default. Different issue: If you remove the USB controllers, the CPU load on the host will reduce by a few percent (~ 3%). Add and remove all other usb controller sections. Just removing the usb controller sections without adding the 'none' makes libvirt add them back (this is stupid). Cheers, Stefan On Fri, 12 Jan 2018, Infoomatic wrote: > Same problem here. While we did have significant differences in cpu > usage between FreeBSD and OpenBSD (basic OS without configuration: > FreeBSD ~ 33min CPU time, OpenBSD ~ 474min CPU time - both started at > the same time), with the latest kernel patches for Ubuntu 17.04 (our > test environments all run Ubuntu 17.04 for KVM VMs), OpenBSD now becomes > practically unusable: as soon as I su or login on the console with su, > cpu usage is at 100% - the system freezes. :-/ guess we need some > dedicated BSD machines to host some test-VMs ;-) > > Regards, > Robert > > > > Gesendet: Donnerstag, 11. Januar 2018 um 20:32 Uhr > > Von: "Kirill Miazine" > > An: misc@openbsd.org > > Betreff: Re: Performance issues as KVM guest? > > > > * Kent Watsen [2018-01-11 17:38]: > > [...] > > > > > Since my hosting provider https://www.bytemark.co.uk/cloud-hosting/ > > > > > patched for Meltdown last weekend I'm seeing significant performance > > > > > issues with an OpenBSD virtual instance there. It seems okay after a > > > > > fresh reboot but then progressively returns to being very slow: for > > > > > example "sleep 1" may take four seconds, then five, six, seven, then > > > > > rather more. Curiously it does tend to be an integral multiplier. > > > > > > > > > > I wondered, is anybody else seeing significant performance problems > > > > > with > > > > > OpenBSD (or other BSDs) virtual instances since Meltdown patching? Is > > > > > there anything to tweak at my end or am I reliant on the provider? > > > > > > > > > > -- Mark > > > > > > > > > There are a ton of threads talking about this issue, and it's not > > > > meltdown > > > > specific. Please search the archives. > > > > > > > > -ml > > > > > > [...] > > > Also, Mark, could you say some more about the issue. For instance, how > > > long > > > after a reboot does it take until you start to notice the issue, and how > > > quickly does it get worse? > > > > I'm another customer of Bytemark experiencing the same issue. I'm taking > > care of one VM there and I'm primarly noticing it in two situations: > > sleep() takes a long time (e.g. sleep(1) might take up to 40 seconds) > > and the clock slows down. > > > > Right now, 9 hours after reboot, the clock on VM is 3 hours behind real > > clock. And sleep(1) takes 13 secs: > > > > km@buildfarm ~ $ time sleep 1 > > 0m13.85s real 0m00.00s user 0m00.01s system > > > > This all started after the host was patched and VM rebooted. > > > > Bytemark guys are looking at the issue and doing their own debugging. > > Here're findings so far: > > > > I spun a few OpenBSD VMs up and left them overnight - looks like the > > clock isn't drifting but there's still the 'time sleep 1' issue. > > My testing results seemed to concur with User_4574's, virtio was slowing > > down only a few minutes after a fresh install whereas compatibility > > would stick at 1s, jump to 2s, etc. > > > > > > > > Thanks, > > > Kent > > > > > > > -- > > -- Kirill Miazine > > > > > >
Re: FYI: logitech mouse LED color tool
Nice On January 12, 2018 2:42:06 AM GMT+01:00, Jan Klemkow wrote: >Hi, > >I implemented a utility to set the LED color of Logitech mouse devices >on OpenBSD. Some people might also use this mouse and would like to >change the LED color. > >If you are interested just try it: https://github.com/younix/g403led > >I just tested it with the "G403 Prodigy Gaming Mouse" model. If it >also >work for other models, let me know. > >Any feedback is welcome. > >bye, >Jan -- Take Care Sincerely flipchan layerprox dev
Re: OpenVPN Help
On Sun, Jan 07, 2018 at 01:31:02PM -0500, leroy jordan wrote: > Hi, All > > I am useing openbsd 6.2 release, as an server production. My network is > split with vlan into int_ and ext_ . However, I'm not sure which way to > run the VPN in a virtual machine or configure it on the int_ or ext_ so > that all the traffic from the int_ side is encrypted tun when it hit HTTPS > or TLS. I'm also using desktop environment this is the reason for the > needed outgoing under VPN. Hi leroy, my own expirience with this list is that you will receive very good answers and tips from experienced people. ...but only if you try to ask good questions. With "good questions" I mean for example writing about what you want to do, what you have done by now, what is not working, giing filenames, errormessages, logfiles... and of course asking a question ;-)
Re: Strange message from syspatch
On 2018-01-12, dmitry.sensei wrote: > Strange message from syspatch: > # syspatch > ftp: SSL write error: no OCSP URLs in peer certificate > # Simplest workaround is to download the files yourself and use a local url in /etc/installurl, e.g. file:///tmp/syspatch. > what does this message mean and what to check? > > OpenBSD 6.2-stable GENERIC.MP#2 amd64 > > we have a fortinet in the middle. Previously, it did not interfere with the > utility, since I added its certificate Most likely the fortinet doesn't include any OCSP URL in its MITM certificate, but just to be sure, which mirror? (cat /etc/installurl), and what's in the cert? $ openssl s_client -connect $hostname:443 -servername $hostname then copy the server cert and paste into "openssl x509 -text -noout". CA/B Forum requires an OCSP URL in certs unless stapling is used. But I don't see how a CA is going to know whether stapling is used so I would expect certs from the cabal to always have this set so we're unlikely to run into this with normal servers. So, although we're unlikely to bump into problems with this code without MITM, I think libtls may be going a little beyond usual requirements in needing this.
Re: Performance issues as KVM guest?
Hello Todd, This issue (Virtual hardware issue happens on latest proxmox5.x but not on Proxmox 4.4 ) with 6.2 (and 6.1 for that matter) It is discussed here https://marc.info/?l=openbsd-misc&m=151472854021947&w=2 but in recent versions of Proxmox 5.1 (QEMU/KVM) there were no console freezes (Proxmox updates fixed this issue (ie virtual Hardware Fix not an OpenBSD Software Fix) https://marc.info/?l=openbsd-misc&m=151467636114177&w=2 So OpenBSD 6.2 Runs Fine on older QEMU and KVM but not on latest KVM QEMU My 2 cents is that the issue is a change in Virtual Hardware that is incompatible with OpenBSD as opposed to change in OpenBSD that has caused the issue, in my humble opinion it is more likely a old driver incompatibility with newer (Virtual) hardware. I hope this helps Tom Smyth
Re: Strange message from syspatch
I once had incorrect VM time causing OCSP response like it was out of date, and syspatch refused in a similar way. But different than your situation I think. V/r, Bryan On Fri, Jan 12, 2018 at 7:19 AM, Stuart Henderson wrote: > On 2018-01-12, dmitry.sensei wrote: > > Strange message from syspatch: > > # syspatch > > ftp: SSL write error: no OCSP URLs in peer certificate > > # > > Simplest workaround is to download the files yourself and use a local > url in /etc/installurl, e.g. file:///tmp/syspatch. > > > what does this message mean and what to check? > > > > OpenBSD 6.2-stable GENERIC.MP#2 amd64 > > > > we have a fortinet in the middle. Previously, it did not interfere with > the > > utility, since I added its certificate > > Most likely the fortinet doesn't include any OCSP URL in its MITM > certificate, but just to be sure, which mirror? (cat /etc/installurl), > and what's in the cert? > > $ openssl s_client -connect $hostname:443 -servername $hostname > > then copy the server cert and paste into "openssl x509 -text -noout". > > CA/B Forum requires an OCSP URL in certs unless stapling is used. But I > don't see how a CA is going to know whether stapling is used so I would > expect certs from the cabal to always have this set so we're unlikely to > run into this with normal servers. So, although we're unlikely to bump > into problems with this code without MITM, I think libtls may be going > a little beyond usual requirements in needing this. > >
Re: Strange message from syspatch
On 2018/01/12 09:03, Bryan Harris wrote: > I once had incorrect VM time causing OCSP response like it was out of date, > and syspatch > refused in a similar way. Yes. That causes problems for the installer too, it's unable to fetch the list of mirrors (and ironically the time that it uses to check whether the clock is out so it can offer to reset it). > But different than your situation I think. Definitely.
Re: Strange message from syspatch
On 2018-01-12, Stuart Henderson wrote: > On 2018-01-12, dmitry.sensei wrote: >> Strange message from syspatch: >> # syspatch >> ftp: SSL write error: no OCSP URLs in peer certificate >> # > > Simplest workaround is to download the files yourself and use a local > url in /etc/installurl, e.g. file:///tmp/syspatch. > >> what does this message mean and what to check? >> >> OpenBSD 6.2-stable GENERIC.MP#2 amd64 >> >> we have a fortinet in the middle. Previously, it did not interfere with the >> utility, since I added its certificate > > Most likely the fortinet doesn't include any OCSP URL in its MITM > certificate, but just to be sure, which mirror? (cat /etc/installurl), > and what's in the cert? > > $ openssl s_client -connect $hostname:443 -servername $hostname > > then copy the server cert and paste into "openssl x509 -text -noout". dmitry sent it offlist, it's a typical mitm creating a new cert based on the original but modified. mirror is ftp.openbsd.org; compared to the real cert the changes are: - changed Serial Number, modulus, signature, issuer (obviously). - following sections removed: X509v3 Extended Key Usage: X509v3 Subject Key Identifier: X509v3 Authority Key Identifier: Authority Information Access: OCSP - URI:http://ocsp.int-x3.letsencrypt.org CA Issuers - URI:http://cert.int-x3.letsencrypt.org/ X509v3 Certificate Policies: - changed subject(!) -Subject: CN=www.openbsd.org +Subject: CN=www.openbsd.org, L=<1543 spaces> obviously it's the missing AIA that's causing the problem for libtls/ftp.
Re: Writing "ones" instead of "zeroes" when wiping disk
Nick Holland wrote: >Another answer to your question might be to change those zeros to ones. >One way to do that: > ># tr "\0" "\377"
bsd.mp not installed on EdgeRouter Lite
After reading INSTALL.octeon, I was able to write miniroot62.fs to a usb, plug that into the ERL, and perform a normal installation. The problem is that the installer was not able to detect both cores, so it only installed bsd.sp (bsd.mp was not an option in the set selection). Running 6.2-release. I did follow the instructions for setting the coremask=0x3 when booting the installer, and setting the coremask=0x3 in the bootcmd. It seems that the installer just wasn't able to recognize that it's a dual core system. To workaround this problem, I downloaded bsd.mp after installation and copied that to the FAT partition. My ERL can now run SMP, but as you probably guessed this does break KARL. Has anyone been able to install bsd.mp on the ERL and not break KARL? Selected snippets from the install process below. Cheers, Scott [snip] Octeon ubnt_e100# fatload usb 0 $loadaddr bsd.rd reading bsd.rd .. . 8750939 bytes read Octeon ubnt_e100# bootoctlinux rootdev=rd0 coremask=0x3 argv[2]: coremask=0x3 ELF file is 64 bit Allocating memory for ELF segment: addr: 0x8100 (adjusted to: 0x100), size 0x86f890 Allocated memory for ELF segment: addr: 0x8100, size 0x86f890 Processing PHDR 0 Loading 7ef710 bytes at 8100 Clearing 80180 bytes at 817ef710 ## Loading Linux kernel with entry point: 0x8100 ... Bootloader: Done loading app on coremask: 0x3 [snip] boot_desc->argc:3 boot_desc->flags:0x5 boot_desc->core_mask:0x3 boot_desc->dram_size:512 boot_desc->phy_mem_desc_addr:0 [snip] OpenBSD 6.2 (RAMDISK) #0: Wed Oct 4 05:40:31 UTC 2017 visa@octeon:/usr/src/sys/arch/octeon/compile/RAMDISK real mem = 536870912 (512MB) avail mem = 520896512 (496MB) mainbus0 at root cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation cpu0: cache L1-I 32KB 4 way D 8KB 64 way, L2 128KB 8 way clock0 at mainbus0: int 5 iobus0 at mainbus0 [snip] Select sets by entering a set name, a file name pattern or 'all'. De-select sets by prepending a '-', e.g.: '-game*'. Selected sets are labelled '[X]'. [X] bsd [X] comp62.tgz[X] xbase62.tgz [X] xserv62.tgz [X] bsd.rd[X] man62.tgz [X] xshare62.tgz [X] base62.tgz[X] game62.tgz[X] xfont62.tgz
Re: FYI: logitech mouse LED color tool
Nice to hack a script and warn whenever mail is coming and screen is blank. Thanks! 2018-01-12 13:08 GMT+01:00 flipchan : > Nice > > On January 12, 2018 2:42:06 AM GMT+01:00, Jan Klemkow < > j.klem...@wemelug.de> wrote: > >Hi, > > > >I implemented a utility to set the LED color of Logitech mouse devices > >on OpenBSD. Some people might also use this mouse and would like to > >change the LED color. > > > >If you are interested just try it: https://github.com/younix/g403led > > > >I just tested it with the "G403 Prodigy Gaming Mouse" model. If it > >also > >work for other models, let me know. > > > >Any feedback is welcome. > > > >bye, > >Jan > > -- > Take Care Sincerely flipchan layerprox dev
Re: vmm issues - vioblk_notifyq: unsupported command 0x8
On Fri, Oct 13, 2017 at 04:14:09PM -0500, Andrew Daugherity wrote:
> On Thu, Oct 12, 2017 at 6:42 PM, Mike Larkin wrote:
> >> oh. I didn't know that is how it was finding things.
> >>
> >
> > When booting it this way in qemu, qemu just reports the ID as "".
> >
> > So are you sure this is the way it is supposed to work?
>
> Yes... with some caveats.
>
> The Linux device manager (udev, I think? They've gone through
> several.) creates symlinks under /dev/disk/by-{id,label,path,uuid}/,
> so that you can use more permanent names in case the disk order (sda,
> sdb, etc.) changes; there are also library calls to open a
> device/partition by ID, UUID, etc., (via libblkid I believe, which
> lets you use things like LABEL=foo or UUID=abcd... as the block device
> passed to mount(8) or listed in fstab). The SUSE installer is
> "helpfully" attempting to use these IDs; e.g. with a SATA disk under
> VirtualBox, it uses a repo URL of
> 'hd:///?device=/dev/disk/by-id/ata-VBOX_HARDDISK_VB40007e3d-cdaea0a1-part2'.
>
> However, you are correct that qemu virtio disks do not report IDs (or
> report blank ones) -- at least by default (apparently with recent
> qemu, there is an option to set a drive's serial number, but it
> doesn't seem to be commonly used). I did a test installation of
> openSUSE under Proxmox VE (qemu/KVM) using virtio disks, and the only
> thing under /dev/disk/by-id is the emaulated IDE CD-ROM. -- nothing
> for /dev/vda or vdb. Notably, the installer configured its repo as
> 'hd:///?device=/dev/vda2' without me having to tell it that, as I had
> to under vmm.
>
> By comparison, the opensuse VM I installed under OpenBSD vmm *does*
> show some 'by-id' devices:
> /dev/disk/by-id:
> total 0
> lrwxrwxrwx 1 root root 9 Oct 13 13:21 virtio-__LI_U_ -> ../../vdb
> lrwxrwxrwx 1 root root 10 Oct 13 13:21 virtio-__LI_U_-part1 ->
> ../../vdb1
> lrwxrwxrwx 1 root root 10 Oct 13 13:21 virtio-__LI_U_-part2 ->
> ../../vdb2
> (Currently /dev/vda is the VM's hard disk and vdb is the ISO...
> strange that there are only links for vdb, but not vda. Of course
> accessing via these symlinks works, since they point at the real
> device, but doing whatever library call to open
> 'virtio-__LI_U_-part2' would most likely fail, and obviously
> the correct symlinks did not exist during installation.)
>
> My best guess is that when udev gets a blank ID, it skips the by-id
> stuff, and thus the installer uses the real disk device, but since vmm
> doesn't implement that call, instead of marking the disk as not having
> an ID, invalid disk IDs somehow get used.
>
>
> -Andrew
Just cleaning out old email threads. This should be in better shape now
that ccardenas@ has implemented proper CD-ROM device support.
-ml
Re: FYI: logitech mouse LED color tool
On Fri, Jan 12, 2018 at 02:42:06AM +0100, Jan Klemkow wrote: > Hi, > > I implemented a utility to set the LED color of Logitech mouse devices > on OpenBSD. Some people might also use this mouse and would like to > change the LED color. > > If you are interested just try it: https://github.com/younix/g403led > > I just tested it with the "G403 Prodigy Gaming Mouse" model. If it also > work for other models, let me know. > > Any feedback is welcome. Make a port! :) -- Juan Francisco Cantero Hurtado http://juanfra.info
