Re: pf buggy on 6.1-STABLE?
Mark Morley wrote: Wondering if this rings any bells for anyone: Yes it does... I had been seeing similar issues for some time on a couple HP Proliant servers - saw it in 5.4 as well - but have been attributing this to driver related issues (the bge driver in particular, which has seen many changes, fixes and enhancements in relatively recent history). In trying to isolate that particular problem I had been applying kernel updates regularly, pf was disabled along with a few other things (also switched from using mpd/netgraph to openvpn/udp), and the problem vanished at some point in between. I cannot definitely name pf as being the culprit as no testing of this was done at the time to confirm it. I had assumed the bge driver changes were responsible for things now working as they should. In addition to the occasional connection failure, I've also seen established connections broken (ssh, http, mysql/ssl and pptp/gre). This was causing havoc with mysql replication over the link, which became very brittle, and required manual fixing (it would get stuck, unable to read the last event in its relay log whenever a disconnection occurred and had to be manually pushed onto the next - mysql 5.0.[3 - .11 or so]). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: reading process memory
Tofik Suleymanov wrote: Thank you for brief and altogether extensive explanation of the case.The thing i wanted to do is to read let's say portions of memory where .bss and .data block of a running program reside. is that possible ? Yes. Debuggers offer this functionality, for example. man 2 ptrace Regards, David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HylaFAX port not work but related to sendmail
Paul.LKW wrote: Dear all: Recently I installed HylaFAX port on 6.1 and find that the fax received (Fax is received in /var/hylafax/recvq and changed to tiff format) can not sent to specified email user and find the error log below: May 30 04:08:56 office sendmail[624]: k4TK8t7A000620: to=ee-fax, delay=00:00:01, xdelay=00:00:01, mailer=local, pri=30505, dsn=5.3.0, stat=unknown mailer error 1 ^^^ Sendmail's configuration will be the problem. It isn't clear what you're trying to do here though so I can't make suggestions without seeing your .mc and knowing what your intention is (who is user ee-fax?). Sorry I haven't used any recent version of hylafax. Regards, DAvid ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: Custom termcap entries and installworld]
Stephen Hurd wrote: 1) How do people cope with custom termcap entries? One workaround is to not modify /etc/termcap at all. Instead just store them in a file somewhere and (depending on your shell) do export TERMCAP=/my/custom/termcap Or even export TERMCAP=custom:my custom entry See the ENVIRONMENT section near the bottom of man 3 curses. Hrm... I don't *think* this can be done by frobbing /etc/gettytab, but perhaps it can... I'll give it a shot. login.conf/.login_conf may help (to set environment variables before login shell starts, assuming that is what you need). But ~/.termcap should work regardless and will override termcap entries in the system termcap db. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Security Survey
Doug Hardie wrote: On May 21, 2006, at 20:55, Colin Percival wrote: If you administrate system(s) running FreeBSD (in the broad sense of are responsible for keeping system(s) secure and up to date), please visit http://people.freebsd.org/~cperciva/survey.html and complete the survey below before May 31st, 2006. What doesn't fit into the survey very well is that all my servers are production ones and it causes a lot of grief for users when I bring them down. I try to hold updates to once per year because of that. I am currently in the middle of upgrading from 5.3 to 6.0. The easy machines are done but there are still a few that will take considerable on-site time which is not easy to come by. A good failover strategy comes into play here. If you have one, then taking a single production machine off-line for a short period should be no big deal, even routine, and should not even be noticed by users if done correctly. This should be planned for and part of the network/system design. Yes, it definitely requires more resources to support, but I'll rephrase the same problem: what happens when (and I mean *when* and not *if*) a motherboard or network card fries or you suffer a hard disk crash (even 2+ drives failing at the same time on a raid array is not particularly unusual considering that drives are quite often from the same manufactured batch)? Lack of a failover on mission critical systems that *can't* be offline is like playing russian roulette. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RAID rebuild problem
Daniel O'Connor wrote: and rebuilt the array.. sudo atacontrol rebuild ar0 However the status stayed at 0%. On the rare occasion I've needed to do so, since 5.1 days, the atacontrol rebuild stays at 0%, last I tried this was on 6.1-PREPRELEASE ~mid February. The first time I gave up waiting after 2 days, now I'm not prepared to be so patient and won't bother until I hear it has been fixed. Instead I boot from a liveCD, delete the raid, dd copy the good disk to the degraded disk(s), redefine the raid, reboot. That still takes some hours to complete depending on the size/speed of the disks, but that at least works to get the raid back up. Since hotswap isn't currently supported the requirement to boot into single user isn't a severe limitation, but the downtime should be unnecessary. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.1 Released
J. T. farmer wrote: Mike Jakubik wrote: Jonathan Noack wrote: The *entire* errata page was from 6.0; it was a mistake. This wasn't some put on the rose-colored classes and gloss over major issues thing. It was a long release cycle and something was forgotten. C'est la vie. It's always a good idea to check the most up-to-date version of the errata page on the web anyway, so it's *not* too late to update it. How convenient. These problems needed to be addressed in the release notes, not some on line version. *Plonk* You've just entered into my do not read bucket. If you can't see that errors occur, then I pity _anyone_ who codes for you... Or perhaps you never make a mistake. That must be it. While I tend to agree with regards to poor attitude (see similar threads in almost any open source forum on the topic of demanding anything from a volunteer project), Mike is obviously quite passionate about and has the interests of FreeBSD at heart, and for that I cannot blame him at all. He seems to have a disagreement with handling of the release process, which is the same recurring issue every time there is a release and probably the #1 cause of burnout with the Release Engineer of the day. Historically, you can see that the current process works though, even if it may not produce the 100% perfect -RELEASE it at least guards against more serious problems that have happened in the past that were introduced by last minute and untested changes. Regards, David PS: cc -hackers removed ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with sk?
Michael Gerhards wrote: Apparently the timeout problem is fixed in -CURRENT, and will be merged after 6.1-RELEASE. Enjoy. Sounds good to me. I guess this won't be more than a few days, perhaps 1-2 weeks?! That is up to the committer, but I would imagine so. Tracking -STABLE is a Good Thing, IMHO, quite aside from the security updates, bugs which don't even affect you right now (but may do sometime) get fixed, and the -STABLE tag tends to be quite appropriate. I am quite new to FreeBSD and so I am not that familiar with all these things. But I read at some places that -STABLE is not always really stable and should not be used on productive systems. So I thought -RELEASE might be the correct choice for me. Actually, my own experience is that -STABLE is better suited to production systems, but YMMV. I don't think we are talking a big difference in relative stability. Note that I work in an environment where application upgrades are also relatively frequent so upgrading the OS as well requires very little extra effort (and is the only reason at all that production boxes are occasionally rebooted). -RELEASE is a snapshot of -STABLE which may or may not have problems (the whole idea of the release engineering process is reducing such problems if possible without introducing more to hopefully make a release less problematic than any other aribtrary snapshot) and in theory should provide the most stable OS, but the point to note is that -STABLE usually really means stable. There are normally no surprising new features being added and no intrusive changes to the way things work - just security, bug fixes and non-intrusive/optional features and enhancements as the version number increments, and you're tracking (in theory) better maintained code. Exceptions do happen when, for example, a bug is introduced or exposed, but not intentionally. The process of upgrading -stable has rarely caused me any grief at all if the instructions in src/UPDATING are followed. If you *really* need to be more conservative you can be more specific and track RELENG_6_1 so that you track only 6.1-RELEASE and subsequent security fixes but I've rarely done so for very long and don't see any advantage in freezing the OS at a specific version and do see plenty of disadvantages in not automatically getting fixes like the one being discussed here. Again YMMV, it depends a lot on how tolerant you can be of the once in a blue moon glitch that may or may not happen and whether new functionality or fixes brought into the stable branch is useful to you. Regards, David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with sk?
Michael Gerhards wrote:
But by browsing through this list I found the thread sk0: watchdog timeout
and the problem described there is quite similiar to what I get here. So
perhaps this bug in the sk driver is also the cause for my trouble here?!
Possibly (and even likely). It sounds like a very severe case of the
same thing.
I have been running a Marvell/Yukon 100mb adapter on FreeBSD RELENG_6
(the onboard NIC on an ASUS mb) and it does sometimes reset connections
and dmesg shows the timeout maybe 2 or 3 times a day. The system is
used in-house only and does not have high load (well, except for burst
load when serving samba and NFS shared ${PORTSDIR}/distfiles, which
overall works fine), so it is useable with the occasional but rarely
noticeable glitch, like a connection pausing for 10-15 seconds then
resuming.
Currently running:
FreeBSD 6.1-PRERELEASE #1: Thu Feb 23 09:03:11 EST 2006
~
skc0: Marvell Gigabit Ethernet port 0xd400-0xd4ff mem
0xfeaf8000-0xfeafbfff irq 22 at device 5.0 on pci2
skc0: Marvell Yukon Lite Gigabit Ethernet rev. A3(0x7)
sk0: Marvell Semiconductor, Inc. Yukon on skc0
I should mention that this is a vast improvement from a couple years ago
under 5.0 and 5.1 it would attach the driver to the card but the
interface was not functional at all.
Can I somehow use this patch for sk0 _without_ changing everything to
-current? Acutually, I wanted to stay to 6.1-RELEASE...
Apparently the timeout problem is fixed in -CURRENT, and will be merged
after 6.1-RELEASE. Enjoy.
Tracking -STABLE is a Good Thing, IMHO, quite aside from the security
updates, bugs which don't even affect you right now (but may do
sometime) get fixed, and the -STABLE tag tends to be quite appropriate.
I only ever used -RELEASE media for the initial install. A system I run
at home was originally installed from FreeBSD 3.0-CURRENT, also now
running a mid-Feb 6.1-PRERELEASE, upgraded from sources many many times
over (build world+kernel takes just under 3 days). :-)
Regards,
David
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
Janet Sullivan wrote: Mike Jakubik wrote: arrive at the sacrifice of stability. I think FreeBSD should only be released when known major bugs are worked out. A known broken release to me and most new users is useless, lets not release simply for the sake of numbering. For me, and many other quiet users, FreeBSD *IS* stable. I've been running 6.1 since the BETAs with no issues. Likewise, or at least very few. No, I don't use quotas. I doubt the majority of FreeBSD users do. I don't either, but the majority of FreeBSD users is a shifting thing, and very hard to make generalisations about. Once quota was about shell users, now it's more common for mail servers to manage storage quotas in a more appropriate way according to their storage mechanism and there are less shell users due to more convenient and user friendly networking applications that provide functionality that can be more easily secured. Quotas are now used more often with samba than anything else, and of course it's use has skyrocketted in recent years for obvious reasons. So who knows... Regards, David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Which RC?
Pietro Cerutti wrote: just updated my RELENG_6 as Tue May 2 08:25:55 CEST 2006 There are some things that are not clear about the version: - uname says FreeBSD 6.1-RC #0 - on the FreeBSD FTP site the RC directory is now RC2 (pub/FreeBSD/releases/i386/6.1-RC2) - on the FreeBSD web site the schedule for 6.1 says that actually 6.1-RC1 has been released How do I know which RC I'm currently running? You can sync your /usr/src with the time of RC2's release by extracting and build that specific version from CVS, but you'll want to track subsequent patches as well, right? RELENG_6 just builds with a -RC tag for now due to the version bump. It will revert to -STABLE once the -RELEASE is out, but built and installed from source you don't get the -RELEASE or -RCnumber tag unless you actually build a release (a la: cd /usr/src/release; make release BUILDNAME=? RELEASE=? CVSROOT=?), specify that as a tag and then do a binary upgrade. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4 postfix no longer logging
jason wrote: At some point in the last couple of weeks postfix on my 5.4-RELEASE system stopped logging to /var/log/maillog. The only thing in there now (and for all of the saved maillog files) is the turnover timestamp. Any suggestions where to look? Short answer - check: a) syslogd b) /etc/syslog.conf Long answer: syslogd is the logger daemon, and postfix will be logging through that. # /etc/rc.d/syslogd restart may fix the problem right there. Check /var/log/messages for any errors in syslogd startup. It may have crashed at some point or failed to start because of a serious syntax error in /etc/syslog.conf. If syslogd is running ok and working for the rest of the system, then double check /etc/syslog.conf to see where mail facility logging is directed (the default is /var/log/maillog, but that could have been changed or the line deleted). Check any settings in postfix for syslog facility (should be 'mail') and priority (if exists), match these against the filters in /etc/syslog.conf to make sure they are high enough to be logged. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
