NextCloud: failed integrity checks
After installation on OpenBSD 6.3 with pkg_add, NextCloud complains about files failing the integrity checks. More specifically: - occ * expected hash: 7e3fce0d7b5c20a7775ed1b548cb2e29bed078d3ca77b01a83d438f671b3d473147d4e8217d2084e17b6fe23a18ba258b11ba60106e23381f1e2889ce14971c4 * current hash: 7693eb89c0bc218712d68ec58599efa46e5c3729814e2aad16bf2c0079be7ae1909f072ead7889883c0a89b6c51570800d9e8a71f35866cb4e0c47aeaa5a4b2b - version.php * expected hash: 4e9046aca4fd8e942ba7bd505374e22ddd500a99b3a46d57d629b99c3132a66206883053f22801894929e51fca307c740062b497d55639bcc9a3154ada3504ff * current hash: 30cd43589fc8ab273fa25e1a477c8cbadb13bac5541daa6d3fa0490a0c2054c2c29a274fd50eec66934a9d9adc541dec8701e7463922d36174478ae3e9a64981 - apps/updatenotification/appinfo/info.xml * expected hash: bf7983ffe422ba215c04a0069081fab0c78ba81fa40a90cbdd3595182e011fb7f3e0bd1cd14cdea742cafb89f1da001582fe8d560749d98ea540b4ee76dd9898 * current hash: d2984fa816b4cea71e7c09f36a4132e7cb88d357f22e1c795778deccdb4066beaef2876b95d849e6eeae37b879c0f63500b0958a6a61bab1c933736bf135c440 Anybody able to reproduce? --Nicolas
Re: Status of Owncloud?
Thanks for the hint ax0n, I'll give NextCloud a try; after all, I wasn't entirely happy with Owncloud anyway, as I had issues uploading large files (100 MB and bigger). @Mischa: Your diagnosis was correct: I completely forgot that there is some extra work to be done to make PHP/cURL work in jailroot. Besides "/etc/resolv.conf", I also had to copy /etc/ssl/cert.pem /etc/services /etc/php-5.6.ini to /var/www/etc/ to make things work. --Nicolas > Am 22.07.2018 um 19:31 schrieb Mischa : > > Besides that, in order to provide it an "internet" connection you need to > copy your resolv.conf to /var/www/etc/ > > Mischa > > >> On 22 Jul 2018, at 19:26, Ax0n wrote: >> >> On Jul 22, 2018 10:11, "Nicolas Schmidt" wrote: >> >> Hi, >> >> I just installed and configured owncloud on OpenBSD 6.3, and so far >> everything seems to work (except for owncloud complaining about not having >> an internet connection). However, when visiting http://localhost/owncloud/ >> after installation, I was greeted by an unfriendly message telling me that >> owncloud doesn't run properly on OpenBSD. This message didn't go into more >> details, nor could I find anything on owncloud.com or openbsd.org regarding >> this. >> >> So I'm wondering, what's the status of owncloud on OpenBSD? Is it still >> supported? Are there plans to remove support for it in future releases? >> >> Best, >> Nicolas >> >> >> I know this doesn't directly answer your question, but it seems like many >> users (especially within but not limited to the OpenBSD community) started >> preferring NextCloud ( https://nextcloud.com ) which appears to be >> maintained by several of the original OwnCloud developers. >> >> --ax0n
Status of Owncloud?
Hi, I just installed and configured owncloud on OpenBSD 6.3, and so far everything seems to work (except for owncloud complaining about not having an internet connection). However, when visiting http://localhost/owncloud/ after installation, I was greeted by an unfriendly message telling me that owncloud doesn't run properly on OpenBSD. This message didn't go into more details, nor could I find anything on owncloud.com or openbsd.org regarding this. So I'm wondering, what's the status of owncloud on OpenBSD? Is it still supported? Are there plans to remove support for it in future releases? Best, Nicolas
segfault when exiting a program
Hi, a while ago I posted on this list because of a problem I experienced with building OpenBSD 6.2-current from source (the base system, not the kernel). Today I found the culprit, and it's rather strange: returning from main(), or calling exit() explicitly causes a segmentation fault. A minimal example is: int main(int argc, char **argv) { return 0; } Evaluating cc -o test test.c; ./test should result in a segmentation fault. Here's the backtrace gdb gives me: #0 _libc___cxa_finalize () at /usr/src/lib/libc/stdlib/atexit.c:133 #1 0x0de4d9fb in _libc_exit (status=0) at /usr/src/lib/libc/stdlib/exit.c:54 #2 0x18bef421 in main () from /home/nico/test Anyone able to reproduce this? Best, Nicolas Schmidt
make_keys produces segfault when building 6.2-stable
I just tried building the base in 6.2-stable (building the kernel worked fine), following the instructions in https://man.openbsd.org/release. Unfortunately, the build process fails when trying to build libcurses. The error I get is ./make_keys keys.list > init_keytry.h Segmentation fault (core dumped) *** Error 139 in lib/libcurses (Makefile:123 'init_keytry.h') *** Error 1 in lib (:48 'all') *** Error 1 in . (Makefile:90 'do-build') *** Error 1 in /usr/src (Makefile:74 'build') Manually running `cd /usr/obj/lib/libcurses && ./make_keys key.list` also produces a Segmentation fault. Any ideas what's going on here? Best, Nicolas
Re: Upgrade 6.1->6.2 fails with "id 0 on/: file system full"
Thanks Tim, that was right on the money! Indeed my „/bsd“ was a symbolic link, pointing to „/bsd.mp“. Because the target path of the symlink was absolute, when it tried to write the new kernel to „./mnt/bsd“ it of course pointed to the ramdisk. After removing that symlink, the upgrade process went through without a hitch. TL;DR: Use relative paths when you symlink „/bsd“. Nicolas > Am 20.02.2018 um 15:42 schrieb trondd : > >> On Tue, February 20, 2018 8:34 am, Nicolas Schmidt wrote: >> Hey, >> >> it's me again, still trying to upgrade to 6.2. >> >> After choosing to skip verification and continue the upgrade process, I >> now immediately get the following error: >> >>Installing bsd0% | >>id 0 on /: file system full >> >>/: write failed, file system full >>ftp: Writing -: No space left on device >> >> Going to a shell, "df" reveals >> >>Filesystem512-blocksUsedAvailCapacityMounted on >>/dev/rd0a 61436116 27100%/ >>/dev/sd2a 2057756179068 1775804 9%/mnt >>. >>. >>. >> >> To me it seems, the install script is trying to install the kernel on the >> ram disk mounted on / instead of the actual root partition mounted on /mnt >> (sd2 is the volume I chose for installation; it's a RAID 1). Since the ram >> disk is full, this of course has to fail. >> >> Any suggestions? >> >> Best regards and thanks for your help, >> Nicolas >> > > This just came up on Daemonforums. The user had a symlink pointing to an > absolute path starting with /. The installer follows that symlink to the > ramdisk / instead of /mnt. > > http://daemonforums.org/showthread.php?p=63885 > > Tim.
Upgrade 6.1->6.2 fails with "id 0 on/: file system full"
Hey, it's me again, still trying to upgrade to 6.2. After choosing to skip verification and continue the upgrade process, I now immediately get the following error: Installing bsd 0% | id 0 on /: file system full /: write failed, file system full ftp: Writing -: No space left on device Going to a shell, "df" reveals Filesystem 512-blocks UsedAvail CapacityMounted on /dev/rd0a 6143 6116 27 100%/ /dev/sd2a 2057756179068 1775804 9%/mnt . . . To me it seems, the install script is trying to install the kernel on the ram disk mounted on / instead of the actual root partition mounted on /mnt (sd2 is the volume I chose for installation; it's a RAID 1). Since the ram disk is full, this of course has to fail. Any suggestions? Best regards and thanks for your help, Nicolas
Re: SHA256.sig not contained in install62.iso
Sorry, I of course meant to say it‘s *not* on it. > Am 20.02.2018 um 12:56 schrieb Nicolas Schmidt : > > Hi, > > I am finally getting around to upgrading 6.1->6.2. When I try to install from > CD using the install62.iso image, the install script complains that it can't > find SHA256.sig (indeed, it's on it). > > Is that supposed to happen? > > Best, > Nicolas A. Schmidt
SHA256.sig not contained in install62.iso
Hi, I am finally getting around to upgrading 6.1->6.2. When I try to install from CD using the install62.iso image, the install script complains that it can't find SHA256.sig (indeed, it's on it). Is that supposed to happen? Best, Nicolas A. Schmidt
Re: Integrating "safe" languages into OpenBSD?
> Am 04.12.2017 um 14:45 schrieb Nick Holland : ... > > Oh yeah. > I recently discovered a very major business operations application where > rather than using the OS's FTP and SFTP functions, they wrote their own > in "safe" Java. I don't know why. ... > If the other machine is being serviced? Network broke? receiving > machine unable to recieve? Oh well. Magic doesn't work, the file is > lost, without alerting the "sending" program. > > Error reporting? Well, for a long time, I thought it was non-existent, > but I recently found they just dumped all the java runtime output to a > file. Nothing is actually done with this info in the application, but > if 100+ lines of J-crap is your favorite way to see "server timeout", > this is your tool. ... > Nick. So they wrote a program that was a) shitty and b) memory-safe? Those are two orthogonal dimensions. Also, the anecdotal evidence that safe languages attract bad programmers does not imply that using safe languages is bad: a good programmer won't suddenly commit such atrocities as you mentioned, just because they use a safe language. Finally, your example probably speaks more about business practices than about safe programming languages. If you want to compare Java to a non-memory-safe language, you should compare it to one that is also designed *for* (instead of *by*) programmers, like Cobol.
Integrating "safe" languages into OpenBSD?
Hi, I recently watched a recording of Theo's talk on pledge at EuroBSDCon 2017, in which the question of memory-safe languages and their practical usefulness came up. Specifically, someone in the audience criticized the approach taken by OpenBSD, which (as I understand) accepts that all software is broken and mitigates the damage caused by various classes of exploits through techniques like ASLR, and suggested that instead one should stick to "memory safe languages" to avoid these exploits altogether. As a response to this, Theo asked rhetorically "Where's ls, where's cat, where's grep, and where's sort?", implying that noone so far bothered to write implementations of even the basic unix utilities in such a language. This brings me to the question, what if someone actually bothered? Under what conditions would you consider replacing one of the current C implementations with an implementation written in another, "safer" language? Note that with Cgrep and haskell-ls, there do in fact exist implementations/analogues of two of the mentioned utilities in a memory safe language (Haskell). Best, Nicolas Schmidt
Re: About WPA2 compromised protocol
Can this issue even be fixed on the AP side? You could change the AP‘s behaviour to never ever resend Message 3, but that seems very drastic. As far as I understood the article by Vanhoef and Piessens, the vulnerability lies within the behavior of the client (that conforms to the 802.11i amendment), as it still accepts retransmissions of Message 3 even if it is already in the PTK-DONE state. — Nicolas Schmidt > Am 17.10.2017 um 19:15 schrieb Matthew Graybosch : > > On Tue, 17 Oct 2017 19:09:29 +0200 > "Stephane HUC \"PengouinBSD\"" wrote: > >> Just for the fun: >> http://www.commitstrip.com/en/2017/10/16/wpa2-vulnerability-just-a-small-update/ > > I saw somebody share that on Mastodon this morning. :) > > On a more serious note; am I correct in assuming that the patch is > already in 6.2? > > -- > Matthew Graybosch > https://matthewgraybosch.com > > "If you didn't want me to say 'both', you should have used XOR."
Re: permission denied local nfs mount
Did you try setting an explicit netmask? > Am 29.07.2017 um 01:36 schrieb Allan Streib : > > 6.1 amd64 release > > My goal is to serve files from a directory in my home dir via httpd. As > I understand it the way to do this is a local NFS mount in the httpd > chroot. > > Basically following the FAQ for NFS I set up this: > > $ cat /etc/exports > /home/astreib/work/new-site.org -ro -network=127.0.0.1 > > $ showmount -e > Exports list on localhost: > /home/astreib/work/new-site.org127.0.0.1 > > $ doas mount -t nfs 127.0.0.1:/home/astreib/work/new-site.org > /var/www/htdocs/new-site > mount_nfs: can't access /home/astreib/work/new-site.org: Permission denied > > Everyhing works if I remove the "-network=" from /etc/exports, i.e.: > > /home/astreib/work/new-site.org -ro 127.0.0.1 > > I don't really understand why? > > Allan
Re: Can I use OpenBSD as a desktop system?
>> On 06/09/17 15:39, SOUL_OF_ROOT 55 wrote: >> Can I use OpenBSD as a desktop system? > > You? No, I doubt it. ... > But, you are welcome, and invited ... > Nick. Nick, I don't think you were being either welcoming or inviting there. To answer OP's question: Yes of course you can, and I did so in the past. The experience wasn't bad, although of course using any free Unix as a desktop system is guaranteed to deliver some pain at least (don't expect it to "just work"). Nicolas
kernel panic: ehci_device_clear_toggle
Hi, I just installed OpenBSD 6.1 and set up a CUPS server with a usb printer, and I'm experiencing kernel panics that seem usb related. These kernel panics actually occured also on the old version of OpenBSD I upgraded from, but only very rarely (once every few months a most). Now I've had three panics in the course of a few hours. The irony is that one of the reasons for upgradings was this exact problem; I assumed it would have been fixed, as it was mentioned on this list already. I would like to file a bug report, but I can't gather all the infos asked for https://www.openbsd.org/ddb.html, as the keyboard stops working after the kernel panic (probably because it's a usb keyboard). So, here's the output I can give you: # panic: ehci_device_clear_toggle: queue active Stopped at Debugger+0x7: leave TID PID UID PRFLAGS PFLAGS CPU COMMAND *359035 78367 541 0x1002 0x8 1 usb 216484 46276 0 0x14000 0x200 0 reaper Debugger(d0a08f55,f54ee848,d09d62e0,f54ee848,0) at Debugger+0x7 panic(d09d62e0,dbaed460,f54ee88c,d08a0895,0) at panic+0x71 ehci_device_clear_toggle(d5d8ff00,d5d8ff00,d5a02800,0,2) at ehci_device_clear_toggle+0x29 usbd_clear_endpoint_stall(d5d8ff00,d5d8ff00,0,f54ee8dc,400) at usbd_clear_endpoint_stall+0x20 ugen_do_write(d5aa,1,f54eee8c,1,f54eed10) at ugen_do_write+0x2a8 ugenwrite(3f01,f54eee8c,1,d0508d09,db91169c) at ugenwrite+0x4f spec_write(f54eedb8,db7b2aa4,f54eee74,d03cd5e9,d0bf6ae0) at spec_write+0xa7 VOP_WRITE(dba0fccc,f54eee8c,1,dbaf2c00,17a8840) at VOP_WRITE+0x42 vn_write(db91169c,db91116b4,f54eee8c,dbaf2c00,d0bf6ae0) at vn_write+0x8a dofilewritev(db7b2aa4,8,db91169c,f54eeef4,1) at dofilewritev+0x1c6 sys_write(db7b2aa4,f54eef5c,f54eef7c,0,200286) at sys_write+0x8f syscall() at syscall+0x250 --- syscall (number -813756072) --- 0x6: One piece of context: the uid 541 is the user _cups, under which cupsd runs. Best, Nicolas
Re: torrent downloads
Many distros sport torrents: NetBSD, Debian, and Ubuntu to name some. Rationale behind this is simple: torrents download with ridiculous speed if they are popular enough. Best, Nicolas > Am 27.04.2017 um 14:36 schrieb Markus Rosjat : > > Hi, > > I think it's kinda pointless to have a torrent for this. You got enough good > mirrors to download from anyway. And nowadays it's not a biggy to download a > iso or so of somewhat 200mb. > > and yes I'm the proud owner of some awesome puffy shirts too (if someone is > concerned about the download part :-P ) > > regards > > markus > >> Am 27.04.2017 um 13:55 schrieb Thuban: >> Hello, >> I was wondering if there is any particular reason explaining why there >> is no torrent file to retrieve OpenBSD *.fs and *.iso. >> >> I've been looking on the list and only found this site that doesn't >> seems up to date [1]. >> >> If the reason is a lack of human ressources, I think I can handle it. >> >> Regards. >> >> [1] : http://openbsd.somedomain.net/ >> > > -- > Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de > > G+H Webservice GbR Gorzolla, Herrmann > Königsbrücker Str. 70, 01099 Dresden > > http://www.ghweb.de > fon: +49 351 8107220 fax: +49 351 8107227 > > Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you > print it, think about your responsibility and commitment to the ENVIRONMENT
Re: IPPORT_RESERVED 'security' check in nfsd obsolete?
Am 19.01.2017 um 12:21 schrieb Theo de Raadt : >> Then may I suggest to add an option to disable this behaviour for specific mounts >> ounts? > > No. > > NFS always required reserved ports. Do you mean that the "reserved ports restriction" is required as part of the NFS protocol spec? I took a look at https://tools.ietf.org/html/rfc7530 , but couldn't find anyhing related to that.
Re: IPPORT_RESERVED 'security' check in nfsd obsolete?
> Am 19.01.2017 um 01:20 schrieb Theo de Raadt : > > No, this change will not be done. Then may I suggest to add an option to disable this behaviour for specific mounts? NetBSD provides the "-noresvport" flag for this. The following quote is from the NetBSD man for exports: "The -noresvport option specifies that NFS RPC calls for the filesystem do not have to come from reserved ports. Normally, clients are required to use reserved ports for operations. Using this option decreases the security of your system."
IPPORT_RESERVED 'security' check in nfsd obsolete?
Hello everyone, I'd like to make a suggestion regarding NFS in OpenBSD; let me apologize in advance if this isn't the right place to make this suggestion. Currently (at least on 5.8, I haven't upgraded yet), the nfs daemon refuses to accept a mount request if it comes from a non-privileged port (>= IPPORT_RESERVED). As I understand, this was once a 'security feature' in the time of mainframes, when access to computer was restricted. In any case, I believe this behaviour should be changed as it does not provide security, and also leads to problems: for example, it means one has to use the markably slower SMB protocol when using an OpenBSD server as a remote mount on a FireTV stick (my use case). I therefore propose to remove this source port check from the nfs code, or alternatively, to add an option to export nfs volumes without this check. The first thing can e.g. be accomplished by modifying the OpenBSD source in two places, as follows (patches for 5.8): patch /usr/src/sbin/mountd/mountd.c < mountd.patch patch /usr/src/sys/nfs/nfs_subs.c < nfs_subs.patch where ### start of mountd.patch ### 369c369 < if (sport >= IPPORT_RESERVED) { --- > if (0 == 1) { // don't fail when sport >= IPPORT_RESERVED 467c467 < if (sport >= IPPORT_RESERVED) { --- > if (0 == 1) { //don't fail when sport >= IPPORT_RESERVED 483c483 < if (sport >= IPPORT_RESERVED) { --- > if (0 == 1) { //don't fail when sport >= IPPORT_RESERVED ### end of mountd.patch ### ### start of nfs_subs.patch ### 1455c1455 < (ntohs(saddr->sin_port) >= IPPORT_RESERVED || --- > (0 == 1 || // don't fail when sport >= IPPORT_RESERVED ### end of nfs_subs.patch ### Best, Nicolas Schmidt