Re: OpenLDAP 2.4.31 on FreeBSD 10.0-CURRENT/amd64 broken!
On 05/06/12 01:55, Dimitry Andric wrote: On 2012-05-05 17:54, Hartmann, O. wrote: Since Friday, I have on all of our FreeBSD 10.0-CURRENT/amd64 boxes massive trouble with net/openldap24-server (SASL enabled, so it is openldap-sasl-server). Last time OpenLDAP worked was Thursday last week, when obviously a problematic update to the OS was made I managed to reproduce the segfault you are seeing in slapd, which is caused by a problem in libthr.so, introduced in r234947. Please apply the attached diff, rebuild lib/libthr and install it, and then try your slapd tests again. Let us know. :) @David, can you please review this diff? It looks like there was a mistake merging from Perforce, where you also moved the line: sc = SC_LOOKUP(wchan); to the top of the _sleepq_add() function, just before the call to _sleepq_lookup(). If this isn't done, sc may be uninitialized when it is dereferenced later on in the function. GREAT! Everything works perfectly as expected and in its status quo as before the inconvenience. The problems I faced with xdm and others were due to a configuration mistake by myself in etc/ldap.conf, which I introduced while searching for problems. Dimitry, my personal thank you. Seriously. Regards, Oliver Hartmann signature.asc Description: OpenPGP digital signature
Re: problem with dhclient after update to FreeBSD-8.3
On 05/05/2012 19:30, Carmel wrote: I just updated my system to FreeBSD 8.3-STABLE #0 from version 8.2. I was getting warning messages regarding webcamd at boot-up; however, I got them fixed (I think) I loaded: cuse4bsd_load=YES in the loader.conf file and placed: webcamd_enable=YES in the rc.conf file. I had never used it before; however, I am assuming that the 8.3 version somehow requires it. What's happening is that 8.3 has introduced more comprehensive support for a wider range of USB devices. It's just picking up on the presence of a webcam now and suggesting software that could manage it. You don't need to enable the webcam at all: the kernel will recognise it as a webcam from its built-in identifying codes, but unless you enable some software to deal with it, it won't be able to do anything. This usually shows up with USB ethernet devices suddenly appearing and cluttering up ifconfig(8) output -- unlike webcams, ethernet interfaces generally do have kernel level support automatically enabled. devd will try and run dhclient on the interface to configure it, which I guess is where your extra dhclent invocation is coming from. It is possible to turn this behaviour off by adding something like: hint.usb.0.disabled=1 into /boot/loader.conf but this is using a sledgehammer to crack a nut, as that turns off that usb bus entirely. (Warning: This may well have deleterious effects on your ability to use a keyboard or mouse with the system: use cautiously. Also, change that '0' to the appropriate bus number if you need to) dhclient is listed as starting at the beginning of the log and again at the end. I never had this happen when using FreeBSD-8.2. I am still confused as to why devd wants to start webcamd devd only wants to start webcamd because you've installed the webcamd software including /usr/local/etc/devd/webcamd.conf If you pkg_delete the webcamd stuff and then restart devd, it won't try starting up webcamd any more. All I guess I really have to get corrected is the dhclient thing, assuming it is a real problem and just not some useless noise. The 'dhclient already running' message is untidy, but harmless. It's the rc system refusing to start a duplicate dhclient process on some interface. As your network interface is via a PCI device, I can't see why devd would think it should try and restart dhclient for it. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: problem with dhclient after update to FreeBSD-8.3
On Sun, 6 May 2012, Matthew Seaman wrote: On 05/05/2012 19:30, Carmel wrote: All I guess I really have to get corrected is the dhclient thing, assuming it is a real problem and just not some useless noise. The 'dhclient already running' message is untidy, but harmless. It's the rc system refusing to start a duplicate dhclient process on some interface. As your network interface is via a PCI device, I can't see why devd would think it should try and restart dhclient for it. http://www.freebsd.org/cgi/query-pr.cgi?pr=165477 may be relevant. It's on 9-stable, I haven't compared with 8.3. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Best mail setup for home server?
On Sat, 05 May 2012 10:21:10 -0500 Joshua Isom articulated: I currently use my FreeBSD system as my generic unix server and some coding, along with occasional multimedia. I'd installed postfix years ago and kept using it. Right now, I use getmail with cron, dspam, and dovecot to handle my gmail account. I've never set up outgoing mail which makes changing email clients, or devices, annoying. Currently postfix is set to use dovecot's deliver command so that dovecot can sort and handle it. Before I deal with setting postfix to relay the mail, dealing with firewalls and other possible issues, is there a better alternative? I'd prefer that local mail just works even if I lose internet, and any email that gets as far as my server will at least eventually mail. The archlinux wiki seems to suggest ssmtp doesn't work properly with attachments. Instead it recommends msmtp, which requires an active internet connection to use. Dragonfly's dma is local only to the computer and not the LAN. Are the only options configuring sendmail or configuring postfix? If you only have a dynamic IP, you might want to investigate something like: http://dyn.com/; or a similar service. Attempting to send mail from a dynamic IP will usually result in it being marked as Spam and discarded or just being outright refused by an up-line MTA. Personally, I would stick with Postfix, obviously the latest version. It is far easier to configure than Sendmail and you can actually speak with its author if a problem arises. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ The Wright Brothers weren't the first to fly. They were just the first not to crash. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: problem with dhclient after update to FreeBSD-8.3
On Sun, 6 May 2012 04:25:52 -0600 (MDT) Warren Block articulated: On Sun, 6 May 2012, Matthew Seaman wrote: On 05/05/2012 19:30, Carmel wrote: All I guess I really have to get corrected is the dhclient thing, assuming it is a real problem and just not some useless noise. The 'dhclient already running' message is untidy, but harmless. It's the rc system refusing to start a duplicate dhclient process on some interface. As your network interface is via a PCI device, I can't see why devd would think it should try and restart dhclient for it. http://www.freebsd.org/cgi/query-pr.cgi?pr=165477 may be relevant. It's on 9-stable, I haven't compared with 8.3. Warren, I posted an addendum to that PR to indicate that the behavior is also occurring on 8.3 systems as well. Do you think it would be prudent to open a new PR with my info since it concerns FreeBSD-8.3 STABLE and not the 9.0 branch? I was also wondering if anyone other than myself is seeing this phenomenon on the 8.3 version. -- Carmel ✌ carmel...@hotmail.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: problem with dhclient after update to FreeBSD-8.3
On Sun, 06 May 2012 10:48:31 +0100 Matthew Seaman articulated: On 05/05/2012 19:30, Carmel wrote: I just updated my system to FreeBSD 8.3-STABLE #0 from version 8.2. I was getting warning messages regarding webcamd at boot-up; however, I got them fixed (I think) I loaded: cuse4bsd_load=YES in the loader.conf file and placed: webcamd_enable=YES in the rc.conf file. I had never used it before; however, I am assuming that the 8.3 version somehow requires it. What's happening is that 8.3 has introduced more comprehensive support for a wider range of USB devices. It's just picking up on the presence of a webcam now and suggesting software that could manage it. You don't need to enable the webcam at all: the kernel will recognise it as a webcam from its built-in identifying codes, but unless you enable some software to deal with it, it won't be able to do anything. While that may well be true, it does clutter up the boot-up process with a lot of sinister if only benign looking warning messages. There should be a way to silence them or at least make the warning message less sinister looking. Something like: webcamd present but not enabled like is done for other devices. This usually shows up with USB ethernet devices suddenly appearing and cluttering up ifconfig(8) output -- unlike webcams, ethernet interfaces generally do have kernel level support automatically enabled. devd will try and run dhclient on the interface to configure it, which I guess is where your extra dhclent invocation is coming from. It is possible to turn this behaviour off by adding something like: hint.usb.0.disabled=1 into /boot/loader.conf but this is using a sledgehammer to crack a nut, as that turns off that usb bus entirely. (Warning: This may well have deleterious effects on your ability to use a keyboard or mouse with the system: use cautiously. Also, change that '0' to the appropriate bus number if you need to) I think I will skip the sledgehammer technique for now. Thanks for the suggestion though. :) dhclient is listed as starting at the beginning of the log and again at the end. I never had this happen when using FreeBSD-8.2. I am still confused as to why devd wants to start webcamd devd only wants to start webcamd because you've installed the webcamd software including /usr/local/etc/devd/webcamd.conf If you pkg_delete the webcamd stuff and then restart devd, it won't try starting up webcamd any more. I don't think removing it is really an option: pkg_info -R webcamd-3.5.0.2 Information for webcamd-3.5.0.2: Required by: gstreamer-plugins-all-1.3.0.10.1_12 gstreamer-plugins-v4l2-0.10.30,3 kde-4.7.4_1 kde-workspace-4.7.4_1 kdeartwork-4.7.4_1 kdenetwork-4.7.4_2 kdeplasma-addons-4.7.4_1 kdetoys-4.7.4_1 kdeutils-4.7.4_2 phonon-gstreamer-4.5.1 qt4-4.7.4 qt4-qtconfig-4.7.4 Interestingly enough, I never had webcamd initiated in the /etc/rc.conf file and never received a warning message about it having to be initialized until the update to FreeBSD-8.3. I am not sure if this should be considered a BUG or what. It doesn't appear that any of the software that requires it to be installed also require it to be running at boot-up. I don't even know who, if anyone, I should report this behavior to. All I guess I really have to get corrected is the dhclient thing, assuming it is a real problem and just not some useless noise. The 'dhclient already running' message is untidy, but harmless. It's the rc system refusing to start a duplicate dhclient process on some interface. As your network interface is via a PCI device, I can't see why devd would think it should try and restart dhclient for it. There does appear to be a PR listed against this behavior as noted in Warren's post on this thread. http://www.freebsd.org/cgi/query-pr.cgi?pr=165477 Thanks for your assistance Matthew. -- Carmel ✌ carmel...@hotmail.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
kernel configuration file
In the Generic kernel configuration file for FreeBSD/amd64, if I do not have a floppy drive, is it safe to comment out this entry? # Floppy drives device fdc Are there any other entries that I could eliminate if I do not have a floppy drive? Also, according the the webcamd documentation, I need to have this in the loader.conf file. webcamd requires the cuse4bsd(3) kernel module. To load the driver as a module at boot time, place the following line in loader.conf(5): cuse4bsd_load=YES Is there a way that I can simply compile it into the kernel? Would a: device cuse4bsd# Required by webcamd entry in the kernel file work? I cannot find any documentation on that. -- Carmel ✌ carmel...@hotmail.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: kernel configuration file
Carmel carmel...@hotmail.com wrote; In the Generic kernel configuration file for FreeBSD/amd64, if I do not have a floppy drive, is it safe to comment out this entry? # Floppy drives device fdc Definitely, yes. Are there any other entries that I could eliminate if I do not have a floppy drive? device atapifd obviouly. :) Also, according the the webcamd documentation, I need to have this in the loader.conf file. webcamd requires the cuse4bsd(3) kernel module. To load the driver as a module at boot time, place the following line in loader.conf(5): cuse4bsd_load=YES Is there a way that I can simply compile it into the kernel? Would a: device cuse4bsd# Required by webcamd entry in the kernel file work? I cannot find any documentation on that. The simplest approach for this is 'try it and find out'. If you use the traditional kernel-huild 'Configure/make depend/make' sequence, to rebuild the kernel -only-, its a matter of one minute or so on a _slow_ (486-class) machine. you'll either get a Configure error, a linker error, or it 'just works'. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: kernel configuration file
On Sun, 6 May 2012 08:08:31 -0500 (CDT) Robert Bonomi articulated: Carmel carmel...@hotmail.com wrote; In the Generic kernel configuration file for FreeBSD/amd64, if I do not have a floppy drive, is it safe to comment out this entry? # Floppy drives device fdc Definitely, yes. Are there any other entries that I could eliminate if I do not have a floppy drive? device atapifd obviouly. :) Thanks, I had not noticed that one. Also, according the the webcamd documentation, I need to have this in the loader.conf file. webcamd requires the cuse4bsd(3) kernel module. To load the driver as a module at boot time, place the following line in loader.conf(5): cuse4bsd_load=YES Is there a way that I can simply compile it into the kernel? Would a: device cuse4bsd# Required by webcamd entry in the kernel file work? I cannot find any documentation on that. The simplest approach for this is 'try it and find out'. If you use the traditional kernel-huild 'Configure/make depend/make' sequence, to rebuild the kernel -only-, its a matter of one minute or so on a _slow_ (486-class) machine. you'll either get a Configure error, a linker error, or it 'just works'. OK, now you lost me. I use the following basic sequence: make buildworld make buildkernel KERNCONF=CARMEL make installkernel KERNCONF=CARMEL make installworld I am sorry, but I am not fully comprehending what commands you want me to enter. -- Carmel ✌ carmel...@hotmail.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: kernel configuration file
On Sunday 06 May 2012 10:34:12 Carmel wrote: On Sun, 6 May 2012 08:08:31 -0500 (CDT) Robert Bonomi articulated: Carmel carmel...@hotmail.com wrote; In the Generic kernel configuration file for FreeBSD/amd64, if I do not have a floppy drive, is it safe to comment out this entry? # Floppy drives device fdc Definitely, yes. Are there any other entries that I could eliminate if I do not have a floppy drive? device atapifd obviouly. :) Thanks, I had not noticed that one. Also, according the the webcamd documentation, I need to have this in the loader.conf file. webcamd requires the cuse4bsd(3) kernel module. To load the driver as a module at boot time, place the following line in loader.conf(5): cuse4bsd_load=YES Is there a way that I can simply compile it into the kernel? Would a: device cuse4bsd# Required by webcamd entry in the kernel file work? I cannot find any documentation on that. The simplest approach for this is 'try it and find out'. If you use the traditional kernel-huild 'Configure/make depend/make' sequence, to rebuild the kernel -only-, its a matter of one minute or so on a _slow_ (486-class) machine. you'll either get a Configure error, a linker error, or it 'just works'. OK, now you lost me. I use the following basic sequence: make buildworld make buildkernel KERNCONF=CARMEL make installkernel KERNCONF=CARMEL make installworld I am sorry, but I am not fully comprehending what commands you want me to enter. Carmel; You don't need to build the whole world if you only need a kernel rebuild. just edit your kernel file and issue: cd /usr/src make kernel KERNCONF=CARMEL the 2nd line builds AND installs the new kernel. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winblows FREE) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: kernel configuration file
On 06/05/2012 14:34, Carmel wrote: Is there a way that I can simply compile it into the kernel? Would a: device cuse4bsd# Required by webcamd entry in the kernel file work? I cannot find any documentation on that. cuse4bsd is a third party module. This means that the sources aren't available as part of the base system, so making work as compiled-in code in the kernel will require you to create patches for your kernel source tree. Not impossible, but not trivial either. I don't know if hps@ has any plans to import it into the base system (I doubt it though), but it would only appear a few releases down the line even if he did. OK, now you lost me. I use the following basic sequence: make buildworld make buildkernel KERNCONF=CARMEL make installkernel KERNCONF=CARMEL make installworld I am sorry, but I am not fully comprehending what commands you want me to enter. If you don't update the system sources, then you can try a new kernel config without rebuilding world all the time. Like so: make buildkernel KERNCONF=CARMEL make installkernel KERNCONF=CARMEL shutdown -r now Just (re)building the kernel takes a lot less time than rebuilding the entire base system. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Samba acting oddly.
I have a problem with Samba, well I think it is samba as one machine I have access to when I try to perform an action like create a new folder in my home folder windows spouts that I need permission and would I like to try again. I guess some background would be useful at this point, I have 3 FreeBSD machines that were running 8.2 AMD 64, some kind souls on this list were able to help me get Samba working using Active Directory, I upgraded to 9.0 when it became available and everything seemed to be fine. I happened to be needing to create a perl script that would allow two users to chat over a network, so rather than fiddling about with Linux and VM`s .. I just used two of my FreeBSD machines, this is when I noticed the issue. Only one machine shows this problem, the others let me happily create / delete stuff in the home folder other shares on the problematic machine are fine. The configuration files for all 3 machines is included below, but I just cannot seen to see why 2 work and 1 does as all three are running Samba35-3.5.6.2 so any help or pointers would be welcome. Regards Graeme Machine Eris - samba works perfectly Smb.conf looks like this [global] workgroup = UNIVERSE realm = UNIVERSE.GALAXY.LCL netbiosname = ERIS interfaces = re0 security = ads allow trusted domains = yes idmap uid = 5000-1 #idmap gid = 15000-2 winbind gid = 5000-1 template homedir = /usr/home/%U template shell = /bin/csh winbind cache time = 3600 winbind nested groups = yes winbind use default domain = yes winbind separator = | winbind enum users = yes winbind enum groups = yes winbind offline logon = yes syslog only = Yes socket options = SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY use sendfile = yes read raw = yes use sendfile = yes local master = no use sendfile = yes dns proxy = no username map = /usr/local/samba/usermap # ACL Support map acl inherit = yes #acl group inherit = yes acl group control = yes # LOGGING log file = /var/log/samba/%m log level = 1 max log size = 1000 syslog = 2 ### recycle bin code # bin vfs object = recycle recycle:repository = .RecycleBin/%U recycle:keeptree = Yes recycle:touch = Yes recycle:versions = Yes recycle:maxsize = 0 recycle:exclude = *.tmp recycle:exclude_dir = /tmp recycle:noversions = *.ppt [homes] readonly=no other shares below Machine Proteus - samba working a charm ... [global] workgroup = UNIVERSE realm = UNIVERSE.GALAXY.LCL netbiosname = PROTEUS interfaces = re0 security = ads allow trusted domains = yes idmap uid = 5000-1 #idmap gid = 15000-2 winbind gid = 5000-1 template homedir = /usr/home/%U template shell = /bin/csh winbind cache time = 3600 winbind nested groups = yes winbind use default domain = yes winbind separator = | winbind enum users = yes winbind enum groups = yes winbind offline logon = yes syslog only = Yes socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536 use sendfile = yes read raw = yes use sendfile = yes local master = no use sendfile = yes dns proxy = no username map = /usr/local/samba/usermap # ACL Support map acl inherit = yes #acl group inherit = yes acl group control = yes # LOGGING log file = /var/log/samba/%m log level = 1 max log size = 1000 syslog = 2 [homes] read only = No Both of these work with no issues. However Amalthea which is the machine showing the problem, the smb.conf is the following [global] workgroup = UNIVERSE realm = UNIVERSE.GALAXY.LCL netbiosname = amalthea interfaces = nfe0 security = ads allow trusted domains = yes idmap uid = 5000-1 #idmap gid = 15000-2 winbind gid = 5000-1 template homedir = /usr/home/%U template shell = /bin/csh winbind cache time = 3600 winbind nested groups = yes winbind use default domain = yes winbind separator = | winbind enum users = yes winbind enum groups = yes winbind offline logon = yes syslog only = Yes socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536 use sendfile = yes read raw = yes use sendfile = yes local master = no use sendfile = yes dns proxy = no username map = /usr/local/samba/usermap # ACL Support map acl inherit = yes #acl group inherit = yes acl group control = yes # LOGGING log file = /var/log/samba/%m log level = 1 max log size = 1000syslog = 2 ### recycle bin code # bin vfs object = recycle recycle:repository = .RecycleBin/%U recycle:keeptree = Yes recycle:touch = Yes recycle:versions = Yes recycle:maxsize = 0 recycle:exclude = *.tmp recycle:exclude_dir = /tmp recycle:noversions = *.ppt [homes] readonly=no ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: kernel configuration file
On Sun, 06 May 2012 14:58:39 +0100 Matthew Seaman articulated: cuse4bsd is a third party module. This means that the sources aren't available as part of the base system, so making work as compiled-in code in the kernel will require you to create patches for your kernel source tree. Not impossible, but not trivial either. I don't know if hps@ has any plans to import it into the base system (I doubt it though), but it would only appear a few releases down the line even if he did. Thanks Matthew, that answered my question. It would seem that importing that module in the base system would be a wise idea; however, that decision is not mine to make. -- Carmel ✌ carmel...@hotmail.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: help debug bwn(4) wireless
In freebsd-questions Digest, Vol 413, Issue 11, Message: 21 On Sat, 5 May 2012 19:26:00 -0400 (EDT) Chris Hill ch...@monochrome.org wrote: On Sat, 5 May 2012, Robert Bonomi wrote: Anton Shterenlikht me...@bristol.ac.uk wrote; [snip] ...I still find the whole networking area perfectly impenetrable. (If you can recommend a really introductory book on the subject, I'd really appreciate it. [snip] See also TCP/IP Network Administration. This is an O'Reilley Associates book. Virtually *everything* they publish is excellent. If they've ever published an even mediocre book, _I_ have never encountered it. Anton, I'll second that recommendation. 'TCP/IP Network Administration' by Craig Hunt is an outstanding book; it taught me a lot about networking, really made the subject comprehensible. The other O'Reilly book that I found indispensable when getting started was 'Essential System Administration' by Aeleen Frisch. In fact, why don't I just me too about O'Reilly. Everything of theirs that I have seen has been excellent. I'll third it Chris. Apart from Tanenbaum's seminal 'Computer Networks' (qv) a decade earlier, I learned most of what I needed to setup mail, DNS, other servers and TCP/IP networking in general from Hunt's book. I also borrowed Frish's excellent book (for about five years :) and found it invaluable for all sorts of sysadmin tasks, including good shell scripting techniques, covering a wide range of unixish OSes. Anton, I'm not sure what the state of the art is for multiple network profiles for such as wireless vs wired, home and work etc, but look around. I recall one called just 'profile' from years ago, and more recently talk of 'failover' setups for wired/wireless nets (probably in n...@freebsd.org), but I've no time for hunting tonight. Anyone? cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: kernel configuration file
From owner-freebsd-questi...@freebsd.org Sun May 6 08:36:52 2012
Date: Sun, 6 May 2012 09:34:12 -0400
From: Carmel carmel...@hotmail.com
To: FreeBSD freebsd-questions@freebsd.org
Subject: Re: kernel configuration file
On Sun, 6 May 2012 08:08:31 -0500 (CDT)
Robert Bonomi articulated:
If you use the traditional kernel-huild 'Configure/make depend/make'
sequence, to rebuild the kernel -only-, its a matter of one minute or
so on a _slow_ (486-class) machine.
you'll either get a Configure error, a linker error, or it 'just
works'.
OK, now you lost me. I use the following basic sequence:
make buildworld
make buildkernel KERNCONF=CARMEL
make installkernel KERNCONF=CARMEL
make installworld
I am sorry, but I am not fully comprehending what commands you want me
to enter.
That's the 'modern' way.
Note: make buildkernel forcibly rebuilds everything, *EVERY* time.
Including *every* loadable module, whether or not you actually use it.
Which can be *really* painful on slow hardware (like 20+ *hours*, on a
486-class machine).
The 'traditional' custom kernel-construction sequence is:
cd /sys/{architecture}/conf
$EDIT {kernelname}C
config {kernelname}
cd ../../compile/{kernelname}
make depend
make
Then, 'make install', to install it as the defalt kernel to boot from,
or copy it to /boot/kernel/{foo} if you just want to test it by manually
selecting it at boot time..
For 'minor' kernel-only changes -- _I_ use custom kernels with =everything=
I need 'compiled in', *no* loadable modules, I'm in no mood to wait for all
the never used modules to be re-built -- The 'traditional' method is
_far_ faster. On a 700 mhz PIII, it is circa 90 seconds when I make a
simple configuration change -- e.g., add a 'device', change an 'option',
change a 'value'. *MOST* of which is the 'make depend' stage. the actual
'make' is under 10 seconds on _that_ hardware.
'make buildkernel' always works for every configuration. It does it by
being extremely pessimistic about what needs to be re-built. i.e., it
=always= assumes everything is out-of-date. This subverts one of the major
reasons 'make' exists -- to rebuild only the -minimal- set of things that
are affected by a given set of changes. It is 'foolproof', but the
skilled kernel builder pays an *incredible* performance penalty for
using something that attemptss to outwit the classical 'sufficiently
determined fool'.
I don't object (well, 'much', that is, see below) to 'make buildkernel',
or even to it being promoted in the Handbook as the 'preferred' means of
kernel building. It _really_ annoys that it is listed therein as the
-only- way. The 'traditional' methodology is fast becoming 'lost art',
along with the related knowledge of _how_ the process works,
'make buildkernel' is a black box, reminiscent of MS Windows 'magic'.
When it works, all is fine. when it breaks, you've got essentially no
information to work with about 'what went wrong'.
With the 'traditional' method, at least all the commands have manpages,
that tell you -what- each command does, in a fair amount of detail.
/rant
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: kernel configuration file
On Sun, 6 May 2012 13:23:08 -0500 (CDT), Robert Bonomi wrote: From owner-freebsd-questi...@freebsd.org Sun May 6 08:36:52 2012 Date: Sun, 6 May 2012 09:34:12 -0400 From: Carmel carmel...@hotmail.com To: FreeBSD freebsd-questions@freebsd.org Subject: Re: kernel configuration file On Sun, 6 May 2012 08:08:31 -0500 (CDT) Robert Bonomi articulated: If you use the traditional kernel-huild 'Configure/make depend/make' sequence, to rebuild the kernel -only-, its a matter of one minute or so on a _slow_ (486-class) machine. you'll either get a Configure error, a linker error, or it 'just works'. OK, now you lost me. I use the following basic sequence: make buildworld make buildkernel KERNCONF=CARMEL make installkernel KERNCONF=CARMEL make installworld I am sorry, but I am not fully comprehending what commands you want me to enter. That's the 'modern' way. The /usr/src/Makefile contains a comment header which explains the purpose of the make targets the current way supports. One should read it before starting, because it's quite informative on _that_ way of doing things (e. g. make kernel = make buildkernel installkernel). Note: make buildkernel forcibly rebuilds everything, *EVERY* time. Including *every* loadable module, whether or not you actually use it. Which can be *really* painful on slow hardware (like 20+ *hours*, on a 486-class machine). Maybe it's worth mentioning /etc/src.conf and /etc/make.conf and the man src.conf manpage. That is a comfortable means to avoid building (and therefore also installing) modules one does not need. The approach to configure all and _only_ the stuff I need in a custom kernel can be followed this way, and it will even work with the current make target way. Have no WLAN? So why bother building it? No ISDN? Omit it! For minor kernel changes (e. g. if you want to try some compile-time settings), this approach is really handy as it minimizes the time required. This consideration should _boost_ build+install times on current plentycore multiprocessors with tons of RAM! :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: help debug bwn(4) wireless
On 06/05/2012 17:31, Ian Smith wrote: Anton, I'm not sure what the state of the art is for multiple network profiles for such as wireless vs wired, home and work etc, but look around. I recall one called just 'profile' from years ago, and more recently talk of 'failover' setups for wired/wireless nets (probably in n...@freebsd.org), but I've no time for hunting tonight. Anyone? Would that be lagg? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html Chris cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Best mail setup for home server?
--As of May 5, 2012 10:21:10 AM -0500, Joshua Isom is alleged to have said: I currently use my FreeBSD system as my generic unix server and some coding, along with occasional multimedia. I'd installed postfix years ago and kept using it. Right now, I use getmail with cron, dspam, and dovecot to handle my gmail account. I've never set up outgoing mail which makes changing email clients, or devices, annoying. Currently postfix is set to use dovecot's deliver command so that dovecot can sort and handle it. Before I deal with setting postfix to relay the mail, dealing with firewalls and other possible issues, is there a better alternative? I'd prefer that local mail just works even if I lose internet, and any email that gets as far as my server will at least eventually mail. --As for the rest, it is mine. I've been using Postfix for a decade to do basically this; no major problems, and it doesn't take much to set up. No reason to go to something else. (Even for speed: I've used it for work on a site handling millions of messages a day...) As has been said, a local resolver will help. The thing to watch for is what mail you'll let it accept: It's moderately easy to set it up as an open relay, which you *don't* want to do. Accept from the local network is fine; I've never needed to set up authenticated sending from outside that, though I keep meaning to when I have some free time... The dynamic IP problem can be a hassle, and lead to weird losses of mail. My solution has just been to call the ISP and get a 'business' line, with a static IP, though forwarding to their mail relay would work as well. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
