Re: TLS certificates for NFS-over-TLS floating client
Miroslav Lachman wrote: >Rick Macklem wrote on 2020/03/19 03:09: >> Miroslav Lachman wrote: >>> >> [...] > >>> NFS (or any other server) should check list of revoked certificates too. >>> Otherwise you will not be able to deny access to user which you no >>> longer want to have an access. >> Yes, good point. >> I won't claim to understand this stuff, but from what I can see, all that is >> done is the CRL is appended to the CAfile (the one with the CA certificates >> are in being used for certificate verification via >> SSL__CTX_load_verify_locations(). >> >(https://raymii.org/s/articles/OpenSSL_manually_verify_a_certificate_against_a_CRL.html >> shows a CAfile and CRLfile being concatenated and then used to verify a >> certificate.) >> >> There is code in sendmail that loads a CRL file separately, but it seems to >> just put it in the X509 store returned by SSL_CTX_get_cert_store(), which >> is the one where the CAfile certificates are stored via >> SSL_CTX_load_verify_locations(), >> I think? >> (It just seems easier to append it to CAfile than do this. The sendmail code >> uses >> poorly documented functions where the man page says >> "SSL_CTX_load_verify_locations()" normally takes care of this.) >> >> Does this sound right? rick > >I think it would be better to have it in a separate file as Apache does >https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcarevocationfile > >Seems more convenient to have CA file write protected (read only) and >then separate file for list of revoked client certificates, maybe >somewhere else than CA certificate. Done. (Actually, the SSL_CTX_load_verify_locations() failed when the CRL was appended to the CAfile, so I needed to use a separate file to get it working.) I found X509_load_crl_file(), which does all the glop in sendmail's tls.c file to do it. (And it looks like the sendmail code only handles a CRL file with a single entry in it.) Thanks for the comments, rick Kind regards Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
Jan Bramkamp wrote: >On 20.03.20 02:44, Russell L. Carter wrote: >> Here I commit heresy, by A) top posting, and B) by just saying, why >> not make it easy, first, to tunnel NFSv4 sessions through >> e.g. net/wireguard or sysutils/spiped? NFS is point to point. >> Security infrastructure that actually works understands the shared >> secret model. > >Why not use IPsec in transport mode instead of a tunnel? It avoids >unnecessary overhead and is already implemented in the kernel. It should >be enough to "just" require IPsec for TCP port 2049 and run a suitable >key exchange daemon. I think the problem with these suggestions is interoperability. The draft (that should soon become an RFC) describes use of RPC-over-TLS and since the authors are both Linux NFS developers, I expect Linux to implement this someday. Once the Linux client can do it, the NFS server vendors will implement it. NFS isn't great, but it is supported by a variety of vendors/systems and I see that as one of its main features. rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
On 20.03.20 20:45, John-Mark Gurney wrote: Jan Bramkamp wrote this message on Fri, Mar 20, 2020 at 18:51 +0100: On 20.03.20 02:44, Russell L. Carter wrote: Here I commit heresy, by A) top posting, and B) by just saying, why not make it easy, first, to tunnel NFSv4 sessions through e.g. net/wireguard or sysutils/spiped? NFS is point to point. Security infrastructure that actually works understands the shared secret model. VPN tunneling doesn't provide the security that most people thinks it does... It requires complicated configuration, and often doesn't provide e2e protections. I fully agree that IPsec is a bitch to configure, but IPsec tranport mode between NFSv4 client and server would provide end to end encryption. Why not use IPsec in transport mode instead of a tunnel? It avoids unnecessary overhead and is already implemented in the kernel. It should be enough to "just" require IPsec for TCP port 2049 and run a suitable key exchange daemon. Because IPsec is a PITA to configure and work, and lots of consumer OSes don't make it at all easy. Does any consumer OS support NFSv4 over TLS? Also, you forget that FreeBSD has ktls, which usees the same crypto offload engine that IPsec does, so it will effectively have similar overhead, and might actually perform better due to TLS having a 16k record encryption size vs IPsec limiting itself to packet size, usually 1500, though possibly 9k if you're using jumbo frames... I compared IPsec to userspace tunnels like spiped or wireguard-go not kTLS. If kTLS can use LRO/TSO etc. it would avoid even more overhead. I fully support doing NFS over TLS. I would love to run NFS over TLS, but it isn't implemented yet and afaik kTLS only accelerates TLS sending and would require a userspace proxy to receive TLS at the moment while IPsec transport mode is just a nasty fight with strongSwan away. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
users of xorg, in particular on FreeBSD 11.3
[ This is cross-posted across several mailing lists for maximum visibility. Please respect reply-to and keep replies to x...@freebsd.org . Thank you! ] In order to improve support when using evdev to manage input devices, in particular keyboards, we have switched the default in x11/libxkbcommon to the evdev instead of the legacy ruleset. This was done in ports r528813 . On FreeBSD 11.3, the default configuration still requires the legacy ruleset. If you are using FreeBSD 11.3, or if you are using xf86-input-keyboard on FreeBSD 12 or later, you need to change the ruleset used by x11/libxkbcommon. If you have issues with your keyboard, most notably arrow keys, and if /var/log/Xorg.*.log shows that the "kbd" or "keyboard" driver is being used, you need to switch to legacy rules by setting the environment variable XKB_DEFAULT_RULES to xorg. The easiest way to accomplish this is by adding it to your shell startup file. As an example, for users of [t]csh, put setenv XKB_DEFAULT_RULES xorg in ~/.login For users of bourne type shells (sh, bash, ksh, zsh, ...) instead put export XKB_DEFAULT_RULES=xorg in ~/.profile Regards -- Niclas Zeising FreeBSD Graphics Team ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
John-Mark Gurney wrote on 2020/03/20 20:29: Rick Macklem wrote this message on Thu, Mar 19, 2020 at 23:41 +: [...] Without a problem statement or what you're trying to accomplish, it's hard to say if it is. The problem I was/am trying to solve was a way for NFS clients without a fixed IP/DNS name could have a certificate to allow access to the NFS server. As suggested by others, having a site local CA created by the NFS admin. seemed Yes, I totally agree w/ this as the best solution. It also allows private hostnames to be used w/o leaking outside the org.. It'd be nice to have better tooling around the CA though. I still haven't found any good tools that make a CA simple to use for small installs... (and by simple, I mean single init command, and single command to issue a cert or generate a key/cert pair, all of them are like, make all thesse directories, edit these files, and run these comlicated commands) security/easy-rsa is very close to this. # easyrsa init-pki # easyrsa build-ca # easyrsa build-server-full # easyrsa build-client-full # easyrsa build-client-full # easyrsa build-client-full or # easyrsa build-client-full nopass And usually # easyrsa gen-dh With "build-ca" you will create key and certificate for you private CA With "build-server-full" you will create key and certificate for your server With "build-client-full" you will create key and certificate for clients It also supports "revoke" and "gen-crl" to revoke compromised certificate and update CRL. Yes, it could be made a bit simpler and run init-pki in the background if build-ca is run for the first time so you can save one step. I don't say easy-rsa is the best choice. I am able to use full openssl commands or write my own tools / scripts around it I choose easy-rsa on machines where somebody else needs to work with certs. [...] Kind regards Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
Jan Bramkamp wrote this message on Fri, Mar 20, 2020 at 18:51 +0100: > On 20.03.20 02:44, Russell L. Carter wrote: > > Here I commit heresy, by A) top posting, and B) by just saying, why > > not make it easy, first, to tunnel NFSv4 sessions through > > e.g. net/wireguard or sysutils/spiped? NFS is point to point. > > Security infrastructure that actually works understands the shared > > secret model. VPN tunneling doesn't provide the security that most people thinks it does... It requires complicated configuration, and often doesn't provide e2e protections. > Why not use IPsec in transport mode instead of a tunnel? It avoids > unnecessary overhead and is already implemented in the kernel. It should > be enough to "just" require IPsec for TCP port 2049 and run a suitable > key exchange daemon. Because IPsec is a PITA to configure and work, and lots of consumer OSes don't make it at all easy. Also, you forget that FreeBSD has ktls, which usees the same crypto offload engine that IPsec does, so it will effectively have similar overhead, and might actually perform better due to TLS having a 16k record encryption size vs IPsec limiting itself to packet size, usually 1500, though possibly 9k if you're using jumbo frames... I fully support doing NFS over TLS. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
Rick Macklem wrote this message on Thu, Mar 19, 2020 at 23:41 +: > John-Mark Gurney wrote: > >Rick Macklem wrote this message on Wed, Mar 04, 2020 at 03:15 +: > >> I am slowly trying to understand TLS certificates and am trying to figure > >> out how to do the following: > >> -> For an /etc/exports file with... > >> /home -tls -network 192.168.1.0 -mask 255.255.255.0 > >> /home -tlscert > > > >Are you looking at implementing draft-cel-nfsv4-rpc-tls? > Yes. The 2 week out of date (I can only do commits once in a while these > days) can > be found in FreeBSD's subversion under base/projects/nfs-over-tls. Nifty. And looks like you know about the ktls stuff, nice... > >> This syntax isn't implemented yet, but the thinking is that clients on the > >> 192.168.1 subnet would use TLS, but would not require a certificate. > >> For access from anywhere else, the client(s) would be required to have a > >> certificate. > >> > >> A typical client mounting from outside of the subnet might be my laptop, > >> which is using wifi and has no fixed IP/DNS name. > >> --> How do you create a certificate that the laptop can use, which the NFS > >>server can trust enough to allow the mount? > >> My thinking is that a "secret" value can be put in the certificate that > >> the NFS > >> server can check for. > >> The simplest way would be a fairly long list of random characters in the > >> organizationName and/or organizationUnitName field(s) of the subject name. > >> Alternately, it could be a newly defined extension for X509v3, I think? > >> > >> Now, I'm not sure, but I don't think this certificate can be created via > >> a trust authority such that it would "verify". However, the server can > >> look for the "secret" in the certificate and allow the mount based on that. > >> > >> Does this sound reasonable? > > > >Without a problem statement or what you're trying to accomplish, it's > >hard to say if it is. > The problem I was/am trying to solve was a way for NFS clients without a > fixed IP/DNS name could have a certificate to allow access to the NFS server. > As suggested by others, having a site local CA created by the NFS admin. > seemed Yes, I totally agree w/ this as the best solution. It also allows private hostnames to be used w/o leaking outside the org.. It'd be nice to have better tooling around the CA though. I still haven't found any good tools that make a CA simple to use for small installs... (and by simple, I mean single init command, and single command to issue a cert or generate a key/cert pair, all of them are like, make all thesse directories, edit these files, and run these comlicated commands) Another option is to just use self sign certs and manually add each one for a host, not sure how difficult this would be in code... This would probably be easiest w/ a small number of clients, eliminates the difficulty of doing a CRL/OSCP, as if a client gets compromised, you just delete their cert till a new one is issued... > to be the best solution. The server can verify that the certificate was > issued by > the local CA. Unfortunately, if the client is compromised and the certificate > is copied > to another client, that client would gain access. This is why CRLs/OSCP is necessary, but there isn't anything you can do to prevent that. This is both a better situation than what we have today (no auth/confidentiality), and if you tie the cert to an IP, it's of limited use, and better than today... > --> I've thought of having the client keep the certificate encrypted in a > file and >require the "user" of the client type in a passphrase to unencrypt the > certificate >so that it can be used by the daemon in the client that handles the > client side >of the TLS handshake, but I have not implemented this. >--> This would at least subvert the simple case of the certificate > file being copied > to a different client and being used to mount the NFS server, > but if the > client is compromised, then the passphrase could be captured > and... Exactly. Just make sure that it's clear how to handle a revoked certificate when this happens, and you're good... > >> Also, even if the NFS client/server have fixed IP addresses with well known > >> DNS names, it isn't obvious to me how signed certificates can be acquired > >> for them? > >> (Lets Encrypt expects the Acme protocol to work and that seems to be > >> web site/http specific?) > > > >There is DNS challenges that can be used. I use them to obtain certs > >for SMTP and SIP servers... using nsupdate, this is relatively easy to > >automate pushing the challenges to a DNS server, and I now use DNS > >challenges for everything, including https. > Since my internet connection is a single dynamically assigned IP from the > phone > company, I doubt this would work for me (which I why I say I don't know how > to do this). I suspect there are ways and it would be nice if you
Re: TLS certificates for NFS-over-TLS floating client
On 20.03.20 02:44, Russell L. Carter wrote: Here I commit heresy, by A) top posting, and B) by just saying, why not make it easy, first, to tunnel NFSv4 sessions through e.g. net/wireguard or sysutils/spiped? NFS is point to point. Security infrastructure that actually works understands the shared secret model. Why not use IPsec in transport mode instead of a tunnel? It avoids unnecessary overhead and is already implemented in the kernel. It should be enough to "just" require IPsec for TCP port 2049 and run a suitable key exchange daemon. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cannot build 12.1-RELEASE on latest current-snapshot
On Fri, Mar 20, 2020, 11:12 AM Dimitry Andric wrote:
> On 20 Mar 2020, at 10:55, h v wrote:
> >
> > buildworld for 12.1-RELEASE fails on recent current.. in stage 3: cross
> > tools (see below)
> >
> > Did i miss newer Options/ Parameters (i checked UPDATING without
> > relevant changes)
> >
> > i'm also not attemting a cross build, simply compiling on amd64 for
> amd64.
> >
> > --- C U T ---
> >
> > --
> stage 3: cross tools
> > --
> > cd /usr/src/12.1; INSTALL="sh /usr/src/12.1/tools/install.sh"
> > TOOLS_PREFIX=/usr/obj/usr/src/12.1/amd64.amd64/tmp
> >
> PATH=/usr/obj/usr/src/12.1/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/12.1/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/12.1/amd64.amd64/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
> > WORLDTMP=/usr/obj/usr/src/12.1/amd64.amd64/tmp MAKEFLAGS="-m
> > /usr/src/12.1/tools/build/mk -m /usr/src/12.1/share/mk" make -f
> > Makefile.inc1 DESTDIR=
> > OBJTOP='/usr/obj/usr/src/12.1/amd64.amd64/tmp/obj-tools'
> > OBJROOT='${OBJTOP}/' MAKEOBJDIRPREFIX= BOOTSTRAPPING=1300084
> > BWPHASE=cross-tools SSP_CFLAGS= MK_HTML=no NO_LINT=yes MK_MAN=no
> > -DNO_PIC MK_PROFILE=no -DNO_SHARED -DNO_CPU_CFLAGS MK_WARNS=no
> > MK_CTF=no MK_CLANG_EXTRAS=no MK_CLANG_FULL=no MK_LLDB=no
> > MK_RETPOLINE=no MK_TESTS=no MK_INCLUDES=yes MK_LLVM_TARGET_ALL=no
> > TARGET=amd64 TARGET_ARCH=amd64 MK_GDB=no MK_TESTS=no cross-tools
> > ===> lib/clang (obj,all,install)
> > ===> lib/clang/libllvm (all)
> > [Creating objdir
> > /usr/obj/usr/src/12.1/amd64.amd64/tmp/obj-tools/lib/clang/libllvm...]
> > make[4]: "/usr/src/12.1/lib/clang/libllvm/Makefile" line 18: Please
> > enable at least one of: MK_LLVM_TARGET_AARCH64, MK_LLVM_TARGET_ARM,
> > MK_LLVM_TARGET_BPF, MK_LLVM_TARGET_MIPS, MK_LLVM_TARGET_POWERPC,
> > MK_LLVM_TARGET_RISCV, MK_LLVM_TARGET_SPARC, or MK_LLVM_TARGET_X86
> > *** Error code 1
>
> Looks like you have MK_LLVM_TARGET_ALL=no in your src.conf? Try removing
> it. Can you also post your make.conf and src.conf?
>
No. This was an error I committed. Update and try again. I had one too many
changes in the tree I pushed this morning.
Warner
-Dimitry
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cannot build 12.1-RELEASE on latest current-snapshot
On 20 Mar 2020, at 10:55, h v wrote:
>
> buildworld for 12.1-RELEASE fails on recent current.. in stage 3: cross
> tools (see below)
>
> Did i miss newer Options/ Parameters (i checked UPDATING without
> relevant changes)
>
> i'm also not attemting a cross build, simply compiling on amd64 for amd64.
>
> --- C U T ---
>
> --
stage 3: cross tools
> --
> cd /usr/src/12.1; INSTALL="sh /usr/src/12.1/tools/install.sh"
> TOOLS_PREFIX=/usr/obj/usr/src/12.1/amd64.amd64/tmp
> PATH=/usr/obj/usr/src/12.1/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/12.1/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/12.1/amd64.amd64/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
> WORLDTMP=/usr/obj/usr/src/12.1/amd64.amd64/tmp MAKEFLAGS="-m
> /usr/src/12.1/tools/build/mk -m /usr/src/12.1/share/mk" make -f
> Makefile.inc1 DESTDIR=
> OBJTOP='/usr/obj/usr/src/12.1/amd64.amd64/tmp/obj-tools'
> OBJROOT='${OBJTOP}/' MAKEOBJDIRPREFIX= BOOTSTRAPPING=1300084
> BWPHASE=cross-tools SSP_CFLAGS= MK_HTML=no NO_LINT=yes MK_MAN=no
> -DNO_PIC MK_PROFILE=no -DNO_SHARED -DNO_CPU_CFLAGS MK_WARNS=no
> MK_CTF=no MK_CLANG_EXTRAS=no MK_CLANG_FULL=no MK_LLDB=no
> MK_RETPOLINE=no MK_TESTS=no MK_INCLUDES=yes MK_LLVM_TARGET_ALL=no
> TARGET=amd64 TARGET_ARCH=amd64 MK_GDB=no MK_TESTS=no cross-tools
> ===> lib/clang (obj,all,install)
> ===> lib/clang/libllvm (all)
> [Creating objdir
> /usr/obj/usr/src/12.1/amd64.amd64/tmp/obj-tools/lib/clang/libllvm...]
> make[4]: "/usr/src/12.1/lib/clang/libllvm/Makefile" line 18: Please
> enable at least one of: MK_LLVM_TARGET_AARCH64, MK_LLVM_TARGET_ARM,
> MK_LLVM_TARGET_BPF, MK_LLVM_TARGET_MIPS, MK_LLVM_TARGET_POWERPC,
> MK_LLVM_TARGET_RISCV, MK_LLVM_TARGET_SPARC, or MK_LLVM_TARGET_X86
> *** Error code 1
Looks like you have MK_LLVM_TARGET_ALL=no in your src.conf? Try removing
it. Can you also post your make.conf and src.conf?
-Dimitry
signature.asc
Description: Message signed with OpenPGP
Re: HOWTO donate CPU to the fight against the Corona-virus
Quoting Jonathan Anderson (from Fri, 20 Mar 2020 10:21:11 -0230): Hi all, Running this on a 12.1-STABLE system, I see a whole lot of this in /var/log/messages: fahclient[53019]: ^[[91m12:15:25:ERROR:WU00:FS00:Exception: Could not get an assignment^[[0m Is this because there temporarily isn't enough work to go around, or because more FreeBSD support is required on the work distribution end as well? This means he was not able to download a work unit. This can either be a network problem, or that the pool of WUs is depleted. At the WE when I tried to get this working even my Windows Laptop didn't receive WUs. Yesterday to today I got WUs non-stop (but it takes some hours to process a WU... my dual-socket Xeon system processes a WU since yesterday 11pm and is currently at 50% of the WU). Be patient, they are adding WUs as fast as they can. You can check in the forum for more info about this: https://foldingforum.org/viewforum.php?f=18=64ecf0e5c256f1bdbb767fcc8a2661c2 Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgptMNutdAxTd.pgp Description: Digitale PGP-Signatur
Re: HOWTO donate CPU to the fight against the Corona-virus
On 3/20/20 1:51 PM, Jonathan Anderson wrote: Hi all, Running this on a 12.1-STABLE system, I see a whole lot of this in /var/log/messages: fahclient[53019]: ^[[91m12:15:25:ERROR:WU00:FS00:Exception: Could not get an assignment^[[0m Is this because there temporarily isn't enough work to go around, or because more FreeBSD support is required on the work distribution end as well? Either there is no work or you have to change the user name in the config file. I am not sure however if the username change is really a solution. Cheers, Mateusz ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HOWTO donate CPU to the fight against the Corona-virus
Hi all, Running this on a 12.1-STABLE system, I see a whole lot of this in /var/log/messages: fahclient[53019]: ^[[91m12:15:25:ERROR:WU00:FS00:Exception: Could not get an assignment^[[0m Is this because there temporarily isn't enough work to go around, or because more FreeBSD support is required on the work distribution end as well? Jon On Fri, 20 Mar 2020 at 08:37, Bob Bishop wrote: > Hi, > > Just a note that the client can grow its logfile at the rate of ~1GB a > day. You’ll probably want to take avoiding action. > > > On 19 Mar 2020, at 07:57, Alexander Leidinger via freebsd-stable < > freebsd-sta...@freebsd.org> wrote: > > > > Hi, > > > > if someone wants to donate some FreeBSD based CPU resources to the fight > against the Corona-virus, here is a quick HOWTO in terms of installing the > Folding@Home client on FreeBSD: > > > > > https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with-freebsd-foldinghome/ > > > > I tested this on a recent -current. > > > > If you are interested in how this helps in the fight against the virus, > please refer to the https://foldingathome.org/ website. In short and > over-simplified: they search for vaccines. > > > > Bye, > > Alexander. > > > > -- > > http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF > > http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF > > -- > Bob Bishop > r...@gid.co.uk > > > > > -- jonat...@freebsd.org http://freebsd.org/~jonathan/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HOWTO donate CPU to the fight against the Corona-virus
Hi, Just a note that the client can grow its logfile at the rate of ~1GB a day. You’ll probably want to take avoiding action. > On 19 Mar 2020, at 07:57, Alexander Leidinger via freebsd-stable > wrote: > > Hi, > > if someone wants to donate some FreeBSD based CPU resources to the fight > against the Corona-virus, here is a quick HOWTO in terms of installing the > Folding@Home client on FreeBSD: > > https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with-freebsd-foldinghome/ > > I tested this on a recent -current. > > If you are interested in how this helps in the fight against the virus, > please refer to the https://foldingathome.org/ website. In short and > over-simplified: they search for vaccines. > > Bye, > Alexander. > > -- > http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF -- Bob Bishop r...@gid.co.uk signature.asc Description: Message signed with OpenPGP
cannot build 12.1-RELEASE on latest current-snapshot
Dear List,
buildworld for 12.1-RELEASE fails on recent current.. in stage 3: cross
tools (see below)
Did i miss newer Options/ Parameters (i checked UPDATING without
relevant changes)
i'm also not attemting a cross build, simply compiling on amd64 for amd64.
--- C U T ---
--
>>> stage 3: cross tools
--
cd /usr/src/12.1; INSTALL="sh /usr/src/12.1/tools/install.sh"
TOOLS_PREFIX=/usr/obj/usr/src/12.1/amd64.amd64/tmp
PATH=/usr/obj/usr/src/12.1/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/12.1/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/12.1/amd64.amd64/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
WORLDTMP=/usr/obj/usr/src/12.1/amd64.amd64/tmp MAKEFLAGS="-m
/usr/src/12.1/tools/build/mk -m /usr/src/12.1/share/mk" make -f
Makefile.inc1 DESTDIR=
OBJTOP='/usr/obj/usr/src/12.1/amd64.amd64/tmp/obj-tools'
OBJROOT='${OBJTOP}/' MAKEOBJDIRPREFIX= BOOTSTRAPPING=1300084
BWPHASE=cross-tools SSP_CFLAGS= MK_HTML=no NO_LINT=yes MK_MAN=no
-DNO_PIC MK_PROFILE=no -DNO_SHARED -DNO_CPU_CFLAGS MK_WARNS=no
MK_CTF=no MK_CLANG_EXTRAS=no MK_CLANG_FULL=no MK_LLDB=no
MK_RETPOLINE=no MK_TESTS=no MK_INCLUDES=yes MK_LLVM_TARGET_ALL=no
TARGET=amd64 TARGET_ARCH=amd64 MK_GDB=no MK_TESTS=no cross-tools
===> lib/clang (obj,all,install)
===> lib/clang/libllvm (all)
[Creating objdir
/usr/obj/usr/src/12.1/amd64.amd64/tmp/obj-tools/lib/clang/libllvm...]
make[4]: "/usr/src/12.1/lib/clang/libllvm/Makefile" line 18: Please
enable at least one of: MK_LLVM_TARGET_AARCH64, MK_LLVM_TARGET_ARM,
MK_LLVM_TARGET_BPF, MK_LLVM_TARGET_MIPS, MK_LLVM_TARGET_POWERPC,
MK_LLVM_TARGET_RISCV, MK_LLVM_TARGET_SPARC, or MK_LLVM_TARGET_X86
*** Error code 1
Stop.
make[3]: stopped in /usr/src/12.1/lib/clang
*** Error code 1
Stop.
make[2]: stopped in /usr/src/12.1
*** Error code 1
Stop.
make[1]: stopped in /usr/src/12.1
*** Error code 1
Stop.
make: stopped in /usr/src/12.1
---C U T ---
Best
Henry
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HOWTO donate CPU to the fight against the Corona-virus
Quoting Matthias Apitz (from Fri, 20 Mar 2020 08:01:12 +0100): El día jueves, marzo 19, 2020 a las 08:57:45a. m. +0100, Alexander Leidinger escribió: Hi, if someone wants to donate some FreeBSD based CPU resources to the fight against the Corona-virus, here is a quick HOWTO in terms of installing the Folding@Home client on FreeBSD: https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with-freebsd-foldinghome/ I tested this on a recent -current. Alexander, As far as I understand, the binary(!) tool pulls tasks from the net and communicates the results back over net, correct? What about the security aspect of this? This is correct. And a malicious person may distribute malware to you. If e.g. the group behind emotet would be able to infiltrate the servers of the project and inject their malicious payload somehow, it would be a big disaster (as there are even science organisations / universities / ... participating as far as I understand it). Personally I have this binary running on FreeBSD in a jail, but also on a Windows laptop. This is something were everyone needs to do their risk-management on their own. Currently with the Corona-virus I consider for myself the benefit of participating with a lot resources more important than the risk (on the laptop). When the current situation normalizes, I probably stop the client on the laptop, but will let it run in the jail (with less resources donated to it). YMMV. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpwioTYlKMnF.pgp Description: Digitale PGP-Signatur
Re: HOWTO donate CPU to the fight against the Corona-virus
Quoting "Kevin P. Neal" (from Thu, 19 Mar 2020 20:51:28 -0400): On Fri, Mar 20, 2020 at 12:13:37AM +0100, Mateusz Piotrowski wrote: The patch is now on Phabricator open to reviews & ready to be tested: https://reviews.freebsd.org/D24127 No source is available? They must not be serious, then. It's answered on the website. As they have stats for each user, cheaters may modify the code to get better stats while the result may then not be useable for the project (false positives could be resolved by a verification step, but false negatives not, and giving the same WU to multiple people to have a statistical confidence would slow down the progress a lot). A lot of the code is actually open source, but not all. They refer to projects which they use. Also think about the fact that this project comes from a medical background where you have a lot of closedness, intelectual property, regulation and liabilities. Personally I consider the fact that this project (started in the year 2000) is producing open source code at all already as a start of an evolition in the medical business (yes, there are other more open source projects in this field too). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpp1ax0q4FB5.pgp Description: Digitale PGP-Signatur
Re: HOWTO donate CPU to the fight against the Corona-virus
El día jueves, marzo 19, 2020 a las 08:57:45a. m. +0100, Alexander Leidinger escribió: > Hi, > > if someone wants to donate some FreeBSD based CPU resources to the > fight against the Corona-virus, here is a quick HOWTO in terms of > installing the Folding@Home client on FreeBSD: > > https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with-freebsd-foldinghome/ > > I tested this on a recent -current. Alexander, As far as I understand, the binary(!) tool pulls tasks from the net and communicates the results back over net, correct? What about the security aspect of this? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
