gmirror(8) rebuild speed
Hi, I wonder if is possible to configure the gmirror rebuild speed. Neither I've found any related info in the net nor the man pages. -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ 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: gmirror(8) rebuild speed
To make it slower, I assume? When is that a good idea? It depends on what status your server are. For example: - if I've a fsck in background so the I/O is high, maybe I want to make it slower - If the box is completey unloaded maybe I want to make it quicker -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ 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: Inmutable bit in some binaries
It's possible installworld will break (fail/exit) when trying to overwrite some of these binaries. However... install(1) supports the -f flags to specify what the destination file should have its file flags (chflags) set to, and from looking at the code (src/usr.bin/xinstall/xinstall.c), there are some places which indicate before copying/installing a file the software may attempt to unset file flags first. I'm not 100% familiar with this code, but it appears as if use of the -S flag to install(1) would cause it to behave like described. It should be easy enough for you to test. Otherwise, my recommendation is to build a test system / virtual box of some sort (VMware, etc.) and try it. See what happens. Ok. It's exactly what I've supposed. Opinion below: What you're attempting to solve, ultimately, is security through obscurity and gets you a very large headache. :-) Your schg idea would only work if you planned on using kern.securelevel=1 or higher. This sounds great in concept, but many a time on this list have people posted problems with system administrative tasks (re: upgrading) when this sysctl is set to non-default (-1). Mm... I don't undestand this like secuiryt by obscurity; anyway you've the reason: kern.securelevel should be the correct path to follow. If you plan on using this, I would advocate *all* installation/work be done in single-user mode. I know quite a few people who completely ignore the boot into single user step of src/Makefile and instead do it in multi-user mode -- only to be found later screaming/crying when binaries don't work or behave oddly because, say, /libexec/ld-elf.so was supposed to be updated yet wasn't due to their choosing to not follow the proper procedure. If your system doesn't have an out-of-band method of getting to it (ex. serial console), then I wouldn't bother trying any of the above. Otherwise, I'm pretty sure others here have made use of read-only environments, such as read-only NFS root filesystems (sometimes accomplished via PXE) and/or /usr, or CD-based OS (good luck changing any files there). I can't help in that regard. Thanks for comments. ;) -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ 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: ionice in FreeBSD?
Great aclarations. Thanks. -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ 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: ionice in FreeBSD?
Great work Luigi ;) That's amazing... anyway ¿is it production-ready? -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ 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: ionice in FreeBSD?
On 02/03/2010 12:12 PM, Bruce Simpson wrote: On 02/02/2010 17:19, Jordi Espasa Clofent wrote: In FreeBSD we've nice(1), renice(8) and even rtprio, idprio(1) but if I'm understanding correctly, they're related to CPU priorty only, not to I/O. That's not entirely true. A thread's CPU priority is still going to affect its ability to be scheduled on the CPU, and if it's waiting in the read() or write() syscalls, then this will make a difference to how quickly it can complete the next call. Yes. I've already supposed it. However, it doesn't explicitly affect relative I/O prioritization. This is another story entirely. I suspect in a lot of cases adding a weight to per thread I/O, isn't going to make much difference for disk I/Os which are being sorted for the geometry (e.g. AHCI NCQ). So I guess my question is, 'why do you need I/O scheduling, and what aspect of system performance are you trying to solve with it' ? Some shell-scripts based on dd or rsync, for example. Even a daily antivirus (ClamAV) scanner means an extensive I/O. -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ 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
Inmutable bit in some binaries
HI all, I'm hardening one test box and at present I'm planning to do: # chflags -R schg file where file will be some binaries that seems to be common targets for rootkits and lammers: ls du ps find top locate strings ifconfig netstat login I wonder if changing these files permissions as I've shown above will be cause some troubles in future upgrade (recompilation, the classic way, not the binary upgrade one) process. ¿It will? -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ 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
ionice in FreeBSD?
Hi all, In Linux exists the ionice(1) for get/set program io scheduling class and priority. In FreeBSD we've nice(1), renice(8) and even rtprio, idprio(1) but if I'm understanding correctly, they're related to CPU priorty only, not to I/O. ¿Is there some ionice(1) equivalent in FreeBSD? -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ 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: About nice(1), renice(8) and ULE scheduler
In fact nice is a very simple program. It only changes the priority value of a process in a POSIX-compliant way. There is no need to change or adapt it; it still works fine in the SMP world and with new schedulers. It's up to the scheduler to interpret and handle the priority values of processes. In other words: The nice(1) tool only attaches a number to a process, nothing more. Only the scheduler knows what that number means. So there's no need to change nice(1). Great. So, the key is the scheduler; it makes sense. By the way, the source code of nice(1) is almost trivial. Basically it just calls the setpriority(2) and execve(2) syscalls. 99% of the source file consists of the BSD license test, arguments parsing and C syntax overhead. Thanks for aclaration. ;) -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ 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
About nice(1), renice(8) and ULE scheduler
HI all, I've realized that the nice(1) code hasn't been modified for a long time (last code change seems from 4 years ago according the sources). ¿Is the nice(1) behaviour the expected? I mean, ¿Has been the ULE scheduler adapted to nice(1) command or not? nice(1) is a very old command based on old concepts and created in times when SMP didn't exist. So ¿it works correctly when a modern an re-designed scheduler as ULE is used? Maybe I have to read again this paper: http://www.usenix.org/event/bsdcon03/tech/full_papers/roberson/roberson.pdf -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ 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
ssh+pam fails after 6.4 to 7.2 upgrade
Hi all, I've upgraded a FreeBSD box to 6.4 to 7.2; no problems here, all goes fine as usual. After the whole upgrade process I can't do ssh connections. Because of I use ssh through LDAP, it involves also the PAM modules. I've tried: - repeat the whole upgrade process because of I didn't know if the error comes from installworld step (it wil means than problem comes from the binaries itself) or from mergemaster step (it wil means that problem comes from config files). -CONCLUSION: it happens after the installworld and before the mergemaster, so it's no a problem of config files. It's a binaries-problem related. - recompile the pam_ldap package to force the re-link of underlaying libraries. - CONCLUSION: no effect. - disable the selective aknowledgement in TCP stack (using sysctl net.inet.tcp.sack.enable=0 and make it permament with echo net.inet.tcp.sack.enable=0 /ect/sysctl.conf). - CONCLUSION: no effect - using the ssh client with -o HostKeyAlgorithms=ssh-dss,ssh-rsa according to entry number 20080801 in UPDATING file in src tree. - CONCLUSION: no effect - debug the client and server side: // client [jespa...@jespasac ~]$ ssh -vvv my_host OpenSSH_5.2p1, OpenSSL 1.0.0-fips-beta4 10 Nov 2009 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to hc31.srv.cat [xxx.xxx.xxx.xxx] port 22. debug1: Connection established. debug1: identity file /home/jespasac/.ssh/identity type -1 debug3: Not a RSA1 key file /home/jespasac/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-END' debug3: key_read: missing keytype debug1: identity file /home/jespasac/.ssh/id_rsa type 1 debug1: identity file /home/jespasac/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 FreeBSD-20080901 debug1: match: OpenSSH_5.1p1 FreeBSD-20080901 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.2 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,z...@openssh.com,zlib debug2: kex_parse_kexinit: none,z...@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit:
Re: ssh+pam fails after 6.4 to 7.2 upgrade
You would probably need to reinstall the openldap-client package (and any packages openldap-client depends on) as well as the pam_ldap and nss-ldap packages. - $ portupgrade -fR openldap-client (-R flag implies the recompilation of openldap-client depenedent packages as well) CONCLUSION: no effect. I'm still thinking in PAM-related error. -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ 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: Hacked - FreeBSD 7.1-Release
# pfctl -sr | grep ssh_brutes block drop quick from ssh_brutes to any pass quick on em1 inet proto tcp from any to xxx.xxx.xxx.0/23 port = ssh flags S/SA keep state (source-track rule, max-src-conn 20, max-src-conn-rate 3/12, overload ssh_brutes flush global, src.track 12) pass quick on em0 inet proto tcp from any to xxx.xxx.xxx.0/23 port = ssh flags S/SA keep state (source-track rule, max-src-conn 20, max-src-conn-rate 3/12, overload ssh_brutes flush global, src.track 12) # pfctl -t ssh_brutes -T show 24.69.83.139 24.106.149.2 59.108.230.130 59.124.109.227 60.6.237.54 60.212.42.11 61.47.34.67 78.40.82.74 79.136.123.7 79.188.234.58 85.12.25.157 85.38.97.122 85.114.135.208 94.198.49.185 110.12.64.141 114.255.100.163 116.28.64.181 121.254.228.61 123.15.41.98 123.124.236.195 158.49.245.201 173.10.126.225 189.108.172.26 190.9.128.231 193.203.70.180 195.219.57.189 202.103.25.246 203.76.99.62 203.94.231.11 208.87.3.42 210.119.104.170 211.92.149.147 211.144.32.185 212.18.195.102 216.36.150.58 218.97.254.206 218.206.233.43 221.202.118.39 222.221.2.210 # uname -a OpenBSD tereo.xxx.com 4.5 GENERIC#0 amd64 -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ 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
Error upgrading 7.0 to 7.2 (buildword in gnu/usr.bin/binutils/libopcodes setp)
Hi all, I get the next nasty error: === gnu/usr.bin/binutils/libopcodes (all) cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libopcodes -I/usr/src/gnu/usr.bin/binutils/libopcodes/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libopcodes/../libbfd -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/include -DARCH_i386 -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/opcodes -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/opcodes/i386-dis.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libopcodes -I/usr/src/gnu/usr.bin/binutils/libopcodes/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libopcodes/../libbfd -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/include -DARCH_i386 -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/opcodes -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/opcodes/dis-buf.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libopcodes -I/usr/src/gnu/usr.bin/binutils/libopcodes/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libopcodes/../libbfd -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/include -DARCH_i386 -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/opcodes -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/opcodes/dis-init.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libopcodes -I/usr/src/gnu/usr.bin/binutils/libopcodes/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libopcodes/../libbfd -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/include -DARCH_i386 -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/opcodes -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/opcodes/disassemble.c building static opcodes library ranlib libopcodes.a === gnu/usr.bin/binutils/libbinutils (all) cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libbinutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/include -DTARGET=\x86_64-obrien-freebsd\ -DBFD_VERSION_STRING=\2.15 [FreeBSD] 2004-05-23\ -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils/arsup.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libbinutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/include -DTARGET=\x86_64-obrien-freebsd\ -DBFD_VERSION_STRING=\2.15 [FreeBSD] 2004-05-23\ -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils/bucomm.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libbinutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/include -DTARGET=\x86_64-obrien-freebsd\ -DBFD_VERSION_STRING=\2.15 [FreeBSD] 2004-05-23\ -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils/debug.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I.
Re: Error upgrading 7.0 to 7.2 (buildword in gnu/usr.bin/binutils/libopcodes setp)
Lowell Gilbert escribió: Does it always happen in the same place (if not, it's a hardware problem)? Hi Lowel, Yes, always at same point. Does it happen the same way without the '-j' option (that can make the output less useful)? Wonderful. I've used times the same command (1) without -j flag and... it works perfectly! It's curious, because of I always use the -j flag in buildworld with successs. It has been the first time that I've experienced this problem (1) chflags -R noschg /usr/obj/usr cd /usr/src make cleandir make cleandir make -j10 buildworld Thanks for all. ;) -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ 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
gjournal + gmirror
Hi all, I've configured a new disk with two journaled partitions (/var and /usr). All works fine until this point. Next I add a new disk and I set up a gmirror as I've done always without problems. But when I reboot the system, I always get a nasty 'mountroot' message. I've cheched the gmirror creation process (module in /boot/loader.conf, the modified fstab... all) and all is correct. I suspect some gjournal+gmirror especial issues maybe ¿Any clue? FreeBSD 7.2 AMD64 -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ 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
nscd in 6.x?
Hi all, I want to implement nscd in a lot of servers which has diferents releseases of 6.x and 7.x branches. No problem with 7.x branches: nscd seems part of the system now: # whereis nscd uname -r nscd: /usr/sbin/nscd /usr/share/man/man8/nscd.8.gz /usr/src/usr.sbin/nscd 7.0-RELEASE-p4 But not appears in 6.2: # whereis nscd uname -r nscd: 6.2-RELEASE-p11 or 6.3 # whereis nscd uname -r nscd: 6.3-RELEASE-p3 Moreover I've updated the src of one 6.3 to see if this it was included in 6.4 sources but also it's not there: # grep nscd /usr/src/sbin/ ¿Can I use nscd in 6.x branch? ¿Is there some 'alternative'? I've read about cached but I don't find anywhere in 6.3 (for example); the only one reference I've found is the port /usr/ports/databases/memcached, but I think it's not nscd-related at all. -- Thanks, Jordi Espasa Clofent ___ 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
nsswitch.conf bad configuration?
)) filter=((objectClass=posixAccount)(uid=postfix)) You can see the difference between user 'oscar? (exists in LDAP ddbb) and the others (doesn't exist in LDAP ddbb). The main question is ¿why appears users 'postfix', 'root', 'paola', 'sendmail' or even 'devnull' in LDAP log if they doesn't exist in LDAP database? Obviosly, they appears because there're query under this UID/username. I think the problem the /etc/nsswitch.conf of the servers (which are de LDAP clients): # cat /etc/nsswitch.conf group: files ldap passwd: files ldap #group: compat #group_compat: nis #hosts: files dns #networks: files #passwd: compat #passwd_compat: nis #shells: files #services: compat #services_compat: nis #protocols: files #rpc: files Maybe the commented lines do that the diferents users/daemons (like postfix, nobody or mailer-daemon) always look at group and passwd directives, which has files and ldap. So, they ask something in files (/etc/passwd and /etc/groups) and de default nsswitch.conf behaviour is, I don't know, please ask for to the next source and the query is passed to ldap resource. ¿Is it enough to comment out all the fields in /etc/nsswitch.conf? Feel free to point me out if isn't the right place for this kind of question (openldap lists also isn't, so it's a SO-related question rather than LDAP-related question). -- Thanks, Jordi Espasa Clofent ___ 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
Upgrade OpenSSH in 6.3 and 7.0 RELENG
Hello folks, I need to upgrade the OpenSSH from the shiped 4.5p1 versions in 6.x and 7.x branches to 4.5p2 or higher(1). I've updated the source tree in 6.3 and 7.0 RELENG boxes with a system upgrade in mind, but the version is 4.5p1: # cat /usr/src/crypto/openssh/version.h | grep -i ssh_version_base uname -r #define SSH_VERSION_BASEOpenSSH_4.5p1 6.3-RELEASE-p1 #cat /usr/src/crypto/openssh/version.h | grep -i ssh_version_base #define SSH_VERSION_BASEOpenSSH_4.5p1 On the other I see that current vesion in -STABLE is 5.2p1, so upgrade to STABLE is an obvious option, but, sincerely, I want to avoid to upgrade to -STABLE and I prefer to keep the systems in their current RELENG. ¿How can I upgrade the OpenSSH in the _same_ RELENG? ¿Maybe using the ports? (1) It seems correct some pam_ldap related issues: http://www.nabble.com/Re:-Password-expiry-warning-message-from-ppolicy-td8071732.html -- Thanks, Jordi Espasa Clofent ___ 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
Error in 7.0p5 upgrade
Hi all, I'm upgrading a FreeBSD amd64 box from 6.2p9 to 7.0p5. After update the sources amd make world with success, I get this error: [...] newfs.lo(.text+0x659): In function `main': : undefined reference to `__mb_sb_limit' newfs_msdos.lo(.text+0x13): In function `mklabel': : undefined reference to `__mb_sb_limit' restore.lo(.text+0xc60): In function `mkentry': : undefined reference to `__mb_sb_limit' restore.lo(.text+0xa6d6): In function `rmthost': : undefined reference to `__mb_sb_limit' sysctl.lo(.text+0xf9f): more undefined references to `__mb_sb_limit' follow tar.lo(.text+0x28f4): In function `read_archive': : undefined reference to `archive_read_support_compression_program' tar.lo(.text+0x3a81): In function `yes': : undefined reference to `__mb_sb_limit' tar.lo(.text+0x432a): In function `safe_fprintf': : undefined reference to `__mb_sb_limit' tar.lo(.text+0x6156): In function `tar_mode_c': : undefined reference to `archive_write_set_compression_program' vi.lo(.text+0x2f80): In function `cut': : undefined reference to `__mb_sb_limit' vi.lo(.text+0x2fb0): In function `cut': : undefined reference to `__mb_sb_limit' vi.lo(.text+0x311e): In function `cut': : undefined reference to `__mb_sb_limit' vi.lo(.text+0x5c29): In function `v_key_name': : undefined reference to `__mb_sb_limit' vi.lo(.text+0x5cf3): In function `v_key_name': : undefined reference to `__mb_sb_limit' vi.lo(.text+0x63b8): more undefined references to `__mb_sb_limit' follow *** Error code 1 Stop in /usr/obj/usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. after try the classical kernel compilation ( cd /usr/src make -DINSTALL_NODEBUG KERNCONF=MYKERNEL) I've not found any related info in the net. Anyones knows about? Last week I upgraded two others 6.2 amd boxes without problem. PD1. I use the classical method over new binary method because of my kernel is customized. PD2. I use -DINSTALL_NODEBUG flag because of my / partition is so small and need to preserve the maximum space. -- Thanks, Jordi Espasa Clofent ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Replication system
Hi all, I have to build a clustered website with FreeBSD 7.x as SO and Apache 2.x as httpd. As load-balancing solution I'll use HAProxy (or maybe a OpenBSD relayd, I'm not sure). Because of several technical (and especially non-technical) reasons, I haven't the possibility to mount a shared storage layer (NFS, SAN...) so I have to share the local data among the different httpd servers. At first approach I've thought in rsync+cron, but ¿anyone knows another replication-data solution in the described scenario? PD. Please, don't advice to me to using a pure shared-data layer... I know it will be the optimal structure, but as I've said above, I can't use it because various reasons. -- Thanks, Jordi Espasa Clofent ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Rare problems in upgrade process (corrupted FS?)
Hi all, I'm traying to update a FreeBSD server box from 6.3p11 to 7.0 and I've found a rare problems. 1) I do the sync process with csup(1); next I go into /usr/src/sys/amd64/conf to edit the GENERIC file (I use a custimized kernels) and this file doesn't exists. Mmmm I decide to repeat the process againt other cvsup mirror but I get the same results: GENERIC file isn't there. 2) I go to FreeBSD CVSWeb , locate the GENERIC file under the 7_0 tag, copy and paste. Yes, I know: a very nasty process. The big problem appears when I try to do 'make cleandir' and others. I get the next outputs: # pwd /usr/src # make cleandir make: don't know how to make cleandir. Stop # make buildworld make: don't know how to make buildworld. Stop # ls -l /usr/bin/make -r-xr-xr-x 1 root wheel 351024 Aug 18 13:19 /usr/bin/make # file /usr/bin/make /usr/bin/make: ELF 64-bit LSB executable, AMD x86-64, version 1 (FreeBSD), for FreeBSD 6.3, statically linked, stripped ¿?¿?¿?¿ * I reboot the machine (because of I suspect a very weird FS problem), boot in single user mode and do a 'fsck -fy'. Effectively, the fsck(8) found and repair several errors. Epecially, one error claims my attention: SUPERBLOCK. * After the theorical FS reparation I'm again in the point 1. ¿Any clues? -- Thanks, Jordi Espasa Clofent ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Rare problems in upgrade process (corrupted FS?)
I would do the following: rm -fr /usr/src/* rm -fr /var/db/sup/src-all csup -h cvsupserver -L 2 -g /usr/share/examples/stable-supfile I've done it. But the results are, at least, curious... # csup -h cvsup.de.FreeBSD.org -L 2 -g /usr/share/examples/cvsup/stable-supfile Parsing supfile /usr/share/examples/cvsup/stable-supfile Connecting to cvsup.de.FreeBSD.org Connected to 212.19.57.134 Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection src-all/cvs Shutting down connection to server Finished successfully # cd /usr/src ; ls -la total 0 Anythings exists now in /usr/src. I've tried again using another mirror and cvsup(1) instead of csup(1). Same results: nothing in /usr/src. It's desconcerting I can assure you /sys/amd64/conf/GENERIC exists, and is on the cvsup mirrors. Yes, of course. I've checked it from cvsweb. Superblock problems wouldn't explain this; there are hundreds of superblocks available (you wouldn't be able to use your machine if they were all horked). I've supposed it; your words confirm it. -- Thanks, Jordi Espasa Clofent ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Rare problems in upgrade process (corrupted FS?) [SOLVED]
Finally I've modified the stable-supfile TAG from *default release=cvs tag=RELENG_7_0 to *default release=cvs tag=RELENG_7 and... voilà!... it works! I've interrupted the csup process (^C) and change again the tag to *default release=cvs tag=RELENG_7_0 and it works perfecty. Maybe it's so stupid as the first tag was miss-typed... but I think not. I checked it several times. I'ts solved, but I don't understand yet. -- Thanks, Jordi Espasa Clofent ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Random reboots (amd64) SOLVED
Some time ago I was crazy with this problem: http://marc.info/?l=freebsd-amd64m=119783171822355w=2 Finally, it has been solved with upgrade from 6.2/6.3 to 7.0. I've no idea why, but nowadays the reboots doesn't exist. -- Thanks, Jordi Espasa Clofent ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
Many people have reported that the *order* of the extensions in extensions.ini has adverse (positive) effects on PHP segfaults on FreeBSD. I myself haven't ever run into extension ordering issues like those described (and we've done hosting for years), but I don't doubt those who have experienced such. Yes Jeremy, I known. I also don't doubt your words, but in my case the order of the extensions seems not any effect. The only solution has been comment the mentioned mbash extension. -- Thanks, Jordi Espasa Clofent ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
It seems a php-extensions bug. If you comment the mhash.so in /usr/local/etc/php/extensions.ini as: ;entension=mhash.so all works fine and you don't get anymore httpd crash (signal 11) if you use 'apachectl graceful'. Maybe will be a good idea to open PR for this? I hope it helps someone (I'm very surprised that this isn't a documented bug in 7.0 yet) -- Thanks, Jordi Espasa Clofent ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
