Re: segfaulting gcc
Jiri Novak wrote: and I have noticed that lots of ports fail to build because of internal compiler error from GCC... Does the error always occur in the same place? If not, then it is possible you have a hardware fault. A segmentation fault results from bad memory access, which could be a program(mer) fault, but in something as well developed as GCC, they ought never to happen. If it is a hardware fault, the likely culprits are memory and disk. Do you have any interesting messages in /var/log/messages? --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to find which port has a given executable
Christopher Nehren wrote:
On 2005-03-23, Alex Zbyslaw scribbled these
curious markings:
% find /usr/ports -type f -name pkg-plist -exec egrep -H epstopdf {} \;
Just a bit of nitpickery: I've found that piping the output to xargs
rather than using find's exec produces faster results. Plus, you (most
of the time) don't need to use constructs like {} \;. :)
I've been typing it like this for 20 years and my fingers can type {} \;
faster than a speeding bullet, or at least a run-away zimmer frame.
Leave us old fogeys in peace. You and your new fangled commands
starting with x that aren't X11 applications. If it wasn't in 4.1BSD it
isn't worth using. Anyway, the manual page for xargs just makes my
brain hurt. :)
Charles Swiger wrote: On Mar 23, 2005, at 1:22 PM,
pkg_which epstopdf
...is probably even faster and easier.
% pkg_which epstopdf
epstopdf: not found
Just like pkg_info -W it doesn't seem to work unless the package is
installed
--Alex
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to find which port has a given executable
Michael C. Shultz wrote:
Is it possible to find out which port has a particular
executable/script file ? It took me some time to find
out if the script epstopdf was in latex or tex or tetex!
Any easy way to do this ?
Here is an example:
pkg_info -W /usr/X11R6/bin/nedit
/usr/X11R6/bin/nedit was installed by package nedit-5.5
I think the question might have been about a file from port which wasn't
yet installed, in which case it's a little more time consuming:
% find /usr/ports -type f -name pkg-plist -exec egrep -H epstopdf {} \;
/usr/ports/chinese/cwtex/pkg-plist:share/texmf/cwtex/help/epstopdf.txt
/usr/ports/print/teTeX-base/pkg-plist:bin/epstopdf
/usr/ports/print/teTeX-texmf/pkg-plist:%%TEXMFDISTDIR%%/doc/help/Catalogue/entries/epstopdf.html
/usr/ports/print/teTeX-texmf/pkg-plist:%%TEXMFDISTDIR%%/tex/latex/oberdiek/epstopdf.sty
/usr/ports/textproc/rubber/pkg-plist:%%PYTHON_SITELIBDIR%%/rubber/graphics/epstopdf.py
/usr/ports/textproc/rubber/pkg-plist:%%PYTHON_SITELIBDIR%%/rubber/graphics/epstopdf.pyc
/usr/ports/japanese/ptex-common/pkg-plist:bin/epstopdf
--Alex
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mkhomedir.so is missing =(
JP wrote: I need some help trying to locate or how to obtain/build a file named mkhomedir.so this file is needed to create home directories after logging in successfully though winbind. I am running FreeBSD 5.3 Release, and Samba 3. % locate mkhome /usr/src/contrib/libpam/doc/modules/pam_mkhomedir.sgml /usr/src/contrib/libpam/modules/pam_mkhomedir /usr/src/contrib/libpam/modules/pam_mkhomedir/Makefile /usr/src/contrib/libpam/modules/pam_mkhomedir/pam_mkhomedir.c --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ssh password delay -- SOLVED
darren wrote: order hosts,bind multi on Glad you got it fixed. Where did you find this config documented? My 4.10 hosts.conf man page doesn't mention anything like this (and 5.3 seems to have lost the file altogether -- at least there was no man page for it). --Alex, curious ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildworld errors
Charles Swiger wrote: Actually, if the compile crashes out at different points, that's almost a sure sign of a hardware issue, most probably overheating. If you were just running the system as a network router before, that involves so little load that you wouldn't stress anything, but building world is a good stress test and marginal cooling will show symptoms like what you've described. I've seen something similar on a Linux box when it was the memory at fault. But definitely hardware! --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ssh password delay
Gary Smithe wrote: If that is your resolv.conf, then that explains some things. Your box is looking at the ISP for name resolution and the ISP has no idea (nor could care) what your internal LAN address space is. Change the resolv.conf to look at itself (127.0.0.1) and setup BIND with some simple DNS and RDNS records. You could use pretty much any box on your network for DNS, but the key is that it has to know about the internal space. Or fix your /etc/host.conf to lookup in files first and then use DNS, then put your local network in /etc/hosts. Much simpler for a small network. E.g. /etc/host.conf # First try the /etc/hosts file hosts # Now try the nameserver next. bind And /etc/hosts 192.168.0.1 myhost Then leave resolv.conf alone. It will be used for anything not in your local hosts file. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Backup on DDS-4 tapes
Ludo Koren wrote: It doesn't help either... The result is the same. Just to check I'm understanding your problem correctly -- you're expecting to write much more data to the tape than is actually being written. If that's correct, then there's a couple things I can think of: 1) Your tape drive isn't doing hardware compression. Check the manual and see if there are any dip switches you need to set. (Make a note of how they're set before you change anything, so you can go back to what you had originally!). When you say the result is the same, if it used exactly the same number of tapes (down to the decimal point) then that definitely suggests that your tape drive is not compressing. 2) The data you're writing to the tape is already mostly compressed, so you won't fit as much as you might if it were uncompressed data. Also, the 40Gb per tape that you quote is, I think, the MAXIMUM amount of data the tape will take. It's only 20Gb native. 40Gb is how much will fit at optimum compression, which you never get. It's unlikely to be a FreeBSD problem because I regularly fit 6-7Gb on a DDS-2, which has a native size of 4Gb. I use dump options like the ones in my last message. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Backup on DDS-4 tapes
Ludo Koren wrote: # /sbin/dump -Lu0 -B 41943040 -C 32 -f /dev/sa0 /usr I would guess that your tape drive does hardware compression in which case the amount of data which fits on a tape is variable. In such a case you can't tell dump how big the tape is -- I haven't used options like -B since 1600bpi reel-to-reel tapes, except in my day you specified how many feet of tape you had :-) from man dump -a ``auto-size''. Bypass all tape length considerations, and enforce writing until an end-of-media indication is returned. This fits best for most modern tape drives. Use of this option is particularly recommended when appending to an existing tape, or using a tape drive with hardware compression (where you can never be sure about the compression ratio). Don't know -L, must be a 5.x thing. Try: /sbin/dump -Lu0 -a -C 32 -f /dev/sa0 /usr I use -b 64 as well. Use cpio/tar at your peril as they may not do devices right and may not understand filesystem flags. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Thunderbird crash
Thanks for the suggestion. However the only other report of Thunderbird problems I could find was someone running latest Xorg on 5.something. So many bus errors and seg faults from an established set of libraries like XFree seems unlikely to me. Why thunderbird and not mozilla or gimp or any other X app? As to CFLAGS etc, I don't set anything, I'm just compiling the port as it comes. Since no-one else has suggested anything I guess I'll have to try recompiling with debugging and without optimisation and see if I can track anything down. Time permitting :-( Jason Henson wrote: The default xserver is now xorg. Other than that do you have any CFLAGS or CXXFLAGS set you shouldn't. From my experience you should not use any, especially -f*. On 03/04/05 07:52:39, Alex Zbyslaw wrote: I installed the latest thunderbird port (1.01) to see how it compared to Mozilla Mail. So far I have had three bus errors and a segmentation fault! SO far I haven't even been able to reply to an email. Needless to say, Mozilla Mail does not have this level of problems for me. I imported all my Mozilla setting when I first ran. Anyone have similar problems or suggest how I can figure out what's going on? Running FreeBSD 4.10 and XFree86 4.4. XFree server package is a couple of minor revisions off latest, but everything else (gtk etc) fully up-to-date. -- Phone: +44 131 468 2422 Email: [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Thunderbird crash
I installed the latest thunderbird port (1.01) to see how it compared to Mozilla Mail. So far I have had three bus errors and a segmentation fault! SO far I haven't even been able to reply to an email. Needless to say, Mozilla Mail does not have this level of problems for me. I imported all my Mozilla setting when I first ran. Anyone have similar problems or suggest how I can figure out what's going on? Running FreeBSD 4.10 and XFree86 4.4. XFree server package is a couple of minor revisions off latest, but everything else (gtk etc) fully up-to-date. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with mount_ntfs
When I try from to mount ntfs partition via commands: mount_ntfs /dev/ad0s1 / mnt or mount -t ntfs /dev/ad0s1 /mnt I get a messege: mount_ntfs: vfsload(ntfs): File exists What does this mean, and what i'll do next? How I can to get access to NTFS partition my hard drive? It's a while since I had to mount an ntfs, so I hope this isn't wasting your time... But are you using an incomplete description of the partition you want to mount? I'd have expected it to be more like: #mount -t ntfs /dev/ad0s1e /mnt The mount line looks perfectly correct to me. The last part of the name you are adding are slices which are what FBSD uses to divide up a partition. They are not relevant to NTFS. I tried a couple of different possible error scenarios -- mounting NTFS over already mounted partition and mounting the NTFS twice -- but neither generated the error the original sender is getting. Just to double-check the mount line, mine looks like /sbin/mount_ntfs /dev/ad1s1 /windows One thing I can suggest is that you run scandisk (from Windows!) over the NTFS partition, even if it us brand new. I had bizarre error from PartitionMagic on my new PC when I tried slicing off some of the NTFS partition and it turned out that there were some errors which scandisk fixed up. Final thought, it is an NTFS partition you are mounting and not a FAT16 or FAT32 one? Obvious I know, but sometimes it is the obvious! --Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with mount_ntfs
Jerry McAllister wrote: The last part of the name you are adding are slices which are what FBSD uses to divide up a partition. They are not relevant to NTFS. Just a little side terminology snit here. The 'e' refers to a _partition_ which FreeBSD uses to divide up _slices_ 's1' rather than the other way around. I knew that :-) Fingers faster than brain on this occasion... --Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuring IP address aliasing
Mike wrote: # ifconfig -a ed0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.1.40 netmask 0xff00 broadcast 192.168.1.255 # ifconfig ed0 alias 192.168.1.41 netmask 255.255.255.0 broadcast 192.168.1.255 ifconfig: ioctl (SIOCAIFADDR): File exists [using same netmask as real interface] However, THIS WORKED: # ifconfig ed0 alias 192.168.1.41 netmask 255.255.255.255 broadcast 192.168.1.255 [using a netmask of 255.255.255.255] QUESTION: Why do I use a different netmask (255.255.255.255) for a IP alias on FreeBSD? Why isn't 255.255.255.0 used? From the ifconfig man page on 4.9 alias Establish an additional network address for this interface. This is sometimes useful when changing network numbers, and one wishes to accept packets addressed to the old interface. If the address is on the same subnet as the first network address for this interface, a non-conflicting netmask must be given. Usually 0x is most appropriate. Since 192.168.1.41 is on the same subnet as 92.168.1.40 you must use 0x (aka 255.255.255.255) as the netmask. (I don't know *why* I'm afraid). You could always stick the alias on a different subnet at which point you can use the netmask you expect. e.g. # ifconfig ed0 alias 192.168.2.40 netmask 255.255.255.0 broadcast 192.168.2.255 --Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw/nated stateful rules example
Micheal Patterson wrote: Whereas what I'm doing Private LAN Keep-State NAT World is not secure and would not be accepted by a security professional? How do you figure that either method is more or less secure than the other? If stateful is breached in either method, the underlying network is compromised. Sorry, it's late and I may be missing something but I just don't see it. I haven't checked your specific example, but in theory is nothing wrong with this at all. One of my examples works the same way. Packets you didn't ask for don't get through. How much more security can you want? As for breaching the dynamic rules you would, I think, have to spoof at least the target IP and probably more, in which case any firewall could succumb. Personally, I am filing away the various example for future use, and calling this topic closed. Thanks to everyone who posted solutions. I for one am grateful. --Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: arp problem in /var/log/messages
Bjoern A. Zeeb wrote: On Tue, 20 Jan 2004, Mark wrote: But what causes them ? I get them too. I believe CISCO routers do this. I had a reference once but lost it. In my case the routers are somewhere on my ISPs network. --Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw/nated stateful rules example
Ken Bolingbroke wrote:
I just jumped in the middle here, so I may be out of context.
But, stateful rules don't play nice with NAT.
You're quite right, they don't play nice at all.
[EMAIL PROTECTED] wrote:
I disagree with you that the /etc/rc.firewall is the best example.
It's really a good example of stateless rules, how to use
scripting Symbolic substitution.
I found it OK for stateful rules, as long as you don't use natd! I couldn't
find any examples *anywhere* of how to get it to work.
So I posted on a newsgroup a while back and got a working idea (see below) and
in the meantime came up with one of my own. I found it really helpful to draw
a little picture of the gateway machine and its interfaces and trace how
packets went out including the natd in the middle. When working with natd you
really do have to consider packets that come in/out your *internal* network
interface. Without natd you can effectively ignore them (which all examples do).
Note that in a standard setup it's a little more complicated since packets
that come in from the local network get nat'ed whereas packets originating
from the gateway machine don't. Anyway, here's my final message on the topic
which contains two ways you might go. I have extensively traced the packets
on the second, less elegant solution and it really does work.
Michael Sierchio wrote:
Alex wrote:
The basic thrust of the problematic section is:
ipfw add divert natd all from any to any via external_interface
ipfw add pass udp from any to any ntp out xmit external_interface
ipfw add pass udp from any ntp to any ntp in recv external_interface
Try this:
# local rules for this gateway's traffic (hope DF is set for UDP)
ipfw add allow udp from me to any out xmit $ext_if keep-state
# divert
ipfw add divert natd ip from any to any via $ext_if
# this rule looks a bit strange here, but it's to allow the
# nat-ed packets outbound to leave. If you're concerned about
# egress filtering from the gateway itself, add appropriate
# non-stateful allow rules
ipfw add allow ip from me to any out xmit $ext_if
ipfw add check-state
ipfw add allow udp from any to any in recv $int_if keep_state
Putting the keep-state on the internal ethernet is a neat solution, thanks. (It conflicts somewhat with some of the way my firewall is set up prior to the ntp/natd stuff, but I'm looking at rewriting that).
I did think of one more solution which works on the external interface only, but it's not as elegant.
# Check all inbound ntp calls
ipfw add skipto 20500 udp from any ntp to any in recv $ext_if
# Checks all outbound ntp calls and (by dynamic rule) all inbound ntp calls
ipfw add skipto 2 udp from any to any out xmit $ext_if keep-state
[ rest of firewall including natd go here ]
# Make sure we do not fall through into special rulesets
add deny log all from any to any
# Only get to these rules in two circumstances:
# 1) Any outbound ntp packet which has been keep-state'ed
# 2) Any inbound ntp packet which matched a dynamic rule
ipfw add 2 divert natd all from any to any out xmit $ext_if
ipfw add allow udp from any ntp to any in recv $ext_if
ipfw add allow udp from any to any ntp out xmit $ext_if
ipfw add deny log all from any to any
# Only get here on an incoming ntp packet. Need to see
# if we want to accept it or not. Check-state will
# trigger dynamic rule and skipto 2 on match
ipfw add 20500 divert natd all from any to any in recv ${ext_if}
ipfw add check-state
ipfw add deny log all from any to any
--Alex
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw/nated stateful rules example
fbsd_user wrote: The conclusion so far is that ipfw1 and ipfw2 using keep-state rules on the interface facing the public internet with divert/nated does not work period. Probably my post hasn't reached you yet. I think you are mistaken if you mean that keep-state rules cannot be securely used in a NAT configuration -- see two examples in my post. The mistake I believe you are making is in talking about only the public-internet facing interface. What you are trying to do is to ensure that *conversations* from anywhere on your internal network can be keep-stated when talking to the external network. But the packets *start* on the internal facing interface. It just so happens that without NAT you can ignore this bit of the conversation, but once you include it, you cannot. In any case, my somewhat messy example which puts the keep-state on a skipto rule still manages without *looking* at the internal interface, though it does take into consideration the whole conversation. Still would like to be proved wrong on my conclusion. If you find any bugs in the two alternatives I posted then I would love to know. --Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fatal trap 12
Daren Desjardins wrote: Over the weekend my bsd 4.9 apparantly rebooted for kicks by itself, reporting a fatal trap 12 in messages. I looked through the list history and found some posts indicating it may be a memory issue. If you suspect a memory problem, then try getting your BIOS to find it. Reboot your machine then press whatever key you need to get into your BIOS. Look for an option which turns on extended memory checking on boot (or which turns off quick memory checking), turn on extended check, save the setting, reboot and watch the BIOS cycle through endless memory checks. If it finds a problem it'll tell you. If it does, then you'll have to try removing memory chips one-by-one to try to find the one at fault. (Note that motherboards often (always?) require the memory chips to be inserted sequentially. I.e. if you take out the first chip, you have to move all the others up -- you can't just leave the first slot empty). Make sure to use some kind of anti-static protection when handling memory chips, otherwise you really will have a memory problem. --Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
