Re: dump and duid
Jan Stary wrote, On 02/27/15 06:09: This is current/amd64. After cleaning my machine I reconnected two of my disks in reverse; what was sd0 is sd1 now, and vice versa. I do nightly dumps of the filesystems, starting with level 0 on early Monday morning, continuing with incremental 1, 2 etc through the week. Usually this means that the Monday dump -0 is big, and the subsequent incrementals are relatively small: -rw--- 1 hans wheel 299G Feb 23 03:26 dump.biblio.0 -rw--- 1 hans wheel 19.7M Feb 24 01:32 dump.biblio.1 -rw--- 1 hans wheel 1.4G Feb 25 01:32 dump.biblio.2 -rw--- 1 hans wheel 674M Feb 26 01:32 dump.biblio.3 -rw--- 1 hans wheel 240G Feb 27 02:55 dump.biblio.4 -rw--- 1 hans wheel 16.7G Feb 23 01:40 dump.home.0 -rw--- 1 hans wheel 326M Feb 24 01:32 dump.home.1 -rw--- 1 hans wheel 54.5M Feb 25 01:32 dump.home.2 -rw--- 1 hans wheel 59.4M Feb 26 01:32 dump.home.3 -rw--- 1 hans wheel 52.3M Feb 27 01:32 dump.home.4 -rw--- 1 hans wheel 93.9M Feb 23 01:30 dump.root.0 -rw--- 1 hans wheel 100K Feb 24 01:30 dump.root.1 -rw--- 1 hans wheel 80.0K Feb 25 01:30 dump.root.2 -rw--- 1 hans wheel 80.0K Feb 26 01:30 dump.root.3 -rw--- 1 hans wheel 7.4M Feb 27 01:30 dump.root.4 [...] Now, on the night after I interchanged the disks, the dump -4 of sd1a (/biblio) is huge again; apparently, dump -4 is dumping everything again. Is this simply because /etc/dumpdates deals with device names, as opposed to duids? I ran into this quite awhile ago. My tests definitely confirm dump does not recognize DUIDs. Many utilities have been made DUID aware, but not dump(8). Dump reads /etc/dumpdates, which only lists device paths.
Re: Daily digest, Issue 3400 (78 messages)
Many thanks to all respondents. Problem solved with dump. -- Ed
Minnowboard MAX PCIe issue
Hi,
I'm trying to run OpenBSD on the Minnowboard MAX with Coreboot. As Ryan
McBride already posted this does work, but the network card isn't
recognized.
After some debugging I found that the problem is that the network card
is behind a PCIe bridge that is not detected by OpenBSD. According to
pcidump(8) the PCI bridge is at PCI bus 0, device 28, function 2. The
problem here seems to be that there is no function 0 for device 28.
I don't have any experience with PCI/PCI-E, so I might say silly things
here. But this is what I found that happened: In pci_enumerate_bus() the
kernel enumerates all devices on a bus. It checks the header type,
vendor and product id of function 0 of a device to determine if/which
device is at this address. Since the PCIe bridge in the Minnowboard Max
doesn't have a function 0, the kernel skips this device.
The following small hack fixes this. After applying the PCIe bridge is
detected and the re(4) NIC behind the bridge is found.
diff -u -p -r1.109 pci.c
--- pci.c 27 Nov 2014 19:03:44 - 1.109
+++ pci.c 7 Mar 2015 13:58:10 -
@@ -754,6 +754,15 @@ pci_enumerate_bus(struct pci_softc *sc,
for (device = 0; device < sc->sc_maxndevs; device++) {
tag = pci_make_tag(pc, sc->sc_bus, device, 0);
+ if (tag == 0x8000e000) {
+ printf("QUIRK: PCIe bridge\n");
+ tag = 0x8000e200;
+ ret = pci_probe_device(sc, tag, match, pap);
+ if (match != NULL && ret != 0)
+ return (ret);
+
+ continue;
+ }
bhlcr = pci_conf_read(pc, tag, PCI_BHLC_REG);
if (PCI_HDRTYPE_TYPE(bhlcr) > 2)
<<<
Of course this is not a real fix. But with my lack of experience with
PCI I can't tell if this is really an OpenBSD problem or a
Coreboot/SeaBIOS problem, or just a bug in the Minnowboard MAX hardware.
Anyone any idea if/how/where to fix this?
Kind regards,
David
# pcidevs -v:
Domain /dev/pci0:
0:0:0: Intel Bay Trail Host
0x: Vendor ID: 8086 Product ID: 0f00
0x0004: Command: 0007 Status:
0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 0c
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line
Size: 00
0x0010: BAR empty ()
0x0014: BAR empty ()
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS:
0x002c: Subsystem Vendor ID: 8086 Product ID: 7270
0x0030: Expansion ROM Base Address:
0x0038:
0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00
0:2:0: Intel Bay Trail Video
0x: Vendor ID: 8086 Product ID: 0f31
0x0004: Command: 0007 Status: 0010
0x0008: Class: 03 Subclass: 00 Interface: 00 Revision: 0c
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line
Size: 00
0x0010: BAR mem 32bit addr: 0xd000/0x0040
0x0014: BAR empty ()
0x0018: BAR mem prefetchable 32bit addr: 0xc000/0x1000
0x001c: BAR empty ()
0x0020: BAR io addr: 0x2040/0x0008
0x0024: BAR empty ()
0x0028: Cardbus CIS:
0x002c: Subsystem Vendor ID: 8086 Product ID: 7270
0x0030: Expansion ROM Base Address:
0x0038:
0x003c: Interrupt Pin: 01 Line: 00 Min Gnt: 00 Max Lat: 00
0x00d0: Capability 0x01: Power Management
0x0090: Capability 0x05: Message Signaled Interrupts (MSI)
0x00b0: Capability 0x09: Vendor Specific
0:18:0: Intel unknown
0x: Vendor ID: 8086 Product ID: 0f16
0x0004: Command: 0106 Status: 0010
0x0008: Class: 08 Subclass: 05 Interface: 01 Revision: 0c
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line
Size: 10
0x0010: BAR mem 32bit addr: 0xd0a18000/0x1000
0x0014: BAR mem 32bit addr: 0xd0a19000/0x1000
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS:
0x002c: Subsystem Vendor ID: 8086 Product ID: 7270
0x0030: Expansion ROM Base Address:
0x0038:
0x003c: Interrupt Pin: 01 Line: 07 Min Gnt: 00 Max Lat: 00
0x0080: Capability 0x01: Power Management
0:19:0: Intel Bay Trail AHCI
0x: Vendor ID: 8086 Product ID: 0f23
0x0004: Command: 0107 Status: 02b0
0x0008: Class: 01 Subclass: 06 Interface: 01 Revision: 0c
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line
Size: 00
0x0010: BAR io addr: 0x2048/0x0008
0x0014: BAR io addr: 0x2058/0x0004
0x0018: BAR io addr: 0x2050/0x0008
Re: Does LibreSSL support RSA export-grade keys? - FREAK Attack
(ridiculous formatting adjusted) On 2015-03-06, someone wrote: > SUGGEST> THE> WORLD> TO> ONLY> USE> PERFECT> FORWARD> SECRECY> AND> > REMOVE> ALL> THE> WEAK> CIPHERS> IN> LIBRESSL> AND> OPENSSL! > There is still not widespread support for PFS. Some of this is probably due to use of old software for whatever reason (slackness? not wanting to change something which has been tested?), some will be due to sites not wishing to increase CPU use (which PFS does). I just tried a handful of online banking sites in the qualys checker. Only *one* of the ones I tried (nice job triodos) supports PFS at all.
Re: Quick OpenBSD/thinkpad question
Dmitrij D. Czarkoff (2015-03-06 23:01 +0100): > m...@jeremiahford.com said: > > My question is; Does anyone have any insight into these claims, whether it > > be proving or disproving? > > With amount of firmware in laptops these days I guess it is effectively > impossible to disprove backdoor claims. > > Jiri B. said: > > There are two kinds of this attacks - hardware or software. > > Hardware attacks? With flamethrowers? Possibly. Don't tell me you don't run a firewall.
Cannot connect to CUPS web interface in -current
Dear misc@ readers, I must admit, I do not have a lot of luck with CUPS... This time, I'm not even able to connect to the web interface! Brand new snapshot installation: just22@poseidon:[~]> uname -a OpenBSD poseidon.atlantide.net 5.7 GENERIC.MP#875 amd64 CUPS daemon is up and running, but when I try to access to https://localhost:631, there seems to be troubles with the SSL encryption; in lynx, for example: SSL error:unable to get local issuer certificate-Continue? (y) SSL error:host(localhost)!=cert(CN)-Continue? (y) Alert: HTTP/1.0 404 Not Found There are some evidence the SSL is the culprit in /var/log/cups/error_log too: just22@poseidon:[~]> tail /var/log/cups/error_log E [07/Mar/2015:18:14:42 +0100] [Client 1] Unable to encrypt connection: Error in the pull function. Reinforcing the log level to debug: I [07/Mar/2015:18:23:47 +0100] Listening to [v1.::1]:631 (IPv6) I [07/Mar/2015:18:23:47 +0100] Listening to 127.0.0.1:631 (IPv4) I [07/Mar/2015:18:23:47 +0100] Listening to /var/run/cups/cups.sock (Domain) I [07/Mar/2015:18:23:47 +0100] Remote access is disabled. D [07/Mar/2015:18:23:47 +0100] Added auto ServerAlias poseidon.atlantide.net D [07/Mar/2015:18:23:47 +0100] Added auto ServerAlias poseidon I [07/Mar/2015:18:23:47 +0100] Loaded configuration file "/etc/cups/cupsd.conf" D [07/Mar/2015:18:23:47 +0100] Using keychain "/etc/cups/ssl" for server name "poseidon.atlantide.net". I [07/Mar/2015:18:23:47 +0100] Using default TempDir of /var/spool/cups/tmp... I [07/Mar/2015:18:23:47 +0100] Configured for up to 100 clients. I [07/Mar/2015:18:23:47 +0100] Allowing up to 100 client connections per host. I [07/Mar/2015:18:23:47 +0100] Using policy "default" as the default. I [07/Mar/2015:18:23:47 +0100] Full reload is required. I [07/Mar/2015:18:23:47 +0100] Loaded MIME database from "/usr/local/share/cups/mime" and "/etc/cups": 39 types, 57 filters... I [07/Mar/2015:18:23:47 +0100] Loading job cache file "/var/cache/cups/job.cache"... I [07/Mar/2015:18:23:47 +0100] Full reload complete. I [07/Mar/2015:18:23:47 +0100] Listening to [v1.::1]:631 (IPv6) I [07/Mar/2015:18:23:47 +0100] Listening to 127.0.0.1:631 (IPv4) I [07/Mar/2015:18:23:47 +0100] Listening to /var/run/cups/cups.sock (Domain) I [07/Mar/2015:18:23:47 +0100] Remote access is disabled. D [07/Mar/2015:18:23:47 +0100] Added auto ServerAlias poseidon.atlantide.net D [07/Mar/2015:18:23:47 +0100] Added auto ServerAlias poseidon I [07/Mar/2015:18:23:47 +0100] Loaded configuration file "/etc/cups/cupsd.conf" D [07/Mar/2015:18:23:47 +0100] Using keychain "/etc/cups/ssl" for server name "poseidon.atlantide.net". I [07/Mar/2015:18:23:47 +0100] Using default TempDir of /var/spool/cups/tmp... I [07/Mar/2015:18:23:47 +0100] Configured for up to 100 clients. I [07/Mar/2015:18:23:47 +0100] Allowing up to 100 client connections per host. I [07/Mar/2015:18:23:47 +0100] Using policy "default" as the default. I [07/Mar/2015:18:23:47 +0100] Full reload is required. I [07/Mar/2015:18:23:47 +0100] Loaded MIME database from "/usr/local/share/cups/mime" and "/etc/cups": 39 types, 57 filters... D [07/Mar/2015:18:23:47 +0100] Scanning /var/spool/cups for jobs... I [07/Mar/2015:18:23:47 +0100] Full reload complete. D [07/Mar/2015:18:23:47 +0100] cupsdCleanFiles(path="/var/spool/cups/tmp", pattern="(null)") I [07/Mar/2015:18:23:47 +0100] Cleaning out old files in "/var/spool/cups/tmp". D [07/Mar/2015:18:23:47 +0100] cupsdCleanFiles(path="/var/cache/cups", pattern="*.ipp") I [07/Mar/2015:18:23:47 +0100] Cleaning out old files in "/var/cache/cups". I [07/Mar/2015:18:23:47 +0100] Listening to [v1.::1]:631 on fd 9... I [07/Mar/2015:18:23:47 +0100] Listening to 127.0.0.1:631 on fd 10... I [07/Mar/2015:18:23:47 +0100] Listening to /var/run/cups/cups.sock on fd 11... I [07/Mar/2015:18:23:47 +0100] Resuming new connection processing... D [07/Mar/2015:18:23:47 +0100] cupsdSetBusyState: newbusy="Not busy", busy="Not busy" D [07/Mar/2015:18:23:47 +0100] cupsdAddCert: Adding certificate for PID 0 D [07/Mar/2015:18:23:47 +0100] Discarding unused server-started event... D [07/Mar/2015:18:23:48 +0100] Report: clients=0 D [07/Mar/2015:18:23:48 +0100] Report: jobs=0 D [07/Mar/2015:18:23:48 +0100] Report: jobs-active=0 D [07/Mar/2015:18:23:48 +0100] Report: printers=0 D [07/Mar/2015:18:23:48 +0100] Report: stringpool-string-count=297 D [07/Mar/2015:18:23:48 +0100] Report: stringpool-alloc-bytes=4832 D [07/Mar/2015:18:23:48 +0100] Report: stringpool-total-bytes=5000 D [07/Mar/2015:18:24:33 +0100] [Client 1] Accepted from localhost:11723 (IPv4) D [07/Mar/2015:18:24:33 +0100] [Client 1] Waiting for request. I [07/Mar/2015:18:24:36 +0100] [Client 1] Connection now encrypted. D [07/Mar/2015:18:24:37 +0100] [Client 1] GET / HTTP/1.0 D [07/Mar/2015:18:24:37 +0100] cupsdSetBusyState: newbusy="Active clients", busy="Not busy" D [07/Mar/2015:18:24:37 +0100] [Client 1] Read: status=200 D [07/Mar/2015:18:24:37 +0100] [Client 1] No authentication data provided. D [07/Mar/2015:18:24:37
Patching X in BASE without X
Hi All, This should be a very easy question. A while back I had questioned when running a system with BASE whether it is fine to skip applying patches not applicable to my system’s uses, and whether they can be done out of order. The response I got was mixed, but it seems the safest bet is to apply patches in order, and apply all patches. This being the case, will it in any way harm or cause problems on a system if I apply patches for X, if I do not have X installed? Kind regards, Andrew Lester
Re: Patching X in BASE without X
On 3/7/2015 2:08 PM, Andrew Lester wrote: Hi All, This should be a very easy question. A while back I had questioned when running a system with BASE whether it is fine to skip applying patches not applicable to my system’s uses, and whether they can be done out of order. The response I got was mixed, but it seems the safest bet is to apply patches in order, and apply all patches. This being the case, will it in any way harm or cause problems on a system if I apply patches for X, if I do not have X installed? Kind regards, Andrew Lester The result of patching xenocara according to the instructions in the patch file is that you would then have at least that portion of X installed. In the case of the latest errata 16 for 5.6, it would mean that you would end up with the X server binaries installed but not the rest of X. If you truly did not install the X packages when you installed OpenBSD I would recommend not patching X. -- John Merriam
Re: Cannot connect to CUPS web interface in -current
On 03/07/2015 09:41 AM, Alessandro DE LAURENZIS wrote: > CUPS daemon is up and running, but when I try to access to > https://localhost:631, there seems to be troubles with the SSL > encryption; in lynx, for example: Mine does not use https, since it is limited to localhost only. I don't remember it ever using https. -- Those who do not understand Unix are condemned to reinvent it, poorly.
Re: Cannot connect to CUPS web interface in -current
On 03/07/15 17:41, Alessandro DE LAURENZIS wrote: Dear misc@ readers, I must admit, I do not have a lot of luck with CUPS... This time, I'm not even able to connect to the web interface! Brand new snapshot installation: just22@poseidon:[~]> uname -a OpenBSD poseidon.atlantide.net 5.7 GENERIC.MP#875 amd64 CUPS daemon is up and running, but when I try to access to https://localhost:631, there seems to be troubles with the SSL encryption; in lynx, for example: SSL error:unable to get local issuer certificate-Continue? (y) SSL error:host(localhost)!=cert(CN)-Continue? (y) Alert: HTTP/1.0 404 Not Found There are some evidence the SSL is the culprit in /var/log/cups/error_log too: just22@poseidon:[~]> tail /var/log/cups/error_log E [07/Mar/2015:18:14:42 +0100] [Client 1] Unable to encrypt connection: Error in the pull function. Reinforcing the log level to debug: I [07/Mar/2015:18:23:47 +0100] Listening to [v1.::1]:631 (IPv6) I [07/Mar/2015:18:23:47 +0100] Listening to 127.0.0.1:631 (IPv4) I [07/Mar/2015:18:23:47 +0100] Listening to /var/run/cups/cups.sock (Domain) I [07/Mar/2015:18:23:47 +0100] Remote access is disabled. D [07/Mar/2015:18:23:47 +0100] Added auto ServerAlias poseidon.atlantide.net D [07/Mar/2015:18:23:47 +0100] Added auto ServerAlias poseidon I [07/Mar/2015:18:23:47 +0100] Loaded configuration file "/etc/cups/cupsd.conf" D [07/Mar/2015:18:23:47 +0100] Using keychain "/etc/cups/ssl" for server name "poseidon.atlantide.net". I [07/Mar/2015:18:23:47 +0100] Using default TempDir of /var/spool/cups/tmp... I [07/Mar/2015:18:23:47 +0100] Configured for up to 100 clients. I [07/Mar/2015:18:23:47 +0100] Allowing up to 100 client connections per host. I [07/Mar/2015:18:23:47 +0100] Using policy "default" as the default. I [07/Mar/2015:18:23:47 +0100] Full reload is required. I [07/Mar/2015:18:23:47 +0100] Loaded MIME database from "/usr/local/share/cups/mime" and "/etc/cups": 39 types, 57 filters... I [07/Mar/2015:18:23:47 +0100] Loading job cache file "/var/cache/cups/job.cache"... I [07/Mar/2015:18:23:47 +0100] Full reload complete. I [07/Mar/2015:18:23:47 +0100] Listening to [v1.::1]:631 (IPv6) I [07/Mar/2015:18:23:47 +0100] Listening to 127.0.0.1:631 (IPv4) I [07/Mar/2015:18:23:47 +0100] Listening to /var/run/cups/cups.sock (Domain) I [07/Mar/2015:18:23:47 +0100] Remote access is disabled. D [07/Mar/2015:18:23:47 +0100] Added auto ServerAlias poseidon.atlantide.net D [07/Mar/2015:18:23:47 +0100] Added auto ServerAlias poseidon I [07/Mar/2015:18:23:47 +0100] Loaded configuration file "/etc/cups/cupsd.conf" D [07/Mar/2015:18:23:47 +0100] Using keychain "/etc/cups/ssl" for server name "poseidon.atlantide.net". I [07/Mar/2015:18:23:47 +0100] Using default TempDir of /var/spool/cups/tmp... I [07/Mar/2015:18:23:47 +0100] Configured for up to 100 clients. I [07/Mar/2015:18:23:47 +0100] Allowing up to 100 client connections per host. I [07/Mar/2015:18:23:47 +0100] Using policy "default" as the default. I [07/Mar/2015:18:23:47 +0100] Full reload is required. I [07/Mar/2015:18:23:47 +0100] Loaded MIME database from "/usr/local/share/cups/mime" and "/etc/cups": 39 types, 57 filters... D [07/Mar/2015:18:23:47 +0100] Scanning /var/spool/cups for jobs... I [07/Mar/2015:18:23:47 +0100] Full reload complete. D [07/Mar/2015:18:23:47 +0100] cupsdCleanFiles(path="/var/spool/cups/tmp", pattern="(null)") I [07/Mar/2015:18:23:47 +0100] Cleaning out old files in "/var/spool/cups/tmp". D [07/Mar/2015:18:23:47 +0100] cupsdCleanFiles(path="/var/cache/cups", pattern="*.ipp") I [07/Mar/2015:18:23:47 +0100] Cleaning out old files in "/var/cache/cups". I [07/Mar/2015:18:23:47 +0100] Listening to [v1.::1]:631 on fd 9... I [07/Mar/2015:18:23:47 +0100] Listening to 127.0.0.1:631 on fd 10... I [07/Mar/2015:18:23:47 +0100] Listening to /var/run/cups/cups.sock on fd 11... I [07/Mar/2015:18:23:47 +0100] Resuming new connection processing... D [07/Mar/2015:18:23:47 +0100] cupsdSetBusyState: newbusy="Not busy", busy="Not busy" D [07/Mar/2015:18:23:47 +0100] cupsdAddCert: Adding certificate for PID 0 D [07/Mar/2015:18:23:47 +0100] Discarding unused server-started event... D [07/Mar/2015:18:23:48 +0100] Report: clients=0 D [07/Mar/2015:18:23:48 +0100] Report: jobs=0 D [07/Mar/2015:18:23:48 +0100] Report: jobs-active=0 D [07/Mar/2015:18:23:48 +0100] Report: printers=0 D [07/Mar/2015:18:23:48 +0100] Report: stringpool-string-count=297 D [07/Mar/2015:18:23:48 +0100] Report: stringpool-alloc-bytes=4832 D [07/Mar/2015:18:23:48 +0100] Report: stringpool-total-bytes=5000 D [07/Mar/2015:18:24:33 +0100] [Client 1] Accepted from localhost:11723 (IPv4) D [07/Mar/2015:18:24:33 +0100] [Client 1] Waiting for request. I [07/Mar/2015:18:24:36 +0100] [Client 1] Connection now encrypted. D [07/Mar/2015:18:24:37 +0100] [Client 1] GET / HTTP/1.0 D [07/Mar/2015:18:24:37 +0100] cupsdSetBusyState: newbusy="Active clients", busy="Not busy" D [07/Mar/2015:18:24:37 +0100] [Client 1] Read: status=200 D [07/Mar/2015:18:24:37 +0100] [Client 1] No au
Re: Cannot connect to CUPS web interface in -current
Hi Fred, On Sat 07/03/2015 21:32, Fred wrote: > Both Firefox and Chrome let me do https://localhost:631/ but then both > complain and I have to add exceptions, once added it works for me. > > In chrome the connection is then encrypted with TLS 1.2 > > port:fred ~> uname -a; dmesg|head -4; pkg_info| grep cups > OpenBSD port.crowsons.com 5.7 GENERIC.MP#860 amd64 > OpenBSD 5.7-beta (GENERIC.MP) #860: Sun Feb 22 03:14:54 MST 2015 > t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8447131648 (8055MB) > avail mem = 8218349568 (7837MB) > cups-2.0.2 Common Unix Printing System > cups-filters-1.0.65 OpenPrinting CUPS filters > cups-libs-2.0.2 CUPS libraries and headers > cups-pk-helper-0.2.5 fine-grained privileges PolicyKit helper for CUPS > gtk+3-cups-3.14.8 gtk+3 CUPS print backend > > Maybe ktrace cups to seem that can give any clues. After adding the exception, I continue to see the "Not Found" message. So the encryption was not the root cause. But it seems I've sorted it out: the files used for CUPS's web interface are contained into the /usr/local/share/doc/cups directory, and *by default*, that isn't world readable, at least for this very latest CUPS release (2.0.2). In fact, the inconsistency is flagged in the error_log file: I [07/Mar/2015:18:25:38 +0100] [Client 4] Files/directories such as "/usr/local/share/doc/cups/" must be world-readable. After changing the permissions all works as expected. Maybe something to fix in CUPS port? Antoine could give us his view... -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: Cannot connect to CUPS web interface in -current
On Sat 07/03/2015 23:20, Alessandro DE LAURENZIS wrote: > After adding the exception, I continue to see the "Not Found" message. > So the encryption was not the root cause. > > But it seems I've sorted it out: the files used for CUPS's web interface > are contained into the /usr/local/share/doc/cups directory, and *by > default*, that isn't world readable, at least for this very latest CUPS > release (2.0.2). In fact, the inconsistency is flagged in the error_log > file: > > I [07/Mar/2015:18:25:38 +0100] [Client 4] Files/directories such as > "/usr/local/share/doc/cups/" must be world-readable. > > After changing the permissions all works as expected. Maybe something to > fix in CUPS port? Antoine could give us his view... Just found a thread reporting a similar issue: [1] http://www.linuxquestions.org/questions/slackware-14/stoopid-cups-question-4175522158/page2.html -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: Cannot connect to CUPS web interface in -current
On Sat, Mar 07, 2015 at 11:20:30PM +0100, Alessandro DE LAURENZIS wrote: > Hi Fred, > > On Sat 07/03/2015 21:32, Fred wrote: > > Both Firefox and Chrome let me do https://localhost:631/ but then both > > complain and I have to add exceptions, once added it works for me. > > > > In chrome the connection is then encrypted with TLS 1.2 > > > > port:fred ~> uname -a; dmesg|head -4; pkg_info| grep cups > > OpenBSD port.crowsons.com 5.7 GENERIC.MP#860 amd64 > > OpenBSD 5.7-beta (GENERIC.MP) #860: Sun Feb 22 03:14:54 MST 2015 > > t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 8447131648 (8055MB) > > avail mem = 8218349568 (7837MB) > > cups-2.0.2 Common Unix Printing System > > cups-filters-1.0.65 OpenPrinting CUPS filters > > cups-libs-2.0.2 CUPS libraries and headers > > cups-pk-helper-0.2.5 fine-grained privileges PolicyKit helper for CUPS > > gtk+3-cups-3.14.8 gtk+3 CUPS print backend > > > > Maybe ktrace cups to seem that can give any clues. > > After adding the exception, I continue to see the "Not Found" message. > So the encryption was not the root cause. > > But it seems I've sorted it out: the files used for CUPS's web interface > are contained into the /usr/local/share/doc/cups directory, and *by > default*, that isn't world readable, at least for this very latest CUPS > release (2.0.2). In fact, the inconsistency is flagged in the error_log > file: > > I [07/Mar/2015:18:25:38 +0100] [Client 4] Files/directories such as > "/usr/local/share/doc/cups/" must be world-readable. > > After changing the permissions all works as expected. Maybe something to > fix in CUPS port? Antoine could give us his view... Permissions are fine here. Not sure why yours are not. -- Antoine
Re: Audio probles like, slow response in applications that use audio
On Fri, Mar 06, 2015 at 09:07:40PM +0100, Alexandre Ratchov wrote: > Yes we have modifications. Back around 2008, audio used to be very > unsable on MP systems and sndiod used to run with lower priority. > So using large buffers (around 500ms) was the only way to get > stable audio. > > Nowadays, this is not necessary, but buffer sizes are still big > because nobody tryed to reduce them. Maybe it's time now. Properly > written software could probably work with 50ms buffers. > > Still I'm talking about 500ms. Not the 1-2s you mentioned, which I > need to understand. > > Could you do the following: in one window, kill sndiod and start a > new one as follows: > > sudo pkill sndiod > SNDIO_DEBUG=4 sndiod -ddd 2>/tmp/log > > in another window: > > mplayer /foo/bar.mp3 > > after few seconds, push the right arrow key to skip forward, wait > few seconds, press q, kill sndiod and send me the /tmp/log file. > > When you hit the right arrow key, mplayer is supposed to take 500ms > to react, but on your setup it takes 1-2s, right? > > The file is huge, so please send it off-list. I attached the file -- Regards Henrique Lengler snd0 pst=cfg.default: rec=0:1 play=0:1 vol=23170 dup listen(/tmp/aucat-1000/aucat0|ini): created sock(sock|ini): created sock,rmsg,widl: AUTH message sio_sun_setpar: 0: trying pars = 48000/16/6 sio_sun_setpar: bpf = (4, 4) sio_sun_setpar: 0: trying round = 600 -> (576, 576) sio_sun_setpar: blocksize ok sio_sun_setpar: 0: trying pars = 48000/16/6 sio_sun_setpar: bpf = (4, 4) sio_sun_setpar: 0: trying round = 960 -> (960, 960) sio_sun_setpar: blocksize ok sock,rmsg,widl: HELLO message sock,rmsg,widl: hello from , mode = 1, ver 7 sock,rmsg,widl: using snd0 pst=cfg.default, mode = 1 mplayer0: overwritten slot 0 snd0 pst=cfg: device requested sio(rsnd/0|ini): created snd0 pst=ini: 48000Hz, s16le, play 0:1, rec 0:1, 9 blocks of 960 frames mplayer0 vol=127,pst=ini,mmc=off,rmsg,widl: SETPAR message mplayer0 vol=127,pst=ini,mmc=off,rmsg,widl: playback channels 0:1 -> 0:1 mplayer0 vol=127,pst=ini,mmc=off,rmsg,widl: 44100Hz sample rate, 882 frame blocks mplayer0 vol=127,pst=ini,mmc=off,rmsg,widl: 11466 frame buffer mplayer0 vol=127,pst=ini,mmc=off,rmsg,widl: GETPAR message mplayer0 vol=127,pst=ini,mmc=off,rmsg,widl: GETPAR message mplayer0 vol=127,pst=ini,mmc=off,rmsg,widl: START message mplayer0 vol=127,pst=ini,mmc=off: playing s32le -> s16le mplayer0 vol=127,pst=ini,mmc=off: allocated 11466/19404 fr buffers mplayer0 vol=127,pst=sta,mmc=off: 44100Hz, s32le, play 0:1, 13 blocks of 882 frames mplayer0 vol=127,pst=sta,mmc=off,rmsg,widl: building SETVOL message, vol = 127 snd0 pst=ini: device started snd0 pst=run: started mplayer0 vol=127,pst=run,mmc=off: attached at -7938, delta = 0 cmap: nch = 2, ostart = 0, onext = 0, istart = 0, inext = 0 dec: s32le, 2 channels resamp: 882/960 mplayer0 vol=127,pst=run,mmc=off: set weight: 23170/23170 12083: sio_revents: revents = 0x4, took 1537ns 35969: sio_revents: revents = 0x4, took 1257ns 47213: sio_revents: revents = 0x4, took 1257ns 57410: sio_revents: revents = 0x4, took 1257ns 67746: sio_revents: revents = 0x4, took 1258ns 78223: sio_revents: revents = 0x4, took 1187ns 95893: sio_revents: revents = 0x4, took 1257ns 000106788: sio_revents: revents = 0x4, took 1187ns 000117194: sio_revents: revents = 0x4, took 1187ns 0849340: clk+0 +0, wr+8 +0 rd:+0 +0 00020857890: clk+1 +0, wr+9 +0 rd:+0 +0 020856284: sio_revents: revents = 0x1, took 4330ns 020903706: sio_revents: revents = 0x0, took 1327ns 020928570: sio_revents: revents = 0x0, took 1327ns 00040880828: clk+2 +0, wr +10 +0 rd:+1 +0 040879291: sio_revents: revents = 0x1, took 5238ns 040912396: sio_revents: revents = 0x0, took 1257ns 040932370: sio_revents: revents = 0x0, took 1258ns 00060857879: clk+3 +0, wr +11 +0 rd:+2 +0 060856343: sio_revents: revents = 0x1, took 5098ns 060889308: sio_revents: revents = 0x0, took 1257ns 060908304: sio_revents: revents = 0x0, took 1258ns 00080882842: clk+4 +0, wr +12 +0 rd:+3 +0 080881515: sio_revents: revents = 0x1, took 3422ns 080911756: sio_revents: revents = 0x0, took 1257ns 080928937: sio_revents: revents = 0x0, took 1257ns 00100857728: clk+5 +0, wr +13 +0 rd:+4 +0 100856401: sio_revents: revents = 0x1, took 3492ns 100886852: sio_revents: revents = 0x0, took 1327ns 100904312: sio_revents: revents = 0x0, took 1327ns 00120890024: clk+6 +0, wr +14 +0 rd:+5 +0 120888697: sio_revents: revents = 0x1, took 3353ns 120918799: sio_revents: revents = 0x0, took 1187ns 120935770: sio_revents: revents = 0x0, took 1257ns 00140857647: clk+7 +0, wr +15 +0 rd:+6 +0 140856250: sio_revents: revents = 0x1, took 4051ns 140888238: sio_revents: revents = 0x0, took 1187ns 140905838: sio_revents: revents = 0x0, took 1257ns 00160902165: clk+8 +0, wr +16 +0 rd:+7 +0 160900908: sio_revents: revents = 0x1, took 3
Listening to a CD over the net
Since I seem to be the only person using this feature (with the possible exception of ratchov@ himself), here's a periodic reminder that you can use sndio OVER THE NETWORK. Optical drives are kind of passé, but I still keep a working USB one around. I hooked it up to a convenient machine--an old sparc64 with USB1.1, as it happens--slotted in an audio CD, then took my laptop and went into a different room. On the laptop I restarted sndiod with -L-, then ssh'ed to the machine with the CD and ran $ AUDIODEVICE=snd@laptop/0 cdio cdplay ... and that's it. Music in my laptop headphones. Because we can. Sndio doesn't have any built-in authentication. You can use ssh's port forwarding if you don't want to run it over the naked network. In my case, IPsec over the WPA2-secured wireless seemed enough. -- Christian "naddy" Weisgerber na...@mips.inka.de
Patch 009 fails on BASE-5.6 amd64
Hi All, I’ve just performed a fresh install of OpenBSD 5.6-BASE (not an upgrade) using the purchased disc set, and have been applying the patches in order, and all have been successful. However, the httpd patch (#009) has failed, and I ended up with several “rej” files. This system could not be more vanilla, no additional software was installed. The X packages and games were not installed. I have taken the output of the signify command which provides information about the specific failures, as well as the four rej files that were generated and put them into a tar archive if anybody would like to see the specifics of the failure. Here is a shared link from Dropbox: https://www.dropbox.com/s/yk9olnqdeeru7m6/009_httpd_failures.tar?dl=0 Has anybody else encountered this issue? I am holding off on applying the additional patches in the mean time. Please let me know if there is any additional information I can provide. Kind regards, Andrew Lester
Re: Patch 009 fails on BASE-5.6 amd64
Andrew Lester wrote: > Hi All, > > I’ve just performed a fresh install of OpenBSD 5.6-BASE (not an upgrade) > using the purchased disc set, and have been applying the patches in order, > and all have been successful. However, the httpd patch (#009) has failed, and > I ended up with several “rej” files. This system could not be more vanilla, > no additional software was installed. The X packages and games were not > installed. I have taken the output of the signify command which provides > information about the specific failures, as well as the four rej files that > were generated and put them into a tar archive if anybody would like to see > the specifics of the failure. Here is a shared link from Dropbox: > https://www.dropbox.com/s/yk9olnqdeeru7m6/009_httpd_failures.tar?dl=0 > > Has anybody else encountered this issue? I am holding off on applying the > additional patches in the mean time. Please let me know if there is any > additional information I can provide. The CDs shipped with a slightly different source tree, that missed a few changes to the httpd directory. You can use cvs to update the httpd, either to OPENBSD_5_6_BASE and apply the patch, or to OPENSD_5_6 which is simpler. I should add a note to the web page; we didn't discover this until some time after the patch. Thanks for reminding me.
IPSEC/IKED flows only being created on one end
Hello misc@, I am working on setting up site to site ipsec VPN between a few locations all with openbsd 5.6 stable "gateways" at them using iked. Since I've never done any of this before I am starting with a basic host to host setup using pre shared keys in my lab. I am running into an issue where the flows are only getting created on one end of the setup. Here are the details: HOST 1: ip address 172.16.204.139 iked.conf: ikev2 "test" active esp from 172.16.204.139 to 172.16.204.140 psk "test" HOST 2: ip address 172.16.204.139 iked.conf: ikev2 "test" esp from 172.15.204.140 to 172.16.204.139 psk "test" I then run /etc/rc.d/iked -f start on host 2. followed by the same command on host 1. after a few seconds I execute the ipsecctl -s all command on each host. on host 1 the out put is: FLOWS: flow esp out from ::/0 to ::/0 type deny SAD: No entries While on host 2 the output is: FLOWS: flow esp in from 172.16.204.139 to 172.16.204.140 peer 172.16.204.139 srcid FQDN/gwb.localdomain dstid FQDN/gwa.localdomain type use flow esp out from 172.16.204.140 to 172.16.204.139 peer 172.16.204.139 srcid FQDN/gwb.localdomain dstid FQDN/gwa.localdomain type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 172.16.204.139 to 172.16.204.140 spi 0x0982384f auth hmac-sha2-256 enc aes-256 esp tunnel from 172.16.204.140 to 172.16.204.139 spi 0x78b6bb97 auth hmac-sha2-256 enc aes-256 If I reverse which host is the "active" the results flip flop. That is the flows are always created on the "passive" side. I expect similar flows should be created on each side or am I missing something completely here? Can someone please point me in the right direction? Also I can include a dmeag if needed. Thanks, -- Joshua Smith Montani Semper Liberi
Re: IPSEC/IKED flows only being created on one end
On Sat, Mar 07, 2015 at 08:29:43PM -0500, Joshua Smith wrote: > Hello misc@, > > I am working on setting up site to site ipsec VPN between a few locations all > with openbsd 5.6 stable "gateways" at them using iked. Since I've never done > any of this before I am starting with a basic host to host setup using pre > shared keys in my lab. I am running into an issue where the flows are only > getting created on one end of the setup. Here are the details: > > HOST 1: > ip address 172.16.204.139 > iked.conf: ikev2 "test" active esp from 172.16.204.139 to 172.16.204.140 psk > "test" > > HOST 2: > ip address 172.16.204.139 > iked.conf: ikev2 "test" esp from 172.15.204.140 to 172.16.204.139 psk "test" Hi there. Don't use PSKs with iked(8) and 5.6. Use certs, or use -current. http://marc.info/?l=openbsd-misc&m=141562487120440&w=2
Re: IPSEC/IKED flows only being created on one end
> On Mar 7, 2015, at 10:39 PM, Josh Grosse wrote: > >> On Sat, Mar 07, 2015 at 08:29:43PM -0500, Joshua Smith wrote: >> Hello misc@, >> >> I am working on setting up site to site ipsec VPN between a few locations >> all with openbsd 5.6 stable "gateways" at them using iked. Since I've never >> done any of this before I am starting with a basic host to host setup using >> pre shared keys in my lab. I am running into an issue where the flows are >> only getting created on one end of the setup. Here are the details: >> >> HOST 1: >> ip address 172.16.204.139 >> iked.conf: ikev2 "test" active esp from 172.16.204.139 to 172.16.204.140 psk >> "test" >> >> HOST 2: >> ip address 172.16.204.139 >> iked.conf: ikev2 "test" esp from 172.15.204.140 to 172.16.204.139 psk "test" > > Hi there. Don't use PSKs with iked(8) and 5.6. Use certs, or use -current. > > http://marc.info/?l=openbsd-misc&m=141562487120440&w=2 Hi Josh, Thanks for pointing this out to me. Seems my search-too wasn't strong enough o dig that out. I'll give it another go with RSA in the morning. That might be the best way to go for my small setup instead of deploying a CA anyhow. Guess that just gives me another option to weigh. -- Joshua Smith Montani Semper Liberi Sent from my iPhone
Re: Listening to a CD over the net
On Sun, Mar 08, 2015 at 01:57:05AM +0100, Christian Weisgerber wrote: > Since I seem to be the only person using this feature (with the > possible exception of ratchov@ himself), here's a periodic reminder > that you can use sndio OVER THE NETWORK. > > Optical drives are kind of pass?, but I still keep a working USB > one around. I hooked it up to a convenient machine--an old sparc64 > with USB1.1, as it happens--slotted in an audio CD, then took my > laptop and went into a different room. > > On the laptop I restarted sndiod with -L-, then ssh'ed to the machine > with the CD and ran > > $ AUDIODEVICE=snd@laptop/0 cdio cdplay > > ... and that's it. Music in my laptop headphones. > > Because we can. > > Sndio doesn't have any built-in authentication. You can use ssh's > port forwarding if you don't want to run it over the naked network. > In my case, IPsec over the WPA2-secured wireless seemed enough. > > -- > Christian "naddy" Weisgerber na...@mips.inka.de This is cool, it seems ratchov@ included this feature in his Linux port.. http://www.sndio.org/install.html Something horrible like this lets me listen to music on a Linux laptop (headphones), streamed from my OpenBSD desktop with no speakers: # ip6tables -A INPUT -p tcp -s fe80::/64 --dport 11025 -m state \ --state NEW -j ACCEPT $ D_LIBRARY_PATH=. ./sndiod -L fe80::blah%wlan0 Because.. we.. can? :-) -Bryan.
support new
0 C Canada P British Columbia T Victoria Z V9A 6Z7 O Mighty Oaks I Elder Matias A 27 Burnside Road West M i...@mightyoaks.com U http://www.mightyoaks.com/ B 250-386-9398 X 250-386-9399 N Over 20 years experience working with UNIX based systems (including OpenBSD) in Scientific, GIS and database applications. We have a strong focus in computer security, networking and custom software. Authorised reseller for Dell, HP and Lenovo. We able to offer OpenBSD based solutions running on name brand hardware. This e-mail is intended only for the person to whom it is addressed (the "addressee") and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use that a person other than the addressee makes of this communication is prohibited and any reliance or decisions made based on it, are the responsibility of such person. We accept no responsibility for any loss or damages suffered by any person other than the addressee as a result of decisions made or actions taken based on this communication or otherwise. If you received this in error, please contact the sender and destroy all copies of this e-mail. Ce courrier est strictement reservé a l'usage de la personne a qui il est adressé (le destinataire). Il peut contenir de l'information privilégiée et confidentielle. L'examen, la réexpédition et la diffusion de ce message par une personne autre que son destinataire est interdite. Nous refusons toute responsabilité a l'égard des pertes ou des dommages subis par une personne autre que le destinataire par suite de decisions ou de mesures fondées sur le contenu de cette communication ou autrement. Si vous avez recu ce courrier par erreur, veuillez communiquer avec son expéditeur et en détruire toutes les copies.
