Re: Import of DragonFly Mail Agent
On 24.02.14 19:49, Mark Felder wrote: We can strip pieces of FreeBSD off and end up with an kernel. Or we could keep the system very much usable out of the box. Imagine a world where everything in FreeBSD is a package and we have a working PROVIDES framework. Upon installation you can choose the software that provides the MTA role. Same for DNS, NTP, database, webserver... That would be a great accomplishment along with a framework to create a master install image utilizing the options/packages you desire. I think this type of thing is definitely plausible if we keep moving forward. My personal opinion remains that complex software is better served/secured/maintained when it is handled in ports not in base. While I agree with all you say, it is worth noting that bind/sendmail/ntp have been very compatible with FreeBSD precisely because of their integration with the base system. What we risk with everything is a port concept is that we live in a world that there is a lot of software to chose from, but from time to time, the software happens to be incompatible with FreeBSD in one way, or another. Another risk is the confusion of too much choice. There is a fine balance to be found here. Daniel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of DragonFly Mail Agent
On 25 Feb 2014, at 08:09, Daniel Kalchev dan...@digsys.bg wrote: What we risk with everything is a port concept is that we live in a world that there is a lot of software to chose from, but from time to time, the software happens to be incompatible with FreeBSD in one way, or another. Another risk is the confusion of too much choice. I think that, over the next few years, the hard line between base system and ports is going to become a little bit more of a gradient. I would like us to end up with multiple tiers: 1) These packages are required for absolutely everything, don't even think about not installing them even in a minimal service jail. 2) These packages are required for a useable system. They're in the default install, but if you're creating a jail you might not want them (e.g. nvi, some of the management tools) because you'll be doing all of your configuration with the version in the base system. 3) These packages are maintained by the FreeBSD project and are expected to integrate well with the base system. Some of them are part of various recommended installs for different configurations (e.g. graphical workstation, web server, whatever), but you can have a working minimal install without any of them. They will be supported for the duration of the release, including prompt security updates. 4) These packages are third-party programs that have been tested with FreeBSD and packaged by members of the FreeBSD project, but are developed independently. They will be supported on a best-effort basis for the release, but you may find that upgrading to a new version requires a newer release at some point. 5) These packages are provided by third parties, on third-party repositories, with no involvement from anyone in the FreeBSD project. Currently, the base system overlaps tiers 1-3, and ports overlaps tiers 3-4. Tier 3 is the source of most bikesheds, because there are lots of things that would benefit from some FreeBSD-specific integration work, are essential to a large section of the FreeBSD userbase, but are completely irrelevant to another large section. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of DragonFly Mail Agent
On Mon, Feb 24, 2014 at 11:50:10PM +0100, Jilles Tjoelker wrote: On Mon, Feb 24, 2014 at 07:01:54PM +0400, Slawa Olhovchenkov wrote: On Mon, Feb 24, 2014 at 03:30:14PM +0100, Baptiste Daroussin wrote: On Mon, Feb 24, 2014 at 06:17:37PM +0400, Slawa Olhovchenkov wrote: On Sun, Feb 23, 2014 at 10:11:56PM +0100, Baptiste Daroussin wrote: As some of you may have noticed, I have imorted a couple of days ago dma (DragonFly Mail Agent) in base. I have been asked to explain my motivation so here they are. What's about suid, security separations etc? What do you mean? dma is changing user as soon as possible, dma will be capsicumized, what else do you want as informations? sendmail (in the past) have same behaviour (run as root and chage user). This is some security risk. For many scenario change user is not simple (for example -- send file from local user A to local user B, file with permsion 0400). sendmail will be forced to change behaviour -- mailnull suid program for place mail into queue and root daemon for deliver to user. This is more complex. Can be dma avoid this way? I'm a bit disappointed that dma uses setuid/setgid binaries, although it is not a regression because sendmail also uses this Unix misfeature. To avoid the large attack surface of set*id binaries (the untrusted user can set many process parameters, pass strange file descriptors, send signals, etc), I think it is better to implement trusted submission differently. A privileged daemon (not necessarily running as root) can listen on a Unix domain socket and use getpeereid(3) to verify the credentials of the client. As long as $anyone locally can send emails, what is the point of checking getpeereid(3)? regards, Bapt pgpqGMk_yxaRE.pgp Description: PGP signature
RE: Build failed in Jenkins: FreeBSD_HEAD #176
Hi, The build failure should be fixed yesterday: http://svnweb.freebsd.org/base?view=revisionrevision=262454 I forgot to test using clang compiler before committing. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build is back to normal : FreeBSD_HEAD #177
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/177/changes ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of DragonFly Mail Agent
from Julio Merino: On Mon, Feb 24, 2014 at 6:47 AM, Thomas Mueller mueller6...@bellsouth.netwrote: To Julio Merino: How long did NetBSD include both sendmail and postfix in base? What NetBSD releases? What was the first release that included both sendmail and postfix, and the first release where sendmail was dropped? As far as I can tell, postfix was added in NetBSD 1.5 (Dec 6, 2000), made the default in NetBSD 2.0 (Dec 9, 2004) and sendmail was removed in NetBSD 4.0 (Dec 19, 2007). That's a 7-year long transitional period. I haven't been able to find the discussion for the removal of sendmail unfortunately. Oldest NetBSD I still have installed is 4.0.1 i386. I had no 64-bit computer at that time. I don't know if NetBSD 4.0.1 i386 would connect on my current Ethernet Realtek 8111E. Postfix seems somewhat more user-friendly than sendmail, though I still got error sending mail, apparently because user name didn't match computer hostname. There needs to be better documentation of sendmail if it is to be kept, and the option to compile sendmail for fuller function including SSL and TLS. I hope dma will be well documented as to setup if it is imported into FreeBSD. Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Re: Import of DragonFly Mail Agent
Am 24.02.2014 15:56, schrieb Daniel Kalchev: On 24.02.14 13:47, Thomas Mueller wrote: I don't believe BSD users use base system of itself to send and receive email. They use ports (FreeBSD) or equivalent in other BSDs. One of the beauties of the BSD 'base system' is that upon installation you have an usable workstation/server environment that can be immediately used for most Internet-related tasks -- and this most certainly includes SMTP. Or NTP. Or... used to include DNS. We can strip pieces of FreeBSD off and end up with an kernel. Or we could keep the system very much usable out of the box. +1! and I want nsupdate back in base. Matthias -- Matthias Meyser| XeNET GmbH Tel.: +49-5323-9489050| 38678 Clausthal-Zellerfeld, Marktstrasse 40 Fax: +49-5323-94014 | Registergericht: Amtsgericht Braunschweig HRB 110823 Email: mey...@xenet.de | Geschaeftsfuehrer: Matthias Meyser ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of DragonFly Mail Agent
On Mon, 24 Feb 2014 19:24:02 -0500 (EST) Benjamin Kaduk wrote: On Mon, 24 Feb 2014, Lyndon Nerenberg wrote: What would really help is if the ports fetch-recursive-list target could extend to reliably include the distfiles for the runtime dependencies as well. But I'm not even sure that's possible. We tried a few different things, but in the end we had to brute force it by running 'make fetch' in every one of the ports directories in order to get all the distfiles onto an external system, which we then rsynced to a USB drive, marched inside, and rsynced to the fileserver. Not pretty ... but with all the distfiles at hand we knew the inside ports builds wouldn't fail due to missing dependencies. I'm rather confused by why it isn't working for you. http://svnweb.freebsd.org/ports/head/Mk/bsd.port.mk?revision=345884view=markup#l5187 is quite clearly looking in ALL-DEPENDS-LIST, which includes runtime dependencies. The only thing I can think of is that non-default configurations are in play, so that 'make config make config-recursive' should be (re-)run until it does not prompt, and only then fetch-recursive-list be used. One oddity is that fetch-recursive-list generates a script that downloads all the files into the current directory. It doesn't take account of the fact that some ports look for their files are in a sub-directory. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Fw: pkgng and pkgdb
hi, all: i used to use pkgdb -Ff along with old wonderful pkg_whatever to keep my freebsd station healthy. but i was told the new era of pkg is coming and so i made switch to pkgng. the question is: what is the equivalent of pkgdb -Ff? for pkg? for pkgdb -Ff, i am especially fond of its ability to fix those duplicated registrations. is the pkg check -dB -av the same as that pkgdb -Ff? thanks. ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of DragonFly Mail Agent
Thomas Mueller wrote There needs to be better documentation of sendmail if it is to be kept, and the option to compile sendmail for fuller function including SSL and TLS Apparently sendmail is compiled with ssl/tls support in FreeBSD, standard. This is what i get by sending mail from my freshly installed FreeBSD-10 machine niobe to the lab's mailhub (running postfix) Received: from niobe.lpthe.jussieu.fr (niobe.lpthe.jussieu.fr [134.157.10.41]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN niobe.lpthe.jussieu.fr, Issuer niobe.lpthe.jussieu.fr (not verified)) by parthe.lpthe.jussieu.fr (Postfix) with ESMTPS id 18143E4DE9 and indeed i see niobe% telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 niobe.lpthe.jussieu.fr ESMTP Sendmail 8.14.7/8.14.7; Tue, 25 Feb 2014 16:41:11 +0100 (CET) ehlo lpthe.jussieu.fr 250-niobe.lpthe.jussieu.fr Hello localhost [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-STARTTLS 250-DELIVERBY 250 HELP There is a directory /etc/mail/certs with various certs, presumably self signed, which has been created at installation. -- Michel Talon ta...@lpthe.jussieu.fr smime.p7s Description: S/MIME cryptographic signature
Re: Import of DragonFly Mail Agent
On 2/24/2014 6:56 AM, Daniel Kalchev wrote: One of the many problems with removing functionality is very well illustrated by what happens now, when you upgrade an pre-10 system running nameserver: you end up without it and eventually without your nameserver database as well. Imagine, one day a user updates their 10-stable to 11-stable only to find out mail is no more. I understand your point, but that would mean they didn't read the release notes or UPGRADING prior to doing so. That is not a problem we can fix in software. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of DragonFly Mail Agent
On Tue, Feb 25, 2014 at 11:30:56AM +0100, Baptiste Daroussin wrote: On Mon, Feb 24, 2014 at 11:50:10PM +0100, Jilles Tjoelker wrote: On Mon, Feb 24, 2014 at 07:01:54PM +0400, Slawa Olhovchenkov wrote: On Mon, Feb 24, 2014 at 03:30:14PM +0100, Baptiste Daroussin wrote: On Mon, Feb 24, 2014 at 06:17:37PM +0400, Slawa Olhovchenkov wrote: On Sun, Feb 23, 2014 at 10:11:56PM +0100, Baptiste Daroussin wrote: As some of you may have noticed, I have imorted a couple of days ago dma (DragonFly Mail Agent) in base. I have been asked to explain my motivation so here they are. What's about suid, security separations etc? What do you mean? dma is changing user as soon as possible, dma will be capsicumized, what else do you want as informations? sendmail (in the past) have same behaviour (run as root and chage user). This is some security risk. For many scenario change user is not simple (for example -- send file from local user A to local user B, file with permsion 0400). sendmail will be forced to change behaviour -- mailnull suid program for place mail into queue and root daemon for deliver to user. This is more complex. Can be dma avoid this way? I'm a bit disappointed that dma uses setuid/setgid binaries, although it is not a regression because sendmail also uses this Unix misfeature. To avoid the large attack surface of set*id binaries (the untrusted user can set many process parameters, pass strange file descriptors, send signals, etc), I think it is better to implement trusted submission differently. A privileged daemon (not necessarily running as root) can listen on a Unix domain socket and use getpeereid(3) to verify the credentials of the client. As long as $anyone locally can send emails, what is the point of checking getpeereid(3)? Checking getpeereid(3) is useful to provide a more reliable indication of which user account originated the message, for example on web hosting servers. For this, it is best if the smarthost authenticates dma so a user cannot bypass dma. -- Jilles Tjoelker ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of DragonFly Mail Agent
On 2/24/2014 6:56 AM, Daniel Kalchev wrote: On 24.02.14 13:47, Thomas Mueller wrote: I don't believe BSD users use base system of itself to send and receive email. They use ports (FreeBSD) or equivalent in other BSDs. One of the beauties of the BSD 'base system' is that upon installation you have an usable workstation/server environment that can be immediately used for most Internet-related tasks -- and this most certainly includes SMTP. Or NTP. Or... used to include DNS. Your beautiful base system ready for most Internet-related tasks does not have a: - GUI - browser - media player - email client - IRC client - office suite I'm wondering what you consider most internet tasks. If I want a basic internet desktop, I need to install a couple hundred ports to achieve that. If I want a server that follows best practices, I have to install openssl from ports, which means I *can't* use the in-base sendmail even if I wanted to. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of DragonFly Mail Agent
On Tue, Feb 25, 2014, at 10:07, Michel Talon wrote: Thomas Mueller wrote There needs to be better documentation of sendmail if it is to be kept, and the option to compile sendmail for fuller function including SSL and TLS Apparently sendmail is compiled with ssl/tls support in FreeBSD, standard. This is what i get by sending mail from my freshly installed FreeBSD-10 machine niobe to the lab's mailhub (running postfix) Yes, however the Sendmail in base on FreeBSD 8 and 9 is compiled against OpenSSL 1.0 which means it's missing support for TLS 1.2, SNI, and other modern best practice features. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of DragonFly Mail Agent
On 2014-02-25 16:31, RW wrote:
On Mon, 24 Feb 2014 19:24:02 -0500 (EST)
Benjamin Kaduk wrote:
On Mon, 24 Feb 2014, Lyndon Nerenberg wrote:
What would really help is if the ports fetch-recursive-list target
could extend to reliably include the distfiles for the runtime
dependencies as well. But I'm not even sure that's possible. We
tried a few different things, but in the end we had to brute force
it by running 'make fetch' in every one of the ports directories in
order to get all the distfiles onto an external system, which we
then rsynced to a USB drive, marched inside, and rsynced to the
fileserver. Not pretty ... but with all the distfiles at hand we
knew the inside ports builds wouldn't fail due to missing
dependencies.
I'm rather confused by why it isn't working for you.
http://svnweb.freebsd.org/ports/head/Mk/bsd.port.mk?revision=345884view=markup#l5187
is quite clearly looking in ALL-DEPENDS-LIST, which includes runtime
dependencies. The only thing I can think of is that non-default
configurations are in play, so that 'make config make
config-recursive' should be (re-)run until it does not prompt, and
only then fetch-recursive-list be used.
One oddity is that fetch-recursive-list generates a script that
downloads all the files into the current directory. It doesn't take
account of the fact that some ports look for their files are in a
sub-directory.
Some snippets from a script that is used to manage updates,
tinderboxe builds, poudriere builds ...
I collected all ports that are required to build my environments
from tinderbox (./tc listPorts) and others in a plain txt file.
in the format $cat/$port.
...
databases/php5-pdo
databases/php5-pdo_mysql
databases/php5-pdo_pgsql
databases/php5-pdo_sqlite
databases/php5-pgsql
databases/postgresql92-client
databases/postgresql92-server
databases/postgresql93-client
databases/postgresql93-server
databases/py-gdbm
databases/rrdtool
databases/rrdtool12
databases/sqlite3
...
Reading this file in a loop with a command like the following
will fetch all required distfiles.
while read port; do
env -i WRKDIRPREFIX=/tmp/rbtrash PKG_DBDIR=/var/empty \
LOCALBASE=/var/empty make fetch -DBATCH -C /usr/ports/${port} \
-DCLEAN_FETCH_ENV -DDISABLE_CONFLICTS
done $path/to/interesting/port/list
A list of all required dependency's can be generated with this command
(for a single port or in the sample loop (s/fetch/all-depends-list/)
$ make all-depends-list /usr/ports/$cat/${port}
Ports tree updates (portsnap or svn up) are written to a log which is used
to generate a list of ports where the distfile is maybe missing, the loop
reads then only this new list.
The directory with all distfiles is distributed via httpd to all build
systems (make.conf: MASTER_SITE_OVERRIDE=$central/fetch/server/url )
Hope this gives some ideas ;)
--
olli
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
FREEBSD 10 - Error on Fetch (portsnap or freebsd-update)
Hi. i`m trying to update my FreeBSD 10 Release to Stable, but i`m not getting to fetch on portsnap and freebsd-update look: # portsnap --debug fetch Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. Fetching snapshot tag from your-org.portsnap.freebsd.org... snapshot.ssl0% of 256 B0 Bps 02m00s fetch: transfer timed out fetch: snapshot.ssl appears to be truncated: 0/256 bytes Error reading input Data invalid snapshot tag. Fetching snapshot tag from isc.portsnap.freebsd.org... snapshot.ssl 100% of 256 B 690 kBps 00m00s done. Fetching snapshot metadata... 009cb897995b7e322bb3b0495ac9a1a01c1ba82280c687 0% of 604 B0 Bps 02m00s fetch: transfer timed out fetch: 009cb897995b7e322bb3b0495ac9a1a01c1ba82280c687b30f84f782f280dc7b appears to be truncated: 0/604 bytes Exit 1 -- Att. Alisson F. Gonçalves Consultoria em BGP/FreeBSD/Redes - Grandes realizações não são feitas por impulso, mas por uma soma de pequenas realizações. (Vincent Van Gogh) E-mail: alissongoncal...@bsd.com.br Celular/Whatsapp: (67) 9694-3243 Skype: alissonx2 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of DragonFly Mail Agent
Bryan Drewery wrote this message on Mon, Feb 24, 2014 at 09:40 -0600: The RC script also leads to much confusion in this configuration: # service sendmail stop Stopping sendmail. Waiting for PIDS: 80956. sendmail_submit not running? (check /var/run/sendmail.pid). Stopping sendmail_clientmqueue. Waiting for PIDS: 81322. It wasn't running? Was it broken? Is that why I couldn't send mail? # service sendmail start Cannot 'start' sendmail. Set sendmail_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'. Oh, it didn't start? # ps uaxw|grep sendmail root 64518 0.0 0.1 6020 2980 ?? Ss 10:19AM 0:00.00 sendmail: accepting connections (sendmail) smmsp 64726 0.0 0.1 6020 2924 ?? Ss 10:19AM 0:00.00 sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail) Oh. Can I restart? # service sendmail restart Cannot 'restart' sendmail. Set sendmail_enable to YES in /etc/rc.conf or use 'onerestart' instead of 'restart'. Stopping sendmail_submit. Oh it looks dead again. # ps uaxw|grep sendmail smmsp 64726 0.0 0.0 6020 0 ?? IWs - 0:00.00 sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail) root 88210 0.0 0.1 6020 3008 ?? Ss 10:20AM 0:00.00 sendmail: accepting connections (sendmail) root 93369 0.0 0.1 3464 1296 18 S+ 10:20AM 0:00.00 grep sendmail Nope. RC script bugs aside, how about modifying the actual configuration? The problem with the above is that the people who did the work did enough for it to work in their configuration and dropped it in.. Having recently fixed some of this, it's clear that they didn't bother to test starting/stopping parts of sendmail and more complicated configurations... This is standard stuff that needs to be maintained... and I don't belive dma will magicly fix stuff like the above... It just means someone will rewrite it with a new set of bugs... -- 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
