Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-15:08.sendmail
On Thu, Jun 18, 2015 at 08:41:51AM -0700, Gregory Shapiro wrote: > > I never changed or generated anything in the mail configuration > > on these servers, they use the default mc/cf files: > > > > $ grep DHParam /etc/mail/sendmail.cf > > # DHParameters (only required if DSA/DH is used) > > O DHParameters=/etc/mail/certs/dh.param > > > > $ ls -l /etc/mail/certs > > total 12 > > lrwxr-xr-x 1 root wheel10 31 Aug 2014 4bc0b037.0 -> cacert.pem > > -rw-r--r-- 1 root wheel 1326 31 Aug 2014 cacert.pem > > -rw-r--r-- 1 root wheel 1375 31 Aug 2014 host.cert > > -rw--- 1 root wheel 1704 31 Aug 2014 host.key > > I found what is breaking it. This commit made locally to FreeBSD: > > Revision 256982 > Modified Wed Oct 23 16:55:20 2013 UTC (19 months, 3 weeks ago) by jmg > MFC r256773: > Enable the automatic creation of a certificate (if one does not exists) > and enable the usage by sendmail if sendmail is enabled. > > sets DHParameters to that file but nothing else generates that file. > We'll have to rev the Errata (and patch) to create that file. In the mean > time, generating the file will fix the problem: > > openssl dhparam -out /etc/mail/certs/dh.param 2048 > > I'll probably fix this by changing /etc/rc.d/sendmail to do the above. > > I'll also look into the sendmail source behavior when the file doesn't > exist (it should revert to it's defaults). Thanks for the investigation and explanation. I have now generated dh.param in both servers and rebooted, and the problem is gone. Thanks! Peter Olsson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-15:08.sendmail
On Thu, Jun 18, 2015 at 08:10:33AM -0700, Gregory Shapiro wrote: > > > Did you (re)generate your dh.params file as noted in the Workaround > > > section? > > > > No, because of this text under Solution: > > " > > A change to the raise the default for sendmail client connections to > > 1024-bit DH parameters has been committed. > > " > > > > As I understand it this would remove the need for generating > > the dh.params file? > > You do not need to regenerate dh.params with the patch unless you have > specifically set DHParameters in /etc/mail/sendmail.cf to a lower > strength. What is the output of: > > grep DHParam /etc/mail/sendmail.cf > > If it is set to a string beginning with '5' or a filename and that > file was generated using 512-bit strength, then remove that setting. I never changed or generated anything in the mail configuration on these servers, they use the default mc/cf files: $ grep DHParam /etc/mail/sendmail.cf # DHParameters (only required if DSA/DH is used) O DHParameters=/etc/mail/certs/dh.param $ ls -l /etc/mail/certs total 12 lrwxr-xr-x 1 root wheel10 31 Aug 2014 4bc0b037.0 -> cacert.pem -rw-r--r-- 1 root wheel 1326 31 Aug 2014 cacert.pem -rw-r--r-- 1 root wheel 1375 31 Aug 2014 host.cert -rw--- 1 root wheel 1704 31 Aug 2014 host.key Peter Olsson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-15:08.sendmail
On Thu, Jun 18, 2015 at 04:54:31AM -0800, Royce Williams wrote: > On Thu, Jun 18, 2015 at 3:21 AM, Peter Olsson < > list-freebsd-annou...@jyborn.se> wrote: > > > On Thu, Jun 18, 2015 at 05:53:20AM +, FreeBSD Errata Notices wrote: > > > Corrected: 2015-06-17 02:39:10 UTC (stable/10, 10.1-STABLE) > > > 2015-06-18 05:36:45 UTC (releng/10.1, 10.1-RELEASE-p13) > > > > > > V. Solution > > ... > > > # freebsd-update fetch > > > # freebsd-update install > > > > This does not seem to solve the problem. > > > > I upgraded two of my 10.1-RELEASE-pX servers to > > 10.1-RELEASE-p12 a couple of days ago, after which all > > outgoing mail, both for local destinations and for > > destinations outside the servers, end up stuck in > > /var/spool/clientmqueue with this in maillog: > > > > And I still have the same problem after upgrading to > > 10.1-RELEASE-p13 and rebooting. > > > > Both servers use base sendmail, and I have done nothing > > (except adding aliases) with the sendmail configuration > > in them. Not even created `hostname` mc/cf files, so they > > are using the default cf files. > > > > Did you (re)generate your dh.params file as noted in the Workaround section? No, because of this text under Solution: " A change to the raise the default for sendmail client connections to 1024-bit DH parameters has been committed. " As I understand it this would remove the need for generating the dh.params file? Hence my thinking that the patch is maybe not 100% correct. Mail from these two servers are not critical for me, so I will wait and see if there is another patch or if in fact I have to generate the dh.params file. > On my systems, I had to do this to support the actual patch (not to perform > the workaround). > > You might have to restart sendmail as well, but I have not tested this. I rebooted the server, didn't help. Peter Olsson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-15:08.sendmail
On Thu, Jun 18, 2015 at 05:53:20AM +, FreeBSD Errata Notices wrote: > Corrected: 2015-06-17 02:39:10 UTC (stable/10, 10.1-STABLE) > 2015-06-18 05:36:45 UTC (releng/10.1, 10.1-RELEASE-p13) > > V. Solution ... > # freebsd-update fetch > # freebsd-update install This does not seem to solve the problem. I upgraded two of my 10.1-RELEASE-pX servers to 10.1-RELEASE-p12 a couple of days ago, after which all outgoing mail, both for local destinations and for destinations outside the servers, end up stuck in /var/spool/clientmqueue with this in maillog: sendmail[1045]: t5IBAMAB001045: from=pol, size=23, class=0, nrcpts=1, msgid=<201506181110.t5IBAMAB001045@xxx>, relay=root@localhost sendmail[1045]: STARTTLS=client, error: connect failed=-1, reason=dh key too small, SSL_error=1, errno=0, retry=-1 sm-mta[1046]: STARTTLS=server, error: accept failed=0, reason=sslv3 alert handshake failure, SSL_error=1, errno=0, retry=-1, relay=localhost [127.0.0.1] sendmail[1045]: ruleset=tls_server, arg1=SOFTWARE, relay=[127.0.0.1], reject=403 4.7.0 TLS handshake. sm-mta[1046]: t5IBAMPQ001046: localhost [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to Daemon0 sendmail[1045]: t5IBAMAB001045: to=www, ctladdr=pol (xxx/xxx), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30023, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: 403 4.7.0 TLS handshake. And I still have the same problem after upgrading to 10.1-RELEASE-p13 and rebooting. Both servers use base sendmail, and I have done nothing (except adding aliases) with the sendmail configuration in them. Not even created `hostname` mc/cf files, so they are using the default cf files. -- Peter Olsson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: There has to be a better way of merging /etc during a major freebsd-update
On Tue, Mar 10, 2015 at 12:55:09PM -0500, Adam Vande More wrote: > On Tue, Mar 10, 2015 at 12:45 PM, Peter Olsson < > list-freebsd-sta...@jyborn.se> wrote: > > > On Tue, Mar 10, 2015 at 10:17:18AM -0500, Adam Vande More wrote: > > > On Tue, Mar 10, 2015 at 7:05 AM, Peter Olsson < > > list-freebsd-sta...@jyborn.se > > > > wrote: > > > > > > > This flag to mergemaster saved a lot of work when I did > > > > upgrades the old way, with cvsup and the make steps and > > > > then mergemaster: > > > > > > > > > > https://svnweb.freebsd.org/base?view=revision&revision=221780 > > > > > > I'd venture to guess the script will work fine on older installs, but > > > testing should be done first. > > > > > > -- > > > Adam > > > > This seems like an excellent addition fo freebsd-update, > > how come it isn't added? > > > > It is added, no flag needed. You are running a version of freebsd-update > which didn't have the feature(8.4). > > -- > Adam Ok, I see, thanks! Peter Olsson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: There has to be a better way of merging /etc during a major freebsd-update
On Tue, Mar 10, 2015 at 10:06:37PM +, Ben Morrow wrote: > Quoth Peter Olsson : > > > > (But I will try running freebsd-update without merging /etc, > > and use mergemaster -F instead. Should solve my problem.) > > I'm fairly sure this won't do what you want, and in fact won't work at > all, unless your /etc is identical to the stock /etc installed from the > ISO. (Which it isn't, of course.) > > installworld specifically avoids installing the files in /etc; then, > when you run mergemaster, it installs the new versions of those files > into a temporary directory and merges them with the existing /etc. > > freebsd-update works a little differently: because it doesn't have a > source tree available, it has to fetch the stock versions of the files > in /etc for the release you're upgrading from, so that it can patch them > to the new release and then merge the changes into your current /etc. If > you tell freebsd-update to install /etc without merging it will blindly > update files you haven't changed (which is probably what you want) but > (I think) will fail to update the files that you have changed, because > it uses binary patches which won't apply to your modified versions. > > If you want a rather hackish solution, you could try something like > this: > > - Rename /etc to /oldetc. > - Find yourself a copy of the stock /etc for the version you are > upgrading from. (tar -xpf base.txz --include /etc) > - Run freebsd-update with /etc removed from the merge list. This > will (should?) give you a stock /etc for the version you are > upgrading to. > - Rename /etc -> /tmp/etc, /oldetc -> /etc and run mergemaster with > -t /tmp. > > Obviously I would script this if I was doing more than one or two > machines > > Ben I'm not really clear on what will happen if I remove /etc/ from MergeChanges in freebsd-update.conf. Will my /etc then be ignored by freebsd-update, or will my /etc be completely overwritten by freebsd-update? Anyway, your hack could be useful to me. There are no more than about ten files I usually change in /etc, so saving the current /etc, installing a stock /etc, running freebsd-update and then running diff -r to sort out my changes could work. But I'm a little worried about removing my /etc changes from a running server. Thanks! Peter Olsson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: There has to be a better way of merging /etc during a major freebsd-update
On Tue, Mar 10, 2015 at 12:01:54PM -0700, Chris H wrote: > On Tue, 10 Mar 2015 10:17:18 -0500 Adam Vande More > wrote > > > On Tue, Mar 10, 2015 at 7:05 AM, Peter Olsson > > wrote: > > > > > This flag to mergemaster saved a lot of work when I did > > > upgrades the old way, with cvsup and the make steps and > > > then mergemaster: > > > > > > > https://svnweb.freebsd.org/base?view=revision&revision=221780 > > > > I'd venture to guess the script will work fine on older installs, but > > testing should be done first. > Isn't that pretty much what the -F flag, I mentioned does? > "-FIf the files differ only by VCS Id ($FreeBSD) install the >new file." > In all honesty, I too got stuck answering "y" ~100 times, way > back when. And decided I needed to either find a better way, > or see if the mergemaster(8) had any secrets I wasn't > aware of. ;-) I think you are mixing up mergemaster with merge. Freebsd-update uses merge, not mergemaster. (But I will try running freebsd-update without merging /etc, and use mergemaster -F instead. Should solve my problem.) Peter Olsson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: There has to be a better way of merging /etc during a major freebsd-update
On Tue, Mar 10, 2015 at 10:17:18AM -0500, Adam Vande More wrote: > On Tue, Mar 10, 2015 at 7:05 AM, Peter Olsson > wrote: > > > This flag to mergemaster saved a lot of work when I did > > upgrades the old way, with cvsup and the make steps and > > then mergemaster: > > > > https://svnweb.freebsd.org/base?view=revision&revision=221780 > > I'd venture to guess the script will work fine on older installs, but > testing should be done first. > > -- > Adam This seems like an excellent addition fo freebsd-update, how come it isn't added? Possibly as a flag, so the default operation isn't changed. Peter Olsson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: There has to be a better way of merging /etc during a major freebsd-update
On Tue, Mar 10, 2015 at 06:58:07AM -0700, Chris H wrote: > On Tue, 10 Mar 2015 13:05:40 +0100 Peter Olsson > > wrote > > > This flag to mergemaster saved a lot of work when I did > > upgrades the old way, with cvsup and the make steps and > > then mergemaster: > > " > > # Install the new file if it differs only by VCS Id ($FreeBSD) > > FREEBSD_ID=yes > > " > > Is there some equivalent to this flag in freebsd-update/merge? > Hello, Peter. > This has probably been answered by now. But just in case. > I believe what you're looking for is: > mergemaster -vF Yes, that would probably solve my problem. Can I just change this line in /etc/freebsd-update.conf: MergeChanges /etc/ /var/named/etc/ /boot/device.hints to this: MergeChanges /var/named/etc/ /boot/device.hints And run mergemaster after the first freebsd-update install, before I reboot? Thanks! Peter Olsson > This is my [chosen] default. I also find it helpful, > as a "safety net" to > cp _Rp /etc /eetc > > prior to the mergemaster(8) step. > > On a related note. I'm not very fond of mergemaster. As > a result, I recently took on maintaining > sysutils/etcmerge. sysutils/etcupdate, is also a > [mergemaster] related port. > > Hope this helps. > > --Chris > > > > I just did my first major upgrade (8.4-RELEASE-p24 -> > > 9.3-RELEASE-p10) with freebsd-update. It took more than > > an hour of manual keyboard activity, most of which could > > probably be done automatically. (And here I thought that > > computers were supposed to free us from tedious routine > > work...) > > > > First robotically pressing dd..j.ZZ in a lot of files. > > Occasionally combined with /<<< to find more places that > > needed changing in files that didn't fit in the screen. > > Eg sendmail.cf. > > > > Of all these files that needed manual editing I had made > > my own changes in only one file (/etc/hosts), the rest of > > them just had this kind of change: > > > > The following file could not be merged automatically: /etc/rc.d/nisdomain > > Press Enter to edit this file in vi and resolve the conflicts > > manually... > > > > <<<<<<< current version > > # $FreeBSD: src/etc/rc.d/nisdomain,v 1.5.2.2 2013/03/28 13:02:44 svnexp Exp > > $ > > === > > # $FreeBSD: releng/9.3/etc/rc.d/nisdomain 193197 2009-06-01 04:55:13Z dougb > > $ > > >>>>>>> 9.3-RELEASE > > > > And then, after all these edits, I had to wade through entering > > y to "Does this look reasonable (y/n)?" for all these files! > > This is of course a necessary step to avoid being bitten by > > any <<< === >>> lines left behind by mistake (easy to do when > > you lose your concentration after more than a hundred files), > > but most of this step could be entirely avoided by automatically > > accepting the ID changes. > > (I amused myself by counting all files during this stage. > > I had to answer y to about 320 files, most of which only > > had changes in the ID.) > > > > This was my first upgrade from 8.4 to 9.3. I have 30 more to go > > before the 8.4 EoL this summer. I see 30 completely unnecessarily > > wasted hours in my future... > > And think of the combined lost man hours worldwide in these upgrades! > > Merge seems to be a really stupid choice for major upgrades. > > (Unless of course there is some flag to freebsd-update which makes > > this kind of change automatically accepted. But I see no such flag > > in man freebsd-update in 8.4, 9.3 or 10.1.) > > > > And yes, I could maybe copy most of /etc from the first > > upgraded server to the rest of them before upgrading, but > > that seems error-prone and not really a good solution for > > every FreeBSD user. > > > > -- > > Peter Olsson > > ___ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
There has to be a better way of merging /etc during a major freebsd-update
This flag to mergemaster saved a lot of work when I did upgrades the old way, with cvsup and the make steps and then mergemaster: " # Install the new file if it differs only by VCS Id ($FreeBSD) FREEBSD_ID=yes " Is there some equivalent to this flag in freebsd-update/merge? I just did my first major upgrade (8.4-RELEASE-p24 -> 9.3-RELEASE-p10) with freebsd-update. It took more than an hour of manual keyboard activity, most of which could probably be done automatically. (And here I thought that computers were supposed to free us from tedious routine work...) First robotically pressing dd..j.ZZ in a lot of files. Occasionally combined with /<<< to find more places that needed changing in files that didn't fit in the screen. Eg sendmail.cf. Of all these files that needed manual editing I had made my own changes in only one file (/etc/hosts), the rest of them just had this kind of change: The following file could not be merged automatically: /etc/rc.d/nisdomain Press Enter to edit this file in vi and resolve the conflicts manually... <<<<<<< current version # $FreeBSD: src/etc/rc.d/nisdomain,v 1.5.2.2 2013/03/28 13:02:44 svnexp Exp $ === # $FreeBSD: releng/9.3/etc/rc.d/nisdomain 193197 2009-06-01 04:55:13Z dougb $ >>>>>>> 9.3-RELEASE And then, after all these edits, I had to wade through entering y to "Does this look reasonable (y/n)?" for all these files! This is of course a necessary step to avoid being bitten by any <<< === >>> lines left behind by mistake (easy to do when you lose your concentration after more than a hundred files), but most of this step could be entirely avoided by automatically accepting the ID changes. (I amused myself by counting all files during this stage. I had to answer y to about 320 files, most of which only had changes in the ID.) This was my first upgrade from 8.4 to 9.3. I have 30 more to go before the 8.4 EoL this summer. I see 30 completely unnecessarily wasted hours in my future... And think of the combined lost man hours worldwide in these upgrades! Merge seems to be a really stupid choice for major upgrades. (Unless of course there is some flag to freebsd-update which makes this kind of change automatically accepted. But I see no such flag in man freebsd-update in 8.4, 9.3 or 10.1.) And yes, I could maybe copy most of /etc from the first upgraded server to the rest of them before upgrading, but that seems error-prone and not really a good solution for every FreeBSD user. -- Peter Olsson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Does quota still require a custom kernel in FreeBSD 9?
Just wondering if a custom kernel with options QUOTA is still needed in FreeBSD 9. I have no test server available right now to test this. According to the handbook it is needed, but I found in a post from 2011 that it would be entered into GENERIC, so the handbook statement might be old? My reason for asking is that I'm about to convert from source build to freebsd-update in all servers, so I would like to revert to GENERIC wherever possible. (If it is still needed, are there any plans for removing this need?) Thanks! -- Peter Olssonp...@leissner.se ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: How go back from X.Y-RELEASE-pZ to X.Y-RELEASE?
On Sat, Nov 24, 2012 at 09:17:18AM -0800, Jakub Lach wrote: > Is this what are you looking for? > > http://svnweb.freebsd.org/base/releng/8.3/UPDATING?view=log Yes, thanks! -- Peter Olsson > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/How-go-back-from-X-Y-RELEASE-pZ-to-X-Y-RELEASE-tp5763474p5763805.html > Sent from the freebsd-stable mailing list archive at Nabble.com. > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: How go back from X.Y-RELEASE-pZ to X.Y-RELEASE?
On Fri, Nov 23, 2012 at 01:25:06PM +0100, Bas Smeelen wrote: > On 11/23/2012 12:22 PM, Peter Olsson wrote: > > We are currently using cvs for both source and ports. > > I have begun changing to portsnap for ports, and I > > would also like to try changing at least some of our > > servers to freebsd-update. > > > > But all servers have been patched, using either RELENG_8_3 > > or RELENG_9_0 as cvs tag. I need to revert them to their > > respective RELEASE to be able to use freebsd-update. > > Complete reinstall from eg CD is not an option, and I don't > > want to upgrade to a newer RELEASE at the moment. > > > > Can I change the cvs tags to RELENG_8_3_0_RELEASE or > > RELENG_9_0_0_RELEASE, and then build/install world and > > kernel as usual? > > Or will that method cause problems for the system or the > > installed ports? > > > > Thanks! > > RELENG_9_0 and RELENG_8_3 are RELEASE branches including patches > (8.3-RELEASE-p4 for instance), so you should be able to use freebsd-update > ont them without changing anything. > If the servers are up to date then freebsd-update doesn't have to do > anything for them untill the next paches for them come around. I tried this in a lab server running 8.3-RELEASE-p4. The only complaint during freebsd-update fetch was this: The following files are affected by updates, but no changes have been downloaded because the files have been modified locally: /var/db/mergemaster.mtree But it wanted to update a lot more files than just the latest patches to p5. Mostly files in /rescue, but also files belonging to openssl, crypt and ipv6, ie previous patches that I already had installed. So it didn't recognize that I already had installed those patches. Anyway, I ran freebsd-update install, and it finished without complaints. Then I rebooted and the server seems fine. /usr/src/sys/conf/newvers.sh now has these lines: REVISION="8.3" BRANCH="RELEASE-p5" However, freebsd-update IDS reports more than 23000 non-matching files, so I will instead try using cvs tag RELENG_8_3_0_RELEASE and see how freebsd-update behaves after install of that kernel and world. The complaints about /var/db/mergemaster.mtree will probably continue, but I suppose I can install another lab server from 8.3 install media and copy that file from there? Another question: I like to read the file /usr/src/UPDATING before installing patches, but freebsd-update doesn't seem to bother with that file. What is the easiest way of accessing a current /usr/src/UPDATING for the RELENG branches, without using cvs or subversion? I thought it would be located at http://www.freebsd.org/cgi/cvsweb.cgi/src/?only_with_tag=RELENG_8_3 but there is no UPDATING in that list. Thanks! Peter Olsson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
How go back from X.Y-RELEASE-pZ to X.Y-RELEASE?
We are currently using cvs for both source and ports. I have begun changing to portsnap for ports, and I would also like to try changing at least some of our servers to freebsd-update. But all servers have been patched, using either RELENG_8_3 or RELENG_9_0 as cvs tag. I need to revert them to their respective RELEASE to be able to use freebsd-update. Complete reinstall from eg CD is not an option, and I don't want to upgrade to a newer RELEASE at the moment. Can I change the cvs tags to RELENG_8_3_0_RELEASE or RELENG_9_0_0_RELEASE, and then build/install world and kernel as usual? Or will that method cause problems for the system or the installed ports? Thanks! -- Peter Olssonp...@leissner.se ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Tuning needed for slow RDP FreeBSD 9 -> Win 2008 R2
On Mon, Feb 13, 2012 at 04:09:05PM +0100, Ivan Voras wrote: > On 13/02/2012 02:50, Peter Olsson wrote: > > Desktop: FreeBSD 9.0-RELEASE amd64, generic kernel, > > running Openbox. My WAN is about 1.2 Mbps, and I try > > to run RDP to windows servers beyond my WAN. > > > > RDP to a Windows Server 2003 SP2 is fast and works > > without problems. > > > > RDP to a Windows Server 2008 R2 is very slow, > > and sometimes just disconnects. > > > > I tried changing a couple of net.inet.tcp sysctl: > > > Nothing has helped, do you have any ideas what I > > should tune? > > It is highly unlikely that any network tuning will help here - this is > almost certainly an application-level problem. > > For what it's worth, I'm using rdesktop to a Win2k8 R2 server without > any lag other problems. I have a colleague who runs Crunchbang (ie Debian) desktop. He had exactly the same performance problem until he used these sysctl: net.core.rmem_max=1048576 net.core.rmem_default=1048576 net.core.wmem_max=1048576 net.core.wmem_default=1048576 net.ipv4.tcp_rmem=1048576 1048576 3444736 net.ipv4.tcp_wmem=1048576 1048576 3444736 I don't know where he got those values, or what they could be translated to in FreeBSD, but they did solve the problem for him. That's why I'm hoping to find a similar sysctl solution for FreeBSD. I did sysctl -a | grep mem and grep buf, but find nothing obvious, except the net.inet.tcp.recvbuf and sendbuf values I have already tried changing. Also, I run Win7 in Virtualbox in my desktop, and from that Win7 I don't have the performance problem towards that RDP server. -- Peter Olssonp...@leissner.se ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Tuning needed for slow RDP FreeBSD 9 -> Win 2008 R2
Desktop: FreeBSD 9.0-RELEASE amd64, generic kernel, running Openbox. My WAN is about 1.2 Mbps, and I try to run RDP to windows servers beyond my WAN. RDP to a Windows Server 2003 SP2 is fast and works without problems. RDP to a Windows Server 2008 R2 is very slow, and sometimes just disconnects. I tried changing a couple of net.inet.tcp sysctl: net.inet.tcp.recvbuf_max=10485760 net.inet.tcp.recvbuf_inc=65535 net.inet.tcp.sendbuf_max=10485760 net.inet.tcp.sendbuf_inc=65535 net.inet.tcp.recvbuf_auto=0 net.inet.tcp.sendbuf_auto=0 net.inet.tcp.sendspace=65536 net.inet.tcp.ecn.enable=1 net.inet.tcp.delayed_ack=0 net.inet.tcp.tso=0 net.inet.tcp.sack.enable=0 net.inet.tcp.path_mtu_discovery=0 Some in combination with others, and some by themselves. I also tried net.link.ifqmaxlen=1024 in /boot/loader.conf. Nothing has helped, do you have any ideas what I should tune? Thanks! -- Peter Olssonp...@leissner.se ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
How disable ntpd on IPv6 adresses?
Hello! I hope this is the right list for this question. In FreeBSD 8.2, how do I make ntpd not open any IPv6 ports? I have searched man pages and google, but haven't found the answer. Some ntpd have the command line option -4, but that doesn't seem to be the case with FreeBSD ntpd. The server runs IPv6, but ntpd will only ever be used with IPv4 servers, so I don't want any unnecessary open IPv6 ports for ntpd. "Use restrict" or "Use a firewall" is not the answer. I just don't want this junk in netstat -an: udp6 0 0 fe80:3::1.123 *.* udp6 0 0 ::1.123*.* udp6 0 0 x:x:x:x.123*.* udp6 0 0 fe80:2::219:bbff.123 *.* udp6 0 0 fe80:1::219:bbff.123 *.* udp6 0 0 *.123 *.* Thanks! -- Peter Olssonp...@leissner.se ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 7.1 and BIND exploit
About scripts for automating DNSSEC maintenance, check this out: http://www.hznet.de/dns/zkt/ There are also some DNSSEC howtos on that site. We use ZKT for our DNSSEC zones, and everything except KSK rollover is fully automated. Has been working fine for about half a year now. Automatic KSK rollover will be in next release of ZKT, I don't know the details of how that is going to work. -- Peter Olsson[EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Problems with OpenOffice compile after upgrade from 5.2.1 to 5.3
I recently upgraded from 5.2.1-p{something} to 5.3-p5.
The system seems fine after the upgrade, but I have one problem.
The reason for the upgrade to 5.3 was to be able to compile
OpenOffice, but when I tried to do that I got an error in the
dmake part stating that the file types.h didn't exist. While
searching for the cause of this problem I ended up in the directory
/usr/local/lib/gcc-lib/i386-portbld-freebsd5.2.1/3.2.3, where
I moved away the whole include directory. Then the OpenOffice
compile could finish the dmake part and continue.
Later in the compile I got errors because the include directory
was missing, so I moved it back. Now I get the error below about
types.h.
I think that the problem has to do with the fact that the files
in /usr/local/lib/gcc-lib/ seem to be from the 5.2.1 release I had
before upgrading. Why haven't these files been upgraded and how can
I fix the problem?
(I have to admit that I didn't go to single user before upgrading,
I just killed almost all of the processes without [] in the ps list.
This might be the cause of the problem.)
I have successfully compiled some other applications after the upgrade,
so the gcc-lib/i386-portbld-freebsd5.2.1 problem doesn't seem to break
everything.
Here is the current error:
cd ./unxfbsd.pro/misc/build/STLport-4.5/src && gmake -f gcc-3.0-freebsd.mak -j1
&& touch so_built_so_stlport
g++32 -D_REENTRANT -fexceptions -I../stlport
-DGXX_INCLUDE_PATH=/usr/local/lib/gcc-lib/i386-portbld-freebsd5.2.1/3.2.3/include/g++-v3
-Wall -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -ftemplate-depth-32
-fPIC dll_main.cpp -c -o ../lib/obj/GCC-FREEBSD/ReleaseD/dll_main.o
In file included from /usr/include/pthread.h:42,
from ../stlport/pthread.h:26,
from ../stlport/stl/_threads.h:74,
from ../stlport/stl/_alloc.h:64,
from ../stlport/memory:28,
from dll_main.cpp:38:
/usr/local/lib/gcc-lib/i386-portbld-freebsd5.2.1/3.2.3/include/sys/types.h:251:
syntax
error before `;' token
In file included from ../stlport/stl/_vector.h:572,
from ../stlport/vector:36,
from dll_main.cpp:39:
../stlport/stl/_bvector.h:37:1: warning: "__WORD_BIT" redefined
In file included from /usr/include/sys/limits.h:36,
from /usr/include/limits.h:128,
from
/usr/local/lib/gcc-lib/i386-portbld-freebsd5.2.1/3.2.3/include/limits.h:132,
from
/usr/local/lib/gcc-lib/i386-portbld-freebsd5.2.1/3.2.3/include/syslimits.h:7,
from
/usr/local/lib/gcc-lib/i386-portbld-freebsd5.2.1/3.2.3/include/limits.h:11,
from /usr/include/pthread.h:45,
from ../stlport/pthread.h:26,
from ../stlport/stl/_threads.h:74,
from ../stlport/stl/_alloc.h:64,
from ../stlport/memory:28,
from dll_main.cpp:38:
/usr/include/machine/_limits.h:95:1: warning: this is the location of the
previous definition
gmake: *** [../lib/obj/GCC-FREEBSD/ReleaseD/dll_main.o] Fel 1
dmake: Error code 2, while making
'./unxfbsd.pro/misc/build/so_built_so_stlport'
---* TG_SLO.MK *---
ERROR: Error 65280 occurred while making
/usr/ports/editors/openoffice-1.1-se/work/stlport
dmake: Error code 1, while making 'instsetoo/prj/build_all'
*** Error code 255
Stop in /usr/ports/editors/openoffice-1.1-se.
---* TG_SLO.MK *---
Thanks!
--
Peter Olsson[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
