Re: Using any network interface whatsoever (solution?)
Mike Meyer wrote: In <[EMAIL PROTECTED]>, Darren Pilgrim <[EMAIL PROTECTED]> typed: >> If you add something to /etc/rc.d so that a sh-ified version of this script runs after all interfaces have attached but before any numbering or cloning takes place you can have lines like this in /etc/rc.conf: ifconfig_PublicLAN="inet a.b.c.d/24" That's far better than trying to remember what's on em0. That's certainly true. But is there an advantage to tieing the PublicLAN name to a MAC address as opposed to em0? The network interface name the user sees becomes tied directly to the physical device by way of a unique, configuration-independent identifier. The probe order and driver name become transparent to the network configuration. You could test two different drivers on the same hardware and you wouldn't have to duplicate or modify your ifconfig lines in /etc/rc.conf, just run: /etc/rc.d/netif stop PublicLAN kldunload olddriver kldload newdriver /etc/rc.d/netif start PublicLAN Within the currently available capabilities, we get the network interface equivalent of disk volume labels. [ Proposed use of PCI addresses instead of MAC addresses. ] The real problem with what I proposed is that you have to arrange to search config information for things that may not be tied to a pci bus. That could get real messy. Right, it doesn't scale to ISA or USB devices. The prior probably isn't a big deal these days, but I imagine compatibility with USB devices is fairly important. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Net::FTPSSL error
In the last episode (Apr 08), Ashok Shrestha said:
> Adding freebsd-hackers@freebsd.org
>
> On 4/8/06, Ashok Shrestha <[EMAIL PROTECTED]> wrote:
> > I'm trying to use Net::FTPSSL to connect to an FTP server via SSL.
> > Here is the script:
> >
> > #!/usr/bin/perl -w
> >
> > use Net::FTPSSL;
> >
> > my $ftps = Net::FTPSSL->new('127.0.0.1',
> > 'Encryption' => 'E',
> > 'Debug' => 1,
> > 'Timeout' => 20)
> > or die "Can't open 127.0.0.1";
> >
> > $ftps->login('username123', 'password123') or die "Can't login: ",
> > $ftps->$last_message();
> >
> > $ftps->cwd("/working") or die "Can't change directory: ",
> > $ftps->last_message;
> >
> > $ftps->get("C13.txt") or die "Can't get file: ", $ftps->last_message;
> >
> > $ftps->quit();
> >
> > Here is my error:
> > ./test_FTPSSL.pl
> > Name "main::last_message" used only once: possible typo at
> > ./test_FTPSSL.pl line 11.
> > >>> USER username123
> > <<< 331 Please specify the password.
> > >>> PASS password123
> > Use of uninitialized value in length at (eval 7) line 1.
> > Use of uninitialized value in string eq at blib/lib/Net/SSLeay.pm
> > (autosplit into blib/lib/auto/Net/S
> >
> > SLeay/ssl_read_all.al) line 1615.
> > Can't read on socket: at ./test_FTPSSL.pl line 11
I don't know any perl, but why is your test script printing an error
message ("Can't read on socket") that's not in the source you pasted, and
does the warning "Name "main::last_message" used only once: possible typo at
./test_FTPSSL.pl line 11" have anything to do with it?
--
Dan Nelson
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using any network interface whatsoever (solution?)
In <[EMAIL PROTECTED]>, Darren Pilgrim <[EMAIL PROTECTED]> typed: > Mike Meyer wrote: > > In <[EMAIL PROTECTED]>, David Taylor <[EMAIL PROTECTED]> typed: > >> That doesn't quite work, though. Unless you require everyone wanting > >> to distinguish between LAN and WAN interfaces uses different types > >> of hardware for each card, they'll still end up with xl0 and xl1 > >> (or whatever), which is in no way better than eth0 and eth1, > > > > You're right - but at least you have the option of using different > > types of cards to get different names. I agree that this sucks, but > > it's better than nothing. > > This is a script to rename interfaces based on the MAC address: Very nice. > If you add something to /etc/rc.d so that a sh-ified version of this script > runs after all interfaces have attached but before any numbering or cloning > takes place you can have lines like this in /etc/rc.conf: > > ifconfig_PublicLAN="inet a.b.c.d/24" > > That's far better than trying to remember what's on em0. That's certainly true. But is there an advantage to tieing the PublicLAN name to a MAC address as opposed to em0? > Comments please! This is certainly a move in the right direction. However, MAC addresses are of about the same order of obscurity as device probe order numbers. It might be more usefull to do something like: ifn_list=/etc/NETIF_list for ifn in $(ifconfig -l link) do ifn_addr=$(pciconf -l | grep "^$ifn" | sed -e 's/[EMAIL PROTECTED]@//' -e 's/: .*//') ifn_name=$(grep $ifn_addr $ifn_list | cut -d ' ' -f 2$) ifconfig $ifn name $ifn_name done This way, the name would be tied to the slot on the backplane that the device is plugged into. If you changed the card in that slot, it'd still get the same name, even if it was a different card type. That seems like desirable behavior to me, but I can also see cases where the name should follow the card if it moves to a different slot, which is what your version does. The real problem with what I proposed is that you have to arrange to search config information for things that may not be tied to a pci bus. That could get real messy. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using any network interface whatsoever
In <[EMAIL PROTECTED]>, Dima Dorfman <[EMAIL PROTECTED]> typed: > Mike Meyer <[EMAIL PROTECTED]> wrote: > > What do I want for that? I identify ethernet boards by which slot on > > the back of the system I plug the cable into. Currently, I have to map > > that to board types to and which board is plugged into which slot to > > know which name to use. I want a name that tells me which slot I plug > > a cable in to plug it into that interface. > Is information about the slot even available on a PC? For something like this: The BIOS seems to get that information from somewhere. But I'm not a hardware guru, so I can't say for sure. > : [EMAIL PROTECTED]:7:0: class=0x02 card=0x016d1028 chip=0x10768086 > rev=0x05 hdr=0x00 > : vendor = 'Intel Corporation' > : device = '82547EI Gigabit Ethernet Controller' > : class= network > : subclass = ethernet > > would you consider eth-6-7-0 to be an improvement over em0? Not really, because the magic numbers aren't tied to anything real. You want the magic numbers to corrspond to the physical objects you manipulate. For disk devices, the numbers were originally tied to bus ids, which were set on the device. ra's had swappable plugs with the drive number on them and a light behind the plug, so /dev/ra3 referred to the drive in the rack of 16 drives with the number "3" in the front panel lights. > It has the advantage of not changing if another card is added to the > system, but it's not very informative. For a system that has only nn> its two on-board NICs, "em0" and "em1" are very obvious--at least > it's clear which one corresponds to the label "eth 0" on the > chassis. I'll have to take your word for that, as I haven't got a box handy with two onboard NICs. Is there anything that says we can't have multiple names for an interface? If we do that, then we could (random brainstorming here): Have a name like eth-pci-slot-3 (it's an ethernet device on a pci bus at slot 3), eth-pci-onboard-0 (onboard ethernet port 0) or eth-usb-2 (for the usb-ethernet dongles). The class part - "eth" - is redundant, as the rest of the name identifies the device exactly, but it helps prevent errors, as you get "no such device" errors instead of trying to do something completely inappropriate to a device. This is what you'd use on systems with multiple identical devices. All network devices also get a name of the form net0, net1, This is for systems with just one network interface - no matter what kind it is - which can just refer to "net0" and get the one and only network interface. All network devices also get a name corresponding to the media, so you'd have eth0, eth1, or fw0, fw1 (firewire), meaning that if you specifically want an ethernet - as opposed to an arbitrary network interface - you'd use eth0 instead of net0. This allows you to use eth0, fw0 and wifi0 for the ethernet, firewire and wifi network interfaces on a modern laptop, without having to worry about which net# device map to which of those devices. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: unable to SSH using Net::SSH::Perl
Adding freebsd-hackers@freebsd.org
On 4/8/06, Ashok Shrestha <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> System Info:
> FreeBSD 6.0-RELEASE
> p5-Net-SSH-Perl-1.30
> perl-5.8.7
>
>
>
> I'm trying to use Net::SSH::Perl to connect to an SSH server.
>
>
>
> Here is the script:
>
>
> #!/usr/bin/perl -w
>
> # test.pl
>
> use Net::SSH::Perl;
>
> my $ssh = Net::SSH::Perl->new("10.0.0.243", 'debug' => '1');
> $ssh->login("username", "password");
>
>
>
> Here is my error:
> ./test.pl
> Reading configuration data /root/.ssh/config
> Reading configuration data /etc/ssh_config
> Allocated local port 1023.
> Connecting to 10.0.0.243, port 22.
> Remote version string: SSH-2.0-OpenSSH_3.8.1p1 FreeBSD-20040419
>
> Remote protocol version 2.0, remote software version OpenSSH_3.8.1p1
> FreeBSD-20040419
> Net::SSH::Perl Version 1.30, protocol version 2.0.
> No compat match: OpenSSH_3.8.1p1 FreeBSD-20040419.
> Connection established.
> Sent key-exchange init (KEXINIT), wait response.
> Algorithms, c->s: 3des-cbc hmac-sha1 none
> Algorithms, s->c: 3des-cbc hmac-sha1 none
> Entering Diffie-Hellman Group 1 key exchange.
> Sent DH public key, waiting for reply.
> Received host key, type 'ssh-dss'.
> Host '10.0.0.243' is known and matches the host key.
> Computing shared secret key.
> Verifying server signature.
> Waiting for NEWKEYS message.
> Enabling incoming encryption/MAC/compression.
> Send NEWKEYS, enable outgoing encryption/MAC/compression.
> Sending request for user-authentication service.
> Service accepted: ssh-userauth.
> Trying empty user-authentication request.
> Authentication methods that can continue: publickey,keyboard-interactive.
> Next method to try is publickey.
> Trying pubkey authentication with key file '/root/.ssh/id_rsa'
> Authentication methods that can continue: publickey,keyboard-interactive.
> Next method to try is publickey.
> Permission denied at ./test_SSH.pl line 8
>
>
>
>
>
>
>
> Here is the relevant portion of my /root/.ssh/config
>
> # Host *
> # ForwardAgent no
> # ForwardX11 no
> # RhostsRSAAuthentication no
> # RSAAuthentication yes
> # PasswordAuthentication yes
> # HostbasedAuthentication no
> # BatchMode no
> # CheckHostIP no
> # AddressFamily any
> # ConnectTimeout 0
> # StrictHostKeyChecking ask
> # IdentityFile ~/.ssh/identity
> IdentityFile ~/.ssh/id_rsa
> # IdentityFile ~/.ssh/id_dsa
> # Port 22
> # Protocol 2,1
> # Cipher 3des
> # Ciphers
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
> # EscapeChar ~
> # VersionAddendum FreeBSD-20050903
>
>
>
>
>
>
>
> Any ideas what I'm doing incorrect?
>
>
> --
> Ashok Shrestha
>
--
Ashok Shrestha
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Net::FTPSSL error
Adding freebsd-hackers@freebsd.org
On 4/8/06, Ashok Shrestha <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> System Info:
> FreeBSD 6.0-RELEASE
> bsdpan-Net-FTPSSL-0.04
> p5-Net-SSLeay-1.30_1
> perl-5.8.7
>
>
>
> I'm trying to use Net::FTPSSL to connect to an FTP server via SSL.
>
>
>
> Here is the script:
>
> #!/usr/bin/perl -w
>
> use Net::FTPSSL;
>
> my $ftps = Net::FTPSSL->new('127.0.0.1',
> 'Encryption' => 'E',
> 'Debug' => 1,
> 'Timeout' => 20)
> or die "Can't open 127.0.0.1";
>
> $ftps->login('username123', 'password123') or die "Can't login: ",
> $ftps->$last_message();
>
> $ftps->cwd("/working") or die "Can't change directory: ",
> $ftps->last_message;
>
> $ftps->get("C13.txt") or die "Can't get file: ", $ftps->last_message;
>
> $ftps->quit();
>
>
>
>
> Here is my error:
> ./test_FTPSSL.pl
> Name "main::last_message" used only once: possible typo at
> ./test_FTPSSL.pl line 11.
> >>> USER username123
> <<< 331 Please specify the password.
> >>> PASS password123
> Use of uninitialized value in length at (eval 7) line 1.
> Use of uninitialized value in string eq at blib/lib/Net/SSLeay.pm
> (autosplit into blib/lib/auto/Net/S
>
> SLeay/ssl_read_all.al) line 1615.
> Can't read on socket: at ./test_FTPSSL.pl line 11
>
>
>
>
>
> Are there any relevant conf files I should post? Any ideas how to
> resolve this issue?
>
>
>
>
>
>
> -- Ashok Shrestha
>
--
Ashok Shrestha
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using any network interface whatsoever
In <[EMAIL PROTECTED]>, Daniel Rock <[EMAIL PROTECTED]> typed: > So I doubt that the overwriting of an Ingres database really > happened in Solaris, like some other poster described - unless the > administrator fiddled with /etc/path_to_inst by hand (you are free > to shoot in your own foot). That happened very early in the life of Solaris, in the early 90s. Persistent numbering was added to Solaris in response to this incident (there were probably others as well). This was on a relatively large server, with something like 4 SCSI buses. A drive was added to a previously unused bus, making it appear "between" two drives that were already in the system. This gave all the drives further on in the probe sequence a device number one higher than they had previously had. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using any network interface whatsoever
Scott Long schrieb: Ceri Davies wrote: On Sat, Apr 08, 2006 at 08:34:30AM -0600, Scott Long wrote: Well, the real question is why we force the details of driver names onto users. Network and storage drivers are especially guilty of this, but tty devices also are annoying. How do you know which manual page to read for driver specifics if they are all named eth0, eth1, ... With the current naming scheme you know when to read the man page for em(4), fxp(4), nve(4), ... I'll say again, how does having em0, em1, em2, and em3 help me know what is going on with each of those interfaces? FreeBSD doesn't support persistent instance numbering, unlike Solaris. If you unplug device em0 in FreeBSD the remaining interfaces get renamed em0, em1, em2 - which is a bad thing. If you unplug e1000g0 in Solaris the remaining interfaces will still be named e1000g1, e1000g2, e1000g3. So I doubt that the overwriting of an Ingres database really happened in Solaris, like some other poster described - unless the administrator fiddled with /etc/path_to_inst by hand (you are free to shoot in your own foot). Daniel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Kernel Quality?
Scott Long writes: > >When you say "user application code", is this an alias for > > ports or do you mean non-ported applications? > > "user application code" == code not in src/sys/... That means > src/lib, src/bin, src/sbin, src/usr.bin, etc. Got it. Thanks. Robert Huff ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using any network interface whatsoever
Mike Meyer <[EMAIL PROTECTED]> wrote: > What do I want for that? I identify ethernet boards by which slot on > the back of the system I plug the cable into. Currently, I have to map > that to board types to and which board is plugged into which slot to > know which name to use. I want a name that tells me which slot I plug > a cable in to plug it into that interface. Is information about the slot even available on a PC? For something like this: : [EMAIL PROTECTED]:7:0: class=0x02 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 : vendor = 'Intel Corporation' : device = '82547EI Gigabit Ethernet Controller' : class= network : subclass = ethernet would you consider eth-6-7-0 to be an improvement over em0? It has the advantage of not changing if another card is added to the system, but it's not very informative. For a system that has only its two on-board NICs, "em0" and "em1" are very obvious--at least it's clear which one corresponds to the label "eth 0" on the chassis. pgp4Fog3jMEng.pgp Description: PGP signature
Re: Using any network interface whatsoever (solution?)
Mike Meyer wrote: In <[EMAIL PROTECTED]>, David Taylor <[EMAIL PROTECTED]> typed: That doesn't quite work, though. Unless you require everyone wanting to distinguish between LAN and WAN interfaces uses different types of hardware for each card, they'll still end up with xl0 and xl1 (or whatever), which is in no way better than eth0 and eth1, You're right - but at least you have the option of using different types of cards to get different names. I agree that this sucks, but it's better than nothing. This is a script to rename interfaces based on the MAC address: #!/bin/csh set mac_list = "/etc/MACaddr_list" foreach ifn ( `ifconfig -l link` ) set ifn_mac = "`ifconfig $ifn link | grep ether | cut -d ' ' -f 2`" set ifn_name = "`grep $ifn_mac $mac_list | cut -d ' ' -f 2`" ifconfig $ifn name $ifn_name end Where /etc/MACaddr_list contains entries of the format: 00:00:00:00:00:00 NameLengthMax15 If you add something to /etc/rc.d so that a sh-ified version of this script runs after all interfaces have attached but before any numbering or cloning takes place you can have lines like this in /etc/rc.conf: ifconfig_PublicLAN="inet a.b.c.d/24" That's far better than trying to remember what's on em0. This is an off-the-top-of-my-head, 2-minute solution, largely untested due to present lack of a victim machine. pf doesn't seem to have any issue, but I haven't tested /etc/rc.d/netif, dhclient, wpa_supplicant, interface cloning and other things people do to their network interfaces. An rc-friendly version would probably make use of something like: ifconfig_UsefulName_linkaddr="00:00:00:00:00:00" in /etc/rc.conf rather than a seperate file, but this is just a proof of concept. Comments please! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Kernel Quality?
Robert Huff wrote: Sam Leffler writes: OTOH we've done nothing with user application code and based on the work I've seen done by netbsd there's plenty of stuff to be fixed there. When you say "user application code", is this an alias for ports or do you mean non-ported applications? Robert Huff "user application code" == code not in src/sys/... That means src/lib, src/bin, src/sbin, src/usr.bin, etc. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Kernel Quality?
Sam Leffler writes: > OTOH we've done nothing with user application code and based on > the work I've seen done by netbsd there's plenty of stuff to be > fixed there. When you say "user application code", is this an alias for ports or do you mean non-ported applications? Robert Huff ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using any network interface whatsoever
Ceri Davies wrote: On Sat, Apr 08, 2006 at 08:34:30AM -0600, Scott Long wrote: On Fri, Apr 07, 2006 at 11:53:42PM +0100, Ceri Davies wrote: For the filesystem I can use geom_label and /dev/ufs/UnlikelyString, but I'd also like to have it try to configure whatever interfaces the machine happens to have via DHCP. Other than specifying ifconfig_0="DHCP" once for every possible value of , is there a mechanism to do this already? ifconfig_DEFAULT Well, the real question is why we force the details of driver names onto users. Network and storage drivers are especially guilty of this, but tty devices also are annoying. The current situation on BSD, where I can identify which interface is meant by its type, is definitely preferable to the Linux situation where eth0 may mean something different tomorrow depending on what is plugged in. Since we can rename devices arbitrarily, I don't really see a problem with respect to anything else. Ceri I'll say again, how does having em0, em1, em2, and em3 help me know what is going on with each of those interfaces? Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using any network interface whatsoever
On Sat, Apr 08, 2006 at 08:34:30AM -0600, Scott Long wrote: > >>On Fri, Apr 07, 2006 at 11:53:42PM +0100, Ceri Davies wrote: > >>>For the filesystem I can use geom_label and /dev/ufs/UnlikelyString, but > >>>I'd > >>>also like to have it try to configure whatever interfaces the machine > >>>happens to have via DHCP. > >>> > >>>Other than specifying ifconfig_0="DHCP" once for every possible > >>>value of > >>>, is there a mechanism to do this already? > >> > >>ifconfig_DEFAULT > > Well, the real question is why we force the details of driver names onto > users. Network and storage drivers are especially guilty of this, but > tty devices also are annoying. The current situation on BSD, where I can identify which interface is meant by its type, is definitely preferable to the Linux situation where eth0 may mean something different tomorrow depending on what is plugged in. Since we can rename devices arbitrarily, I don't really see a problem with respect to anything else. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpaF0iZFohHl.pgp Description: PGP signature
Re: Using any network interface whatsoever
In <[EMAIL PROTECTED]>, David Taylor <[EMAIL PROTECTED]> typed: > That doesn't quite work, though. Unless you require everyone wanting > to distinguish between LAN and WAN interfaces uses different types > of hardware for each card, they'll still end up with xl0 and xl1 > (or whatever), which is in no way better than eth0 and eth1, You're right - but at least you have the option of using different types of cards to get different names. I agree that this sucks, but it's better than nothing. I tried to find out how to tell the difference between ethernet interfaces on Linux. Seems that the 2.6 kernel can assign different names to the ethernet devices at each reboot. Um, yeah. Solutions for this problem all seem to involve assigning an arbitrary name based on the MAC address. This has two problems: 1) you have to have a mapping somewhere of mac addresses to cards so you know where to plug in the wan port vs. the lan port. 2) if you replace a dead card with an identical card, your configuration breaks. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using any network interface whatsoever
In <[EMAIL PROTECTED]>, Scott Long <[EMAIL PROTECTED]> typed: > Mike Meyer wrote: > > In <[EMAIL PROTECTED]>, Scott Long <[EMAIL PROTECTED]> typed: > > Please trim the text you are repling to. > Please, I'm tired of arbitrary email etiquette. If you think etiquette is arbitrary, you're sadly mistaken. > > But where do you put the label on an ethernet interface? > It sounds like your message is, "don't be like Linux." No, the message is "don't use solutions we know have serious problems". Having devices names that change when you don't make any changes to the device can cause serious problems. Linux does that for lots of things. FreeBSD does it for some things. > Fine, what do you want instead? How does having 2 em devices in my > system, named em0 and em1, tell me by name which one is connected to > which LAN? It doesn't, any more than having disk0 and disk1 instead of ad0 and da0 tell you which disk has the root file system on it. It's not clear that that particular problem can be solved at the device name layer. It's not clear it should be. For disks, the device name should uniquely identify the drive in the system. Nothing short of changing the drives bus address should change that. Volume labels identify the data on the drive, which is what the user cares about. Letting the users work with what they care about should be the goal. My question about labels for ethernet devices wasn't meant to be rhetorical. Ethernet device names on Unix are pretty much worthless. They tell you basically nothing about which device you've got. On FreeBSD, different card types have different names, which is better than nothing - but that's about all it's better than. We need something akin to labels for ethernet devices. The LAN it's plugged into is the equivalent of the data on the disk - but there's no equivalent for the label. What do I want for that? I identify ethernet boards by which slot on the back of the system I plug the cable into. Currently, I have to map that to board types to and which board is plugged into which slot to know which name to use. I want a name that tells me which slot I plug a cable in to plug it into that interface. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weight of an IRIS 4D/210GTX Box anyone ?
On Saturday, 8 April 2006 at 23:11:59 +0800, Kathy Quinlan wrote: > Hi all, > > I have been offered a IRIS 4D/210GTX SGI box, and I need to know the > rough weight, thought as google did not turn up anything and SGI seem to > disown all the old stuff these days, anyone got any idea on the weight > of this ? There's a photo of my 4D/25 (badged as a Control Data Cyber 910) at the right on the last photo of http://www.lemis.com/grog/old-office.html . I'm not sure how they compare. Greg -- See complete headers for address and phone numbers. pgpHupfkKa4O7.pgp Description: PGP signature
Re: Using any network interface whatsoever
On Sat, 08 Apr 2006, Mike Meyer wrote: > In <[EMAIL PROTECTED]>, Scott Long <[EMAIL PROTECTED]> typed: > > Well, the real question is why we force the details of driver names onto > > users. Network and storage drivers are especially guilty of this, but > > tty devices also are annoying. > > Because Unix has always made the hardware details available to > administrators. Times have changed so that users now need to do things > that used to be restricted to administrators. > > This historical behavior is a *good* thing. If all devices of type > "foo" are just named "foo" and assigned numbers by the system, then I > have no control over the names. If I don't care which is which, this > isn't a problem. If I do care - for instance, I want to distinguish > between the ethernet interface that's on the internet and the one > that's on my LAN, or I want root to be on the disk with the root file > system on it - then this is a PITA, because every time I add hardware > to the system, or re-arrange the cards in the cage, or similar things, > I risk breaking the system configuration. If the device names are > completely determined by the hardware settings, then this doesn't > happen. That doesn't quite work, though. Unless you require everyone wanting to distinguish between LAN and WAN interfaces uses different types of hardware for each card, they'll still end up with xl0 and xl1 (or whatever), which is in no way better than eth0 and eth1, except that it means you have the option of looking up what on earth "xl" actually means to get a vague description of what type of hardware it is, rather than checking the dmesg for xlX or ethX. -- David Taylor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using any network interface whatsoever
...lazy...
Not all problems can be fixed by somebody else. Work a little for a
change.
If you wish to name your interfaces switch to Windows.
ifconfig -a | awk '/^[a-z0-9^]*:/ {i=$1} /inet / {ip=$2;net=$4;}
/status/ {print i" "ip" - "net" - "$2}'
em0: 10.0.1.1 - 0xff00 - active
em1: 69.x.x.x - 0xfff8 - active
em2: 64.x.x.x - 0xfff8 - active
em3: 192.168.3.1 - 0xff00 - active
em4: 206.x.x.x - 0xfff0 - active
Scott Long wrote:
Mike Meyer wrote:
In <[EMAIL PROTECTED]>, Scott Long <[EMAIL PROTECTED]> typed:
Please trim the text you are repling to.
Please, I'm tired of arbitrary email etiquette.
But where do you put the label on an ethernet interface?
It sounds like your message is, "don't be like Linux." Fine, what do
you want instead? How does having 2 em devices in my system, named em0
and em1, tell me by name which one is connected to which LAN?
Scott
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
--
Alain Hebert[EMAIL PROTECTED]
PubNIX Inc.
P.O. Box 175 Beaconsfield, Quebec H9W 5T7
tel 514-990-5911 http://www.pubnix.netfax 514-990-9443
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using any network interface whatsoever
Mike Meyer wrote: In <[EMAIL PROTECTED]>, Scott Long <[EMAIL PROTECTED]> typed: Please trim the text you are repling to. Please, I'm tired of arbitrary email etiquette. But where do you put the label on an ethernet interface? It sounds like your message is, "don't be like Linux." Fine, what do you want instead? How does having 2 em devices in my system, named em0 and em1, tell me by name which one is connected to which LAN? Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using any network interface whatsoever
Mike Meyer wrote: If I do care - for instance, I want to distinguish between the ethernet interface that's on the internet and the one that's on my LAN, or I want root to be on the disk with the root file system on it - then this is a PITA, because every time I add hardware to the system, or re-arrange the cards in the cage, or similar things, I risk breaking the system configuration. If the device names are completely determined by the hardware settings, then this doesn't happen. I wrote some add-on bits for /etc/rc.network in 4.x that compares the link addresses of attached network interfaces to a list of link addresses, then sets ifconfig_ifN* variables accordingly before rc.network does anything. It provides a means of wiring IP addresses to physical ports in a way that gets around the problem of probe order. If there's interest, I'll get to work on an rcNG version. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using any network interface whatsoever
In <[EMAIL PROTECTED]>, Scott Long <[EMAIL PROTECTED]> typed: Please trim the text you are repling to. > You're argument here doesn't really make sense. Only because you're carrying it to ridiculous extremes and misinterpreting it. > Youre' saying that > instead of /dev/da0, we should have > /dev/HITACHI-HUS103073FL3800-SA19-B0T1L0 That's a ridiculous extreme. All I advocated was that we be able to easily identify the devices connected to the system, *not* that we be able identify every device in the world. Sun solved disk device naming back in the 80s. > and instead of em0, it should > be em0-192.168.254.199-24-192.168.254.1-192.168.254.255, right? This is a misinterpretation, because you're including system configuration information (the network it's attached to) in the device description. I'm not aware of a good solution to this problem for ethernet devices. > I'm not saying that we should get rid of the device information. I'm > fully happy making it available to top layer applications. > Administrators definitely need the information to make good decisions. > But the information isn't always needed, and it does make simple > management tasks harder. I think I said that. > It also adds complexity that can lead to > problems. Why when I add a RAID driver do I also need to hack up > sysinstall so that it'll recognise the RAID devices? Missing features in sysinstall would seem to be irrelevant. > The computer should be helping us in administration tasks, not > hiding behind inconsistent and obscure names. All names are obscure when you don't know what they mean. And once you know what they mean, they aren't obscure any more. Which doesn't mean the computer can't help us deal with things. The current BSD device naming and management schemes date back to at least v6. Updating them to deal with modern conditions, as opposed to those that were prevelant in the 70s, is certainly a reasonable thing to suggest. But the Linux solution of smashing all the devices of the same basic type into one flat undistinguished namespace is *not* an improvement. > Now, for your specific case of SCSI, it is possible to wire down device > assignments by the administrator. It's been documented how to do this > in man pages and kernel config files, most recently by me personally, > for years. I know. I figured all this out and documented it when it happened to me years ago (I did say it was a 4.x system). It's still a suprise when adding new hardware breaks the configuration of old hardware on a system as reliable as Unix usually is. I expect that from Windows, but not Unix. > The flaw is that it still requires specific operator intervention to > make work. That's the flaw, all right. The *problem* is that the system was trying to be user-friendly in ill-considered ways. Again, this is the kind of problem I expect to run into with Windows, not Unix. > That's where things like volume labels come > in. Does a sysadmin care about the low-level device name for a drive on > a Windows or Mac system? Does he even know without taking a deep look > inside the system? Does not knowing it make it any less possible to > easily and reliable manage and control the hardware? On the Mac, the answers are "yes", "yes" and "not applicable". On Windows XP, the answers are "yes", "no", and "yes". > It's all done through human-readable labels that are easy to work > with. No, it isn't. *Most* of it is, and probably everything that the casual user runs into. But we're talking about sysadmins, who have to deal with issues like unformatted drives and file systems that don't necessarily have labels. Oddly enough, on the Mac you tend to get things that look like your ridiculous disk name when dealing with these (i.e. "93.2 GB ST9100823A"). > The low level information is still available when needed, but it's > not the primary means of control. I think that's fine; it strikes > the balance between control and ease of use that I'm looking for. Volume labels would certainly solve a lot of issues - even some of the ones I brought up. In particular, if they became the standard way of dealing with devices, then we could unravel some of the more user-friendly-but-expert-hostile designs already in place. But where do you put the label on an ethernet interface? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using any network interface whatsoever
Mike Meyer wrote: In <[EMAIL PROTECTED]>, Scott Long <[EMAIL PROTECTED]> typed: Well, the real question is why we force the details of driver names onto users. Network and storage drivers are especially guilty of this, but tty devices also are annoying. Because Unix has always made the hardware details available to administrators. Times have changed so that users now need to do things that used to be restricted to administrators. This historical behavior is a *good* thing. If all devices of type "foo" are just named "foo" and assigned numbers by the system, then I have no control over the names. If I don't care which is which, this isn't a problem. If I do care - for instance, I want to distinguish between the ethernet interface that's on the internet and the one that's on my LAN, or I want root to be on the disk with the root file system on it - then this is a PITA, because every time I add hardware to the system, or re-arrange the cards in the cage, or similar things, I risk breaking the system configuration. If the device names are completely determined by the hardware settings, then this doesn't happen. Real world examples of this type of breakage include a FreeBSD 4.x system with SCSI disks that failed to boot when a USB mass storage device was plugged into it, and a Solaris system that started swapping on it's Ingres raw database partition after a disk was added. If a system is meant for desktop use where you typically have at most one of anything, then hiding the names from the users is a good thing. In a server environment, where you may have multiple instances of several different device types, then being able to easily tell which is which is a good thing. You're argument here doesn't really make sense. Youre' saying that instead of /dev/da0, we should have /dev/HITACHI-HUS103073FL3800-SA19-B0T1L0, and instead of em0, it should be em0-192.168.254.199-24-192.168.254.1-192.168.254.255, right? That way all the information is present and there is no chance of mixing up devices. I'm not saying that we should get rid of the device information. I'm fully happy making it available to top layer applications. Administrators definitely need the information to make good decisions. But the information isn't always needed, and it does make simple management tasks harder. It also adds complexity that can lead to problems. Why when I add a RAID driver do I also need to hack up sysinstall so that it'll recognise the RAID devices? This is 2006, not 1976! The computer should be helping us in administration tasks, not hiding behind inconsistent and obscure names. Now, for your specific case of SCSI, it is possible to wire down device assignments by the administrator. It's been documented how to do this in man pages and kernel config files, most recently by me personally, for years. The flaw is that it still requires specific operator intervention to make work. That's where things like volume labels come in. Does a sysadmin care about the low-level device name for a drive on a Windows or Mac system? Does he even know without taking a deep look inside the system? Does not knowing it make it any less possible to easily and reliable manage and control the hardware? It's all done through human-readable labels that are easy to work with. The low level information is still available when needed, but it's not the primary means of control. I think that's fine; it strikes the balance between control and ease of use that I'm looking for. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weight of an IRIS 4D/210GTX Box anyone ?
Well, I have 7x4D/20 here (and about 12 working Indy, 6 for spare part (12 R5000), and a bunch of Indigo) The 4D/20 are about 70 pounds (~30 kilos) each. I dont know for the 210GTX but they looked similar. Anybody want a SGI? Free if you pay the shipping. Have fun. Kathy Quinlan wrote: Hi all, I have been offered a IRIS 4D/210GTX SGI box, and I need to know the rough weight, thought as google did not turn up anything and SGI seem to disown all the old stuff these days, anyone got any idea on the weight of this ? Regards, Kat. -- Alain Hebert[EMAIL PROTECTED] PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.netfax 514-990-9443 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using any network interface whatsoever
In <[EMAIL PROTECTED]>, Scott Long <[EMAIL PROTECTED]> typed: > Well, the real question is why we force the details of driver names onto > users. Network and storage drivers are especially guilty of this, but > tty devices also are annoying. Because Unix has always made the hardware details available to administrators. Times have changed so that users now need to do things that used to be restricted to administrators. This historical behavior is a *good* thing. If all devices of type "foo" are just named "foo" and assigned numbers by the system, then I have no control over the names. If I don't care which is which, this isn't a problem. If I do care - for instance, I want to distinguish between the ethernet interface that's on the internet and the one that's on my LAN, or I want root to be on the disk with the root file system on it - then this is a PITA, because every time I add hardware to the system, or re-arrange the cards in the cage, or similar things, I risk breaking the system configuration. If the device names are completely determined by the hardware settings, then this doesn't happen. Real world examples of this type of breakage include a FreeBSD 4.x system with SCSI disks that failed to boot when a USB mass storage device was plugged into it, and a Solaris system that started swapping on it's Ingres raw database partition after a disk was added. If a system is meant for desktop use where you typically have at most one of anything, then hiding the names from the users is a good thing. In a server environment, where you may have multiple instances of several different device types, then being able to easily tell which is which is a good thing. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Weight of an IRIS 4D/210GTX Box anyone ?
Hi all, I have been offered a IRIS 4D/210GTX SGI box, and I need to know the rough weight, thought as google did not turn up anything and SGI seem to disown all the old stuff these days, anyone got any idea on the weight of this ? Regards, Kat. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.0/304 - Release Date: 7/04/2006 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using any network interface whatsoever
Ceri Davies wrote: On Fri, Apr 07, 2006 at 03:57:42PM -0700, Brooks Davis wrote: On Fri, Apr 07, 2006 at 11:53:42PM +0100, Ceri Davies wrote: I'm trying to configure a bootable image to be used in various situations and on various (mostly unknown) hardware. For the filesystem I can use geom_label and /dev/ufs/UnlikelyString, but I'd also like to have it try to configure whatever interfaces the machine happens to have via DHCP. Other than specifying ifconfig_0="DHCP" once for every possible value of , is there a mechanism to do this already? ifconfig_DEFAULT Superb, thank you! If you have non-Ethernet-like interfaces compiled in, you will probably want create empty "ifconfig_" variables for them since DHCP won't work very well there. :) Good point, thanks again :) Ceri Well, the real question is why we force the details of driver names onto users. Network and storage drivers are especially guilty of this, but tty devices also are annoying. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: automatic checking of source code
Divacky Roman wrote: hi I just found http://mygcc.free.fr/ which is a project for automatic checking of source code for bugs (memory leaks, unreleased locks, null pointer dereferences). I recall there was some SoC project to achieve something similar but this is complete and ready to run... it might be of some interest for someone See thread "FreeBSD Kernel Quality?" posted 04/05/06. roman -- www.liberalnistrana.cz ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Regards, Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
