Re: [OpenIndiana-discuss] OI IPv4 Stack setting DF flag on fragmented UDP packets
On 12/04/17 13:01, Markus Wernig wrote: > I switched our DNS from Sol 11.3 to OI illumos-cd964fce75. After that, I > noticed that some reply packets sent by the new server would no longer > get through the firewalls. The reason appears to be that they are > fragmented, but still have the DF (dont-fragment) flag set. This happens > whenever a reply packet is larger than the interface's MTU (1500), which > is easily reached with any DNSSEC enabled query. This is normal behavior for IPv4 in Solaris; it's part of Path MTU Discovery. For IPv6, it's even more strict: intermediate nodes are not supposed to fragment at all -- only the original sender -- so Path MTU Discovery is simply required. The way it's supposed to work is that the DF flag causes any intermediate router that needs to fragment to return a "Fragmentation Needed" ICMP error instead. This error message will have the restricted MTU in it, and the OS caches this information for the next try. (It's stored in the IRE, which, in this case, is effectively a per-IP-destination cache.) You can turn off Path MTU Discovery (google "disable pmtud"), but it's probably a good idea to find out what's really broken here. Is something filtering ICMP error messages improperly? I don't know of any way for an application (BIND/named in this case) to do anything with the DF bit on Solaris. Linux has a sockopt for this (IP_MTU_DISCOVER) as does AIX (IP_FINDPMTU), but I don't think that Solaris does. I think a better idea is to set up your DNS server to use TCP when it needs to send ridiculously big replies. Using UDP for large messages is just fraught with peril. > Solaris in the same situation also fragments the reply packet, but does > not set the DF flag. That's not the default behavior. The default is to have DF on, at least on the Solaris versions I'm familiar with. (I guess Oracle could have changed this, though I think it would be wrong to do so. Path MTU Discovery is a good thing, not a bad thing.) -- James Carlson 42.703N 71.076W ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Best way to map SAS drives to physical positions
Jeppe Toustrup wrote: > The only way I have found which I can find the order of the drives in > the JBOD along with the above names, without pulling out each drive > and see which one becomes unavailable, is within /etc/path_to_inst, > where I find the following lines: Have you tried "cfgadm -lv"? -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Best way to map SAS drives to physical positions
Jeppe Toustrup wrote: > On Mon, Oct 3, 2011 at 16:00, James Carlson wrote: >> Have you tried "cfgadm -lv"? > > Yes, "cfgadm -lv" does not list the drives connected through SAS, but > "cfgadm -lav" does. The output does however not make me much wiser > than the output I can get from path_to_inst (only lines related to SAS > drives shown): OK. It sounds like what you're looking for is something more like the enclosure lists that luxadm can provide with FC boxes. I don't think that exists, though, with SAS. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] USB wireless network LinkSys WUSB100
Maxim Kondratovich wrote: > Hello, > please help, how to identify driver name for this device? Looks like > this device is recognized but not added to list of my network devices... > I tried to ifconfig usb_mid plumb but looks like it's wrong idea. I don't believe there are any WUSB100 drivers for Solaris / OpenSolaris / OpenIndiana. Someone will have to write or port one. "usb_mid" is the driver that attaches if no vendor/class specific driver is available. It just attaches default drivers to the device, which won't include Ethernet functionality (a somewhat unsettled area of the USB world), but will include the ability to open the device with libusb and communicate from user space. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ce networks and aggregations
Gabriele Bulfon wrote: > Hi, I was trying to use dladm aggr to aggregate 2 networks, but the system > doesn't let me. > So I read ce network driver does not support aggregation with dladm. > Somewhere it talks about Sun Trunking allowing the same stuff with older > cards. > Where can I find it (No Oracle points it out) and make my two cards go > double? Is this on OpenIndiana? If it's on Solaris, you may want Sun Trunking; talk to your local Oracle representative. There was (at least at one point) an alternative Cassini driver that used GLDv3 and was thus usable with dladm. I don't know if that ever saw the light of day, though. Someone on this list or (perhaps) networking-disc...@opensolaris.org may have references. http://sstallion.blogspot.com/2008/04/cassini-emancipation.html A better answer, in my opinion, would be to buy some newer Ethernet cards. Many of them perform better than Cassini anyway. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Static IP configuration problem
Ray Arachelian wrote: > On 10/12/2011 03:23 PM, Lucas Van Tol wrote: >> I think /etc/netmasks is where you would store the netmask? >> >> echo $NETWORK $NETMASK >> /etc/netmasks >> > It is and I was just about to reply to point out that if you forget > this, you can get in trouble since it may pick /8 for a 10.x.x.x > address, or /16 for a 172.15.x.x for example when you might not want it > to. :) netmask should be in the form of 255.255.255.0 for class C. I can't recommend using /etc/netmasks for anything. It's a brutal hack and really doesn't work right for modern CIDR networks. Instead, just specify "address/length" or "name/length" for the address on the interface. In other words, if you would previously have done something like this: # echo 10.1.0.0 255.255.0.0 >> /etc/netmasks # echo 10.1.0.1 > /etc/hostname.foo0 I recommend doing this instead: # echo 10.1.0.1/16 > /etc/hostname.foo0 It's easier, and it has the great benefit that it works right with CIDR netmasks without fuss. Or just use "ipadm" to administer the addresses ... -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ce networks and aggregations
Gabriele Bulfon wrote: > Yes, this is an older Sun sparc machine running Solaris 10, and I'm trying to > make it access > a storage server on OpenIndiana, using two ce aggregated ethernet cards. > I would love to change its cards into GLDv3 ones, but these systems accepts > only few ones, > and I have only ce ones at my disposal at the moment..and spare parts are > a mess today. > Unless someone can suggest me a non Sun GLDV3 ethernet card that will run on > a Sun V240! My memory is getting hazy, but I don't think GLDv3 is an option for Solaris 10. I think you're much better off calling Oracle for support, because I think you're pretty far afield right now ... -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ssh sessions timing out?
Dan Swartzendruber wrote: > No, same LAN. Only thing in between is a gigabit switch. The OI is > actually a virtual machine, and 3 other hosts (linux) are on the same > hypervisor and my win7 workstation can hit them with no issues. Since it's saying it's a network error, you might want to start by tracing packets on the network (using something like wireshark) to figure out which side is initiating the disconnect, and how it's doing so -- whether by FIN or RST. Another thing to check would be system logs. Many kinds of problems can cause a failure like this, including having a duplicate IP address configured somewhere on your network. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] smb keeps failing?
Dan Swartzendruber wrote: > I also did run 'svcs -xv' and there were no errors. It looks like OI's smb > service just decided to say screw it and stop advertising the name :( Is there any chance that this SMB problem and the ssh problem you reported separately are actually both symptoms of underlying network trouble? -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ssh sessions timing out?
Gary Gendel wrote: > Back on topic... My OpenIndiana ssh service seems to take a long time to > connect with a client (long delay before the password prompt is > displayed). It happens most of the time and feels like a network > timeout issue. How can I figure out what it's waiting for? That sounds like a very common (and not Solaris-specific) network symptom: check your reverse (IN PTR) DNS records and/or /etc/hosts, /etc/nsswitch.conf, and /etc/resolv.conf files. The usual reason this happens is that the sshd process (the server) attempts to look up the canonical host name for the incoming connection, and since the address isn't known or the DNS resolver is misconfigured, it takes a long time for the server to give up trying to get a name for the client. The test for this, on the server side, would be to do something like this: % getent hosts 192.168.254.200 ... but replace that address with the address of the client. If that query doesn't return immediately with a useful answer (such as "192.168.254.200 dhcp-200"), that's what's wrong. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ce networks and aggregations
Gabriele Bulfon wrote: > noI don't think I will ever call Oracle for support, this is not > an option. > If I won't find any way to aggregate these two cards, I will more easily > throw away these machines > and change them into x86+OI :) EBay sounds like a good plan B for an over-constrained problem. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ssh sessions timing out?
Dan Swartzendruber wrote: > Yeah, I think that's it. I happened to notice a few minutes ago that when I > ssh to 'nas.druber.com', it is connecting via ipv6 and has the lag. If I > change the putty entry to 10.0.0.4, it connects instantly. I am wondering > now if the ssh issue is also ipv6 related? I now have two ssh sessions > open, one via ipv4 and one via ipv6. I am running wireshark on the ipv4 > only at this point. If the ipv6 one dies, I may retry wireshark on the ipv6 > address... Actually, that sounds like a completely different problem, unrelated to name services. That sounds like IPv6 breakage. Depending on the drivers involved, I remember there being various hardware checksum offload bugs that can cause all sorts of strange-looking problems. Some were IPv6-specific. It might be worthwhile to try rebooting with this in /etc/system: set ip:dohwcksum=0 and, if you're using e1000g, this in /kernel/drv/e1000g.conf: tx_hcksum_enable=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0; lso_enable=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0; I don't trust hardware offload schemes any further than I can throw them. For a minuscule bump in performance, they extract many hours and days of wasted administrative effort. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ssh sessions timing out?
Gary Gendel wrote: > My /etc/resolv.conf should always look like: > > domain genashor.com > nameserver 10.101.1.7 > > Doing this fixed the timeout problem. Is there a way to get dhcpagent > to leave resolv.conf alone, or to trigger my event handler (which > updates the dns cache service and corrects the resolv.conf) when a BOUND > or INFORM message comes in? The dhcpagent(1M) man page has answers for most of this. The parameters controlling dhcpagent are set in /etc/default/dhcpagent. If you set PARAM_REQUEST_LIST to exclude the DHCP bits, then the DHCP client won't ask the server for that information. That may or may not be enough. DHCP servers are free to provide you with data even if you haven't asked for it. For that reason, there's also a PARAM_IGNORE_LIST that can be used to get rid of the DNS gook rather completely. To prevent overwrite, it's sufficient to make sure that 'DNSserv' (type 6) entries are not returned; see /lib/svc/method/net-svc for the mechanism that edits this file. (But do _NOT_ modify that script! Your changes will be nuked on upgrade. It's an internal part of the implementation.) If you want to use an event hook, create a /etc/dhcp/eventhook script. See the dhcpagent(1M) man page for details. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ssh sessions timing out?
Gary Gendel wrote: > Sorry, that was clear as mud... I already have an event handler for > dhcpagent that processes a BOUND or INFORM message, but it doesn't seem > to get triggered when it first starts up (or maybe the overwrite happens > later). So the question is how to prevent dhcpagent from writing the > /etc/resolv.conf file. The overwrite occurs when svc:/network/service:default runs. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ssh sessions timing out?
Dan Swartzendruber wrote: > > The HW offload thing makes no sense for me to leave enabled, since this > is a virtual machine :) Thanks for the tip. Before I go that far, I > think I'll start with just disabling ipv6 and see... Depending on the types of drivers involved, I believe that the hardware offload options can actually tweak real hardware bits. There's often a surprising amount of cooperation going on between a hypervisor and a guest operating system. But, sure, if you're not using it, removing the IPv6 address is a good thing to try. (Note that you'll almost certainly want to leave the IPv6 loopback address alone. The v6 folks do a lot of compatibility testing without external v6 addresses, but not without loopback.) -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ssh sessions timing out?
Dan Swartzendruber wrote: > Okay, now I know what is happening (but not why). I remote desktop to > my home system just now and saw the same abort nonsense. Pulled up the > window with the wireshark capture running. The last N entries were tcp > retransmissions from my win7 box to OI, followed by the expected RST > when no ACK was forthcoming. And this was the ipv6 session - the ipv4 > one is still going strong, so as soon as I have a chance to bounce nwam > after disabling ipv6, that's my next step. That's consistent with a hardware checksum offload mechanism or similar data-garbling scheme. Check "netstat -ni" and "netstat -s" output to see if there are any counters bouncing upwards. (Depending on OS version, there's also "dladm show-link -s" or "dlstat show -h".) Also, depending on the driver, "kstat" may be helpful in getting really low-level diagnostic information. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ssh sessions timing out?
Dan Swartzendruber wrote: > > Okay, I'm stumped. How do I disable ipv6? Google points me at adding > this line to /etc/nwam/llp: > > e1000g0 noipv6 > > So I did, and bounced nwam with 'svcadm restart nwam'. Yet, I still see > this: > > e1000g0: flags=20002004841 mtu 1280 index 4 > inet6 fe80::20c:29ff:fedf:6add/10 > ether 0:c:29:df:6a:dd > e1000g0:1: flags=20002004841 mtu 1280 > index 4 > inet6 2001:470:1f11:1201::12b1/128 e1000g is one of the drivers with known (and long-standing) hardware checksum issues. Did you see the e1000g.conf entries I suggested? The entry you added should certainly do the job. I don't know why it doesn't, and I've been out of touch with the NWAM folks for a long time, so I don't know the current status of it. (Are you even using NWAM?) You can certainly manually remove those entries: ifconfig e1000g0:1 inet6 unplumb ifconfig e1000g0 inet6 unplumb I'd do that and then recycle the 'nwam' service to see if it comes back. If it does, then that sounds like a bug (of some sort) with nwamd. If it doesn't, then it's possible that there's a corner case here (new entries in llp) that nwamd doesn't handle too well. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ssh sessions timing out?
Dan Swartzendruber wrote: > no joy. the manual commands certainly got rid of the two inet6 > entries. bouncing nwam brought them right back. is there something in > the ncp-Automatic.conf file that would accomplish the same effect? i > thought i found something via google, but that sent me to a broken > oracle page :( Dunno. I haven't used NWAM in quite a while. Generally, it just does what it thinks is best, and trying to "tune" its behavior is (at least for me) an exercise in frustration. If you don't like it, disable it, and switch back to manual control. (It's was originally designed primarily for laptops. Yes, quite a few of us at Sun ran Solaris on laptops.) One option might be trying to contact the project team at nwam-disc...@opensolaris.org, or by searching around for the project lead, Renee Sommerfeld (nee Danson). -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ssh sessions timing out?
Dan Swartzendruber wrote: > > James, thanks, I really appreciate the effort here. This is supposed to > be a SAN, not a dev box or anything - I just want it to run stably, and > disabling ipv6 seems to be doing that, so I think I'm going to call it a > day... OK. For what it's worth, I'd *really* recommend updating that e1000g configuration to avoid the known problem areas and switching from NWAM to static configuration for such a system. But it's obviously your call. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] nagios/nrpe?
Dan Swartzendruber wrote: > I monitor a bunch of servers and such on my home system using nagios > (icinga) on a ubuntu VM. Each target has nrpe to handle the network > requests and run the nagios plugins. Has anyone gotten the nrpe/nagios > stuff working on OI? Google hasn't turned up anything useful, I'm > afraid... Nagios itself claims to run on Solaris 9 and better, which should include OpenIndiana. It looks like someone at Sun tweaked the software for OpenSolaris, which would certainly be a better bet, but the links to the packages are all dead; consumed by the Borgacle. http://blogs.oracle.com/drapeau/entry/nagios_is_available_for_opensolaris Perhaps this would be a better starting point: http://gibbontech.blogspot.com/2007/04/compiling-nagios-30a3-and-plugins-for.html -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Aggregation performance measurement
Gabriele Bulfon wrote: > Hi, > I recently could join an old Sun Sparc machine to an OpenIndiana storage, by > adding a couple of > ethernets to the Sparc machine running Solaris 10/08. > The Sparc machine is now connected to the storage switch, LACP capable. > I understand that dladm on Solaris 10 is still different from the OpenIndiana > version, so maybe > the problem I see comes from here. > I created two trunks of two ports each on the switch, connected the Sparc on > one trunk, the storage > on the other trunk, aggregated cards on both machines through dladm, > configured aggr1 on both > machines, verified that machines can see each other. > All four links are up and quiet on the switch, nothing was moving. > So I used "netio" to check network throughput, resulting around 90MB/sec: > strange, this is > less than 1Gb/sec! Is aggregation workgin? There's no way to know based on that. Since performance sounds exceptionally low, I would look for low-level errors first. A fairly common (and unfortunate) cause of low performance like this occurs when a system administrator attempts to "force" Ethernet duplex without fully understanding what "forced" mode means. (When duplex is "forced" on one side of a link, this disables normal autonegotiation, and that causes the other side to drop into the minimum supported configuration; typically half-duplex. If you feel compelled to force Ethernet parameters, you must do it on both sides of the link.) Another common cause is plain old bad cables. Swapping out cables is a good thing to try. Look for errors on the link. Look at kstats. Try running without trunking first to see if you can get decent single-link performance before dealing with the complexity of trunking. There's no reason to reach for a complicated solution if the simple things aren't working right. > So, I started transfering data from the Sparc to the storage via NFS, and > looking at the switch, > I could see one machine working on both ports of his trunk, while the other > one was almost > working on just one port..that is something more than 1Gb/sec!why?? That's not too surprising, depending on how the trunks are configured and what sort of traffic is passing over the links. Standards-compliant Ethernet trunking requires the peers to distribute packets among the links in a way that precludes accidental packet reordering. 802 just doesn't allow reordering. Generally, this means that the peers must hash based on some kind of flow-identifying information. At a minimum, this is usually the MAC addresses. But it can include any other data the peers like, as long as reordering within a flow is precluded. The more information used, and the more individual flows present, the better statistical balance you get. But there are no guarantees in life. Sometimes everything hashes to one link, even if you try hard. Look at the configuration again. How are the trunks set up? What sort of flow identification is used? It is the sender (not recipient) who is responsible for picking the output port used for any given packet, so look at the sending side of the "unbalanced" traffic. Look at the traffic itself. Is there more than one flow in that direction? If no, then seeing it all on one link is perfectly normal and expected. Trunking doesn't just add the two bandwidths together! > So I tried removing the "sleeping" cable, and measured the same throughput > Strangely, I tried removing the "working" cable, and insterted the "sleeping" > one, and still > everything was working on one port, the "sleeping" one became operational. > Added again the second one, and that was become the "sleeping" one > Looks like aggregation is not using all the available throughput......what am > I missing? is there > any incompatibility between Solaris10/08 and OpenIndiana? I don't expect that there should be any. More likely, I expect a misconfiguration somewhere in this set-up. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Mixing zfs raids and mirrors
Gabriele Bulfon wrote: > Hi, > I was wondering what (if any) problems I may encounter by mixing different > zfs strategies on one pool, > with all equal disk sizes. > Examples: > - pool1: raidz1 a0 a1 a2 mirror a3 a4 > - pool2: raidz1 b0 b1 b2 raidz1 b3 b4 b5 mirror b6 b7 > - pool3: mirror c0 c1 mirror c2 c3 raidz c4 c5 c6 > I'm just trying to balance pools performance and maximum space... > Last but not least: > - what if pool3 is actually the rpool (where system just occupies few > GBytes), where I'll add > volumes with quotas to share? Should I keep rpool separate absolutely? > (I just don't want to miss many GB on an rpool that will just stay as it is, > on the boot disks). Last I checked, it wasn't possible to boot off of RAID-Z; only mirrors were supported for boot. As for the other part, the man page says: Virtual devices cannot be nested, so a mirror or raidz vir- tual device can only contain files or disks. Mirrors of mir- rors (or other combinations) are not allowed. If you're looking to boost RAID-Z performance, I'd suggest adding more disks. RAID-Z will effectively stripe the data across the available devices, parallelizing the I/O operations. To get better error tolerance, use raidz2 or raidz3. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] NFS and aggregation
On 10/20/11 06:24, Gabriele Bulfon wrote: > Hi, after reading a lot, I understand that LACP aggregation won't let me run > a single > connection on all the available links, but just allocate one per connection. > So, considering this, and considering one NFS client mounting a share through > an aggregated > path, I was wondering if multiple files usage by the client will be performed > through different > connections so different links. Generally, no. You'll get one connection per peer. > If the algorythm is choosing the link through MAC &or IP, then I suspect I > will still be using > one link all the time from the same client... Yep. If the hashing mechanism allows you to use L4 (transport layer port numbers) discrimination, then you'll get the finest grain distribution possible. But if it's a single TCP connection, that'll still be a single flow. Ethernet trunking works great for high levels of aggregation and (with LACP) as a low-level redundancy mechanism. It doesn't magically make things go faster, though. If you want that, then you'll have to buy faster hardware. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Gernot Wolf wrote: > Ok, for some reason this attachement refuses to go out :( Have to figure > that out... Probably just because it's huge. Try "tail -100 /var/adm/messages". It's likely that if there's something going nuts on your system, there'll be enough log-spam to identify it. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Configuring span ports on oi151
carlopmart wrote: > Is it possible to configure a bridge (with n physical nics) with a span > port like for example FreeBSD does?? No, mirror port functionality does not exist. If you intend to use snoop / tcpdump / wireshark on the span port, then just use the existing monitoring facility. A bridge created with dladm will have an observability node, based on the bridge name. If you create a bridge named "foo", then you can snoop on "foo0" and see all of the packets processed by the bridge. If you're using the span port for some other purpose, then the feature will probably have to be added to the code. It's not present in the current code because the observability node covered the known uses of that sort of port without extra complications. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Configuring span ports on oi151
carlopmart wrote: > On 10/24/2011 06:13 PM, James Carlson wrote: >> carlopmart wrote: >>> Is it possible to configure a bridge (with n physical nics) with a >>> span >>> port like for example FreeBSD does?? >> >> No, mirror port functionality does not exist. >> >> If you intend to use snoop / tcpdump / wireshark on the span port, then >> just use the existing monitoring facility. A bridge created with dladm >> will have an observability node, based on the bridge name. If you >> create a bridge named "foo", then you can snoop on "foo0" and see all of >> the packets processed by the bridge. >> >> If you're using the span port for some other purpose, then the feature >> will probably have to be added to the code. It's not present in the >> current code because the observability node covered the known uses of >> that sort of port without extra complications. >> > > Thanks James. I need to sniff traffic on this bridge, but using it as > port mirror or span port. For example, if I create a bridge with bge0, > bge1, and bge2, I need to "see" all traffic that cross these interfaces, > not only, for example, bge0 ... That's the problem. I'm a little confused, because that's exactly what the existing observability mechanism is for. If you use that existing node (named after the bridge), you'll see all of the traffic processed by the bridge, regardless of the port on which it was received. It's a solved problem. You didn't say how you're sniffing traffic. If you mean that you must use an _external_ network monitoring device to do this, then the existing built-in mechanism obviously won't be sufficient. That'd be a fair reason to add a port mode flag that disables the normal MAC filtering, though it's a little unclear why an external device would be required or desired. In any event, if you're interested in looking into this, the source for the driver itself is in usr/src/uts/common/io/bridge.c. The necessary change, I think, might be to make bridge_forward() treat those "monitor" links as special, or to look for the calls to mac_rx() (the existing observability hooks) and insert special handling there. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Configuring span ports on oi151
Jason J. W. Williams wrote: >> Thanks James. I need to sniff traffic on this bridge, but using it as port >> mirror or span port. For example, if I create a bridge with bge0, bge1, and >> bge2, I need to "see" all traffic that cross these interfaces, not only, for >> example, bge0 ... That's the problem. > > I've always used tcpdump on both Linux and OpenIndiana/Solaris for > that...one session per interface: > > tcpdump -i bge0 -s0 -w /tmp/bge0.pcap & > tcpdump -i bge1 -s0 -w /tmp/bge1.pcap & > tcpdump -i bge2 -s0 -w /tmp/bge2.pcap & You don't need to do that unless you need to keep track of the port on which the packets are seen. If you don't, and you just want a record of all of the traffic, use the existing observability node. A single "tcpdump -i bridgename0 -s0 -w /tmp/bridge.pcap &" should do it. (It'd be nice if the file format[s] were extended to keep track of port as well as inbound/outbound direction and status flags. We had a project in our group to do that back at Sun, but it was never prioritized and thus never finished.) > Are you looking for an easier method? (tcpdump on Linux allows "-i > any" to capture across interfaces but it's not promiscuous capture and > I'm not sure if the Solaris version supports it.) No. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Configuring span ports on oi151
carlopmart wrote: > On 10/24/2011 07:08 PM, James Carlson wrote: >> You didn't say how you're sniffing traffic. If you mean that you must >> use an _external_ network monitoring device to do this, then the >> existing built-in mechanism obviously won't be sufficient. That'd be a >> fair reason to add a port mode flag that disables the normal MAC >> filtering, though it's a little unclear why an external device would be >> required or desired. >> > > Sorry James, for not being properly explained. But yes, I need to use an > external monitoring device. I use an external server with a different > IDS/IPS sensors to process certain type of traffic. For example: exists > one Snort sensor to monitor ftp, smtp, tcp anomalies, etc. Another > Bro-IDS sensor to process ssl traffic. And another suricata sensor to > process http traffic only. All these three sensors are installed in one > server. I see. One solution might be to get those "sensors" to run on the OpenIndiana system. Then they could take advantage of the observability interface to grab the traffic desired. > And it is a lab. not a production system ... The other solutions I can think of (besides adding this feature to the existing code or porting the applications) would be intentionally breaking the bridge_learn() function in bridge.c so that it always returns without updating the forwarding tables, or, alternatively, using an external bridge that has this feature. The latter would be extremely easy, but would cost more money. The former is a bit hackish, but should do the job, and would be fairly easy to do, provided you are able to build kernel modules. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Poor relative performance of SAS over SATA drives
weiliam.hong wrote: > 3. All 4 drives are connected to a single HBA, so I assume the mpt_sas > driver is used. Are SAS and SATA drives handled differently ? I think others have reported poor results from combining these, even though they're "supposed" to work via protocol translation. http://gdamore.blogspot.com/2010/08/why-sas-sata-is-not-such-great-idea.html > This is a test server, so any ideas to try and help me understand > greatly appreciated. I would use the path of least resistance: install two controllers, one dedicated for SATA (if you must have SATA drives), and the other dedicated for SAS. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] inetutils 1.8
Gabriele Bulfon wrote: > Hi, trying to build inetutils 1.8 gives errors: > setsig.c:33: error: syntax error before "setsig" > setsig.c:33: error: syntax error before "sig_t" > Any clue? Google seems to suggest that it could be an unfixed problem in inetutils. http://comments.gmane.org/gmane.comp.gnu.inetutils.bugs/1318 In any event "sig_t" isn't defined on OpenIndiana. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] About auto snapshots
On 10/27/11 18:17, Harry Putnam wrote: > I couldn't find any better way to capture those messages (taking place > on a Virtualbox install of oi 151) than a screen shot so have attached > it below, I hope it is visible enough to read: The messages say that you should run "svcs -xv", and then examine the log files that the system tells you about in the svcs output. What happened when you did that? -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] log messages from failed time-slider daemon
On 10/27/11 18:34, Harry Putnam wrote: > Note that top line about `crontab'. Is that the reason for the > subsequent failures? It appears to be. > What is going on that requires crontab to be read? And what might make > it not open.. permissions? The script this service runs modifies crontab entries (yecch!). Not opening could be due to user modification of the time-slider service itself, bad permissions somewhere, or a read-only file system. Try: ls -ld /var/spool/cron/crontabs df /var/spool/cron/crontabs > Is this the root crontab, or would it be a user crontab?... there is > so little information in the log output its not really possible to > figure much from it. It looks like the root crontab. Something is definitely strange on your system. If you do this: pfexec su - root crontab -l > /tmp/root.cron crontab /tmp/root.cron what happens? -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] e2fsprogs header file bug
On 10/28/11 06:45, Andrey N. Oktyabrski wrote:
> Good day.
>
> In which bug tracker I must create a bug report for this issue?
>
> (Cite from:
> http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=45491)
>
> The problem is that on OI-151 EXT2_IOC_GETFLAGS is defined as
>
>
> _IOR('f', 1, long)
>
>
> where _IOR is defined in drm/drm.h which is not included.
> To me this looks like a bug in OpenIndiana.
At a guess, I suspect that what's going on here is that you have a
/usr/include/ext2/fs.h that's delivered by libparted, and this other
software is "assuming" that if this file is present, then all things in
it must work and it must correspond to a kernel feature.
I think that's a bit of a brash assumption on the part of the author of
that libarchive software. Just because you troll through /usr/include
and find a file there does not automatically mean it'll do what you
think it does -- basically, any package can add a file to that directory
for any reason, not just bona fide parts of the OS.
One thing you could do would be to find out what installed that file,
and then go ask the author of that package whether he thinks he should
be delivering the file:
pkg search -lp /usr/include/ext2/fs.h
My guess, though, is that he's really not at fault here, and that the
fault really lies with the software that is making assumptions about
what those files represent. Writing portable software is harder than
that. Reading through that problem report, though, makes it sound like
those other developers aren't going to agree with me. :-/
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] e2fsprogs header file bug
Andrey N. Oktyabrski wrote:
> On 28.10.11 16:29, James Carlson wrote:
>>> In which bug tracker I must create a bug report for this issue?
>>>
>>> The problem is that on OI-151 EXT2_IOC_GETFLAGS is defined as
>>> _IOR('f', 1, long)
>>> where _IOR is defined in drm/drm.h which is not included.
>>> To me this looks like a bug in OpenIndiana.
>>
>> At a guess, I suspect that what's going on here is that you have a
>> /usr/include/ext2/fs.h that's delivered by libparted, and this other
>> software is "assuming" that if this file is present, then all things in
>> it must work and it must correspond to a kernel feature.
> Where you see the "fs.h"? ext2fs/ext2fs.h
I was diving in libparted because I didn't have ext2fs/ext2fs.h on my
OpenIndiana system. :-/
>> I think that's a bit of a brash assumption on the part of the author of
>> that libarchive software. Just because you troll through /usr/include
>> and find a file there does not automatically mean it'll do what you
>> think it does -- basically, any package can add a file to that directory
>> for any reason, not just bona fide parts of the OS.
> Yes, I agree, but this is a separate bug :-) And this bug is not
> IO-related.
I still disagree that depending purely on the existence of a header file
is the right way to build portable software -- it's likely necessary,
but almost certainly not sufficient. Good luck to the users of that
software, I guess.
>> One thing you could do would be to find out what installed that file,
>> and then go ask the author of that package whether he thinks he should
>> be delivering the file:
>>
>> pkg search -lp /usr/include/ext2/fs.h
> $ pkg search -lp /usr/include/ext2fs/ext2fs.h
> PACKAGE PUBLISHER
> pkg:/system/file-system/e2fsprogs@1.41.14-0.151.1
That doesn't come with the system. It's part of OI-SFE.
Looking over the software, it doesn't look to me like anyone should
assume that if the header files are present, then the kernel bits are
present as well. These programs are for "compatibility" -- specifically
on systems that lack those Linux-specific file systems.
>> My guess, though, is that he's really not at fault here, and that the
>> fault really lies with the software that is making assumptions about
>> what those files represent. Writing portable software is harder than
>> that. Reading through that problem report, though, makes it sound like
>> those other developers aren't going to agree with me. :-/
> I think, if any header file uses some macro, it must include header file
> with definition for this macro. Am I wrong?
To that last question, I'd say "yes."
I can see no need for any requirement that all of the macros defined in
a header file must be usable in all contexts. There are cases where the
macros defined are usable only in certain contexts -- such as when
building a kernel module or when compiling for debug or with certain
optional features.
Yes, I do think that, as a design point, it's a good thing for header
files shipped with the system to be stand-alone, meaning that they can
be compiled successfully without needing prior includes.
But, aside from that, I don't believe it's a requirement that anything
inside is usable by anyone, unless it's actually _documented_ to be
useful. In this case, I can see no documentation related to e2fsprogs
that suggests that including this header file will somehow get you
EXT2FS-related kernel ioctl support.
You might have an argument that e2fsprogs shouldn't include this header
file. Most projects (for what it's worth) just toss in the kitchen sink
-- anything that's built is shipped, even if it's not normally useful
for anyone outside of the project.
Perhaps Ken Mays might have something to say about it.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] e2fsprogs header file bug
Andrey N. Oktyabrski wrote: > On 28.10.11 18:29, James Carlson wrote: >> You might have an argument that e2fsprogs shouldn't include this header >> file. Most projects (for what it's worth) just toss in the kitchen sink >> -- anything that's built is shipped, even if it's not normally useful >> for anyone outside of the project. > Thanks for detailed explanation, you are right. But if you don't want to > give someone something, don't give it. Otherwise it is a cheese in a > mousetrap. If one were malicious, it'd be a way to catch people who write code without reading the documentation. :-/ > Perhaps, it is necessary to remove unusable headers from system? Well, much luck in that. Years ago at Sun, I filed a bug on it, and I had lengthy discussions with some of the senior architects while trying to find a way to address it. I never really did get much agreement on the issue. What I wanted to do was to segregate the documented interfaces (i.e., the things people in other projects _should_ be #including) from the undocumented ones (the things they should never #include) via packaging. That is, you'd have a "normal" /usr/include that gets installed, and a set of "extra" packages containing /usr/include files that you "should not" be using, but that have historically been shipped with the system. It seems like a simple idea, and possibly helpful to keep users on the straight-and-narrow, but: - Many system headers have a wild mix of documented/public interfaces and undocumented/unusable ones. You'd have to separate out these bits first into separate files, likely involving tens of thousands of lines of code churn. - At least at Sun, there were hundreds of obscure groups contributing code to ON all the time. There was simply no feasible way to get all of them to stop contributing unusable bits to /usr/include, so even if you could do this, it'd be a one-off hack. Eventually, new trash would appear. There's no way to make it stay fixed. - Some third-party software (unfortunately!) relies on undocumented and only partially usable bits from /usr/include. Since a lot of people rely on that code, cleansing /usr/include would have little effect -- real users will have to install the "naughty" package containing the "unusable" headers so that they can continue building the software they really want. If everybody installs that, then the work of separating the bits was wasted. I also tried removing headers that were utterly without merit, such as /usr/include/net/af.h. That doesn't do anything on Solaris, and never did. You'd be surprised and dismayed how much crapola like that is strewn in /usr/include. I spent months categorizing stuff, removing garbage, and rewriting mistaken code throughout the system that actually _used_ these _unusable_ headers, but never got to the point of integrating the work. I still have the diffs somewhere if someone wants them. I like cleanliness, so I wouldn't argue against someone making improvements here, but I've been beaten down enough myself. ;-} -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] e2fsprogs header file bug
Andrey N. Oktyabrski wrote: > More about e2fsprogs. Now from the pkgsrc. There is a same bug as here: > http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=45499 > > Is it correct to expect ifr_hwaddr member in ifreq structure if > SIOCGIFHWADDR defined? It might be correct on some platforms. It wouldn't be correct on OpenIndiana, because it doesn't exist on that one. In other words, the application needs to be ported. I believe that ioctl only works on PF_PACKET sockets, and requires the use of sockaddr_ll. See: http://arc.opensolaris.org/caselog/PSARC/2009/232/pfp-psarc.txt -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] e2fsprogs header file bug
Andrey N. Oktyabrski wrote:
> On 03.11.11 16:22, James Carlson wrote:
>> Andrey N. Oktyabrski wrote:
>>> More about e2fsprogs. Now from the pkgsrc. There is a same bug as here:
>>> http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=45499
>>>
>>> Is it correct to expect ifr_hwaddr member in ifreq structure if
>>> SIOCGIFHWADDR defined?
>>
>> It might be correct on some platforms. It wouldn't be correct on
>> OpenIndiana, because it doesn't exist on that one. In other words, the
>> application needs to be ported.
>>
>> I believe that ioctl only works on PF_PACKET sockets, and requires the
>> use of sockaddr_ll. See:
>>
>> http://arc.opensolaris.org/caselog/PSARC/2009/232/pfp-psarc.txt
>
> What solution would be correct?
> 1. Check it in the "configure" stage:
> if ${OPSYS} == "SunOS" then #undef SIOCGIFHWADDR in config.h
>
> In this case the software developers must do it in the "configure" script.
>
> 2. Remove the SIOCGIFHWADDR definition from Illumos/OI headers while it
> don't work.
>
> In this case Illumos/OI developers must correct header files.
I'd say #1. The reason I say that is that (a) the OI header does in
fact work, if you know how to use it, and that other software's failure
to understand how to use it really isn't OI's problem, (b) definition of
that macro does not in fact imply anything about the system, (c) there's
no fundamental system design requirement saying that #defines must be
omitted until the underlying implementation is "perfect" with respect to
some thoroughly arbitrary external reference, and (d) there's really no
standard saying precisely what that #define must do, so there's no
violation of type or conformance.
I do agree that partially implemented "Linux compatibility" things are a
bit of a hazard in general, and that this one in particular is a bit
sad. Taking that failure up with the developer of the feature (not me,
but he's not hard to find) might be interesting.
However, like the last problem with this same unported software posted
on this same list, this new problem exposes a number of fairly clear issues:
1. Non-trivial software needs to be ported in order to run on
different systems. All of us who build software that runs on
multiple systems really do wish it were otherwise, that somehow
standards bodies and market pressure would magically make every
system compatible with another, but we know that in the real
world, that just doesn't work. Porting is work.
As a corollary, software that hasn't been ported, like features
that are never tested, does not work. Period. It doesn't work.
2. Automatic configuration systems (such as, but certainly not
limited to, GNU autoconf) are not magic. Sometimes, in the hands
of skilled and wise developers, they help the process of designing
and then _TESTING_ software that is widely portable. But they're
not pixie dust that can be sprinkled on top in the hope that
somehow a slew of build-time tests combined with a rat's nest of
#ifdefs will make it all work out.
Perhaps more significantly: no automated test can (today at least)
determine what has been documented to work on any given system.
All that it can test is the contents of include files, symbols in
libraries, OS name and version, files/directories, installed
software packages, and, if it tries hard, kernel interfaces. None
of that substitutes in any automated way for an actual developer
reading the flippin' man pages.
3. Not all systems are Linux. Nor are they BSD. Nor are they
Windows. Nor are they Solaris. And so on. Assuming that there's
one special golden reference standard out there that "everyone"
must support is pure folly.
If everything were the same, well, there'd only be one OS in the
world, and I know I'd really be sad if we all had to write code
on Win7.
4. e2fsprogs is not greater in stature than OI. That is to say,
there's no reason I can see that OI should have to change in order
to pave a road for that one software project. Sure, if there are
objective bugs or flaws in OI, and if someone has the time and
ability to repair those things, then that's great, whether it does
or does not help e2fsprogs. But assuming that each
incompatibility between the two is in fact a problem is _either_
is, I think, deeply wrong.
One doesn't go visiting a foreign land and just "assume" the
residents there must speak the one's own language and, if they
don't, then they must be defectiv
Re: [OpenIndiana-discuss] e2fsprogs header file bug
On 11/5/11 5:40 AM, Andrey N. Oktyabrski wrote: > On 04.11.11 14:14, James Carlson wrote: >> I'd say #1. ... > So it is a lot of words in the justification of not to change anything > in the OI/Illumos... That's not entirely true. If someone wants to change OI to make things better for this application, I certainly would not think that's a bad thing. I just don't think it's the same kind of bug that I suspect you do. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] server power cycling at very predictable moments
On 11/4/11 12:18 PM, Daniel Kjar wrote: > The oracle board is down so I thought I would throw this out here... > every two weeks at 3:20AM my x2200 powercycles. > > Oct 7 03:21:44 bio2 genunix: [ID 540533 kern.notice] ^MSunOS Release > 5.10 Version Generic_144501-19 64-bit > Oct 21 03:21:48 bio2 genunix: [ID 540533 kern.notice] ^MSunOS Release > 5.10 Version Generic_147441-03 64-bit > Nov 4 03:21:51 bio2 genunix: [ID 540533 kern.notice] ^MSunOS Release > 5.10 Version Generic_147441-04 64-bit Note that the kernel's version number is changing each time. I suspect this is caused by an automated installer that is enabled on this system. I don't know what they might be calling it these days, but there was a product called "Sun Update Manager" that would do this sort of thing. Since this is S10 (rather than OpenIndiana or even OpenSolaris), you might want to look into that. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] XtreemeFS on Openindiana
Paolo Marcheschi wrote: > Hi > With the help of Michael Berlin from the Project, I built the client, > but now I have some issue with fuse. > The client seems to work, but it fails when it passes control to > fuse: > http://pastie.org/2829843 > > to get more info I trussed it: > http://pastie.org/2829859 Neither seems to reveal much about the problem. It's a SEGV, so it's an application internal error (bug) of some sort. The best bet, rather than truss, would be to get it under a debugger. If you have a core file, at least try doing a "pstack" on the core file itself. Or use mdb and the "$c" command to print a stack trace. And show the result to the developer of the code -- he's likely the only one who can diagnose the problem correctly. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Configuring span ports on oi151
Jonathan Loran wrote: > Why not something like this: > > mkfifo /tmp/spanout-pipe > tcpdump -i bridgename0 -s0 -w /tmp/spanout-pipe & > cat /tmp/spanout-pipe | ssh ids-system "snort-etc-capture" Ew. I like it. :-/ For what it's worth, you could get rid of the named pipe: tcpdump -i bridge0 -s0 -w /dev/stdout | ssh ids "snort-etc-capture" -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] is the newly released orac-sol 11 an advance compared to oi?
On 11/10/11 17:07, Jerry Kemp wrote: > I have Solaris 11 Express still running on my SparcBlade 2000, because, to the > best of my knowledge, there are no OI iso images for Sparc. > > The fact that Solaris 11 Express runs fine on these systems, and Solaris 11 GA > does not load tells me that support for these boxes were discontinued for some > reason other than technical reasons, i.e. politics, financial, etc. I think it's pretty unfair to charge the good folks still lingering at Oracle in that way. I was involved with a number of technical reviews of support plans at Sun, and I strongly doubt that it's ever as simple as calling it just a "business decision." Often, the reason install has been disabled is that support for some key component has become impossible due to a third party license issue. Or the component itself cannot support some key new kernel feature. Or spare parts have run out and it's no longer possible to maintain the necessary test infrastructure. For example, an all-too-common technical problem is the changing landscape, such as the removal of Xsun and replacement with Xorg. Xorg's certainly better for most people, and supports a lot more hardware -- and is open source -- but there are old drivers that work only with proprietary Xsun, and there is _nobody_ with the right combination of money, talent, time, and motivation to do the rewrite. So guess what? Those systems end up in the dustbin. Unless someone from Oracle speaks up and says that something nefarious really happened, I suggest giving them the benefit of the doubt. If you're angry about it, and want to use brand new software on a 10 year old computer, then contact Oracle and let them know what you think. Or just stop buying their products. Whatever you feel is best. But speculating here about their motives is probably pointless. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Solaris 11 is out - so?
Gary Mills wrote: > On Fri, Nov 11, 2011 at 08:47:56AM -0500, Edward Ned Harvey wrote: >>> From: Gabriele Bulfon [mailto:gbul...@sonicle.com] >>> >>> Oracle announced availabilty of Solaris 11. >>> Do you notice any real news in the O.S. that OI/IllumOS has not? >>> What is the status of the promised sources? >> Sources were never promised. We all want them, but I never believed they >> were going to release them. > > Is there a legal requirement to release source built in to CDDL? > If not, we are unlikely to see it. They're the legal owners of the code, so it frankly does not matter what the CDDL says. The property owner can set or change any terms at any time, and is not bound by previous terms. But sources were indeed promised at some unspecified date after the binary release. Hope they carry through. http://mail.opensolaris.org/pipermail/opensolaris-discuss/2010-August/059310.html -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Solaris 11 is out - so?
Edward Martinez wrote: > On 11/11/11 06:48, James Carlson wrote: >> But sources were indeed promised at some unspecified date after the >> binary release. Hope they carry through. >> >> http://mail.opensolaris.org/pipermail/opensolaris-discuss/2010-August/059310.html >> >> > Some solaris 11 code were published and it appears some of the > files are CDDL licensed . I guess this is the only CDDL source will > get. well, maybe for now. > >http://oss.oracle.com/systems-opensourcecode/#oracle-solaris I looked those files over carefully, and that appears to be just the "must be distributed" third-party stuff, such as GPL'd components, and few user-level example bits. That's not at all what was referenced in the link I provided above. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Solaris 11 is out - so?
Hillel Lubman wrote: > It's a make it or break it moment. If Oracle holds to their promise to > release the source especially for ZFS - good. If they will make ZFS closed > from now on - do you think illumos can manage to pull it through on its own? Yes, but there are some interesting technical challenges. One is that the zpool and zfs version numbering space is flat, so unless the new on-disk (and in-stream) formats can be reverse-engineered, the compatibility story will be unusual, to say the least. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] IPv6 question
Mike Hyde wrote: > I am getting an IPv6 address via RA, but I am not getting a DNS entry via > dhcpv6. By RA, I assume you mean "stateless autoconfiguration." For DHCPv6, see in.ndpd(1M) and dhcpagent(1M). The way it's supposed to work on a "normal" network is that the router (via RA messages) signals that clients on this network should run what it calls "stateful autoconfiguration" -- this means DHCPv6. When this happens, in.ndpd will automatically invoke dhcpagent, and start doing DHCPv6 to get addresses and other data, depending on the "managed" and "other" flags in that RA message. Depending on the configuration of your system (whether you're using NWAM or not), you may need to set up an /etc/dhcp/eventhook to do something useful with the "BOUND6" and "EXTEND6" events. So, some questions: - Do you have explicit ndpd configuration (ndpd.conf)? If so, do you have stateful autoconf disabled? - Is your local router configured to advertise the need for DHCPv6? If it can't be configured that way, then see ifconfig(1M) for ways to start up DHCPv6 manually. - What does "ifconfig -a" say about the state of the interfaces? You will see "DHCP" on the IPv6 interface if DHCPv6 is running. - If the interface is already running DHCPv6, then try: dhcpinfo -i bge0 -v6 DNSAddresses (Replace "bge0" with the name of your interface.) If that last bit works, then /etc/dhcp/eventhook is probably what you need. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] IPv6 question
Mike Hyde wrote: > As I mentioned, this is a base install. I am using NWAM for networking. The > network is setup so that the interface IP comes from RA, and the dhcp server > only provides dns servers. This does work on linux properly, so I believe > the network is setup properly. OK. (Obviously, wireshark would tell one more ... ) > When I run dhcpinfo -i bge0 -v6 DNSAddresses I do get a DNS server address. Because the Neighbor Discovery RFC is a bit touched in the head, that could actually mean one of two things: either that there are no IPv6 routers on the network at all (!) or that one or more IPv6 routers are there and are issuing the "other" bit in the RA. I'll assume the latter, which would be a Good Thing here. > So based on your email I need to create a eventhook file and through some > config into it. Sigh; yes. The intended design was that NWAM would simply take care of this. It was supposed to check for DHCPv6 completion and decide what to do with the data based on its own set of priority rules. Obviously, that isn't happening. I'm not an expert in NWAM, so I'm not sure how to find out where (exactly) the ball is getting dropped. It's not supposed to be like that. But the eventhook work-around is fairly trivial. > Any idea where I would look to figure out what I need? The man page for dhcpagent(1M) may be a fair start; it includes examples. Something like this might be useful: #!/bin/sh case "$2" in BOUND6|EXTEND6|INFORM6) grep -v "DHCPv6 $1" /etc/resolv.conf > /etc/resolv.conf.new for addr in `/sbin/dhcpinfo -i $1 -v6 DNSAddresses`; do echo "nameserver: $addr # DHCPv6 $1" done >> /etc/resolv.conf.new mv /etc/resolv.conf.new /etc/resolv.conf ;; esac exit 0 The exact details will vary depending on how you want your network to operate. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] IPv6 question
Mike Hyde wrote: > I did some digging in the docs from OI past and found this: > > "DHCPv6 is invoked by Router Advertisements (RAs). Depending on how the > router is configured, the system automatically invokes DHCPv6 on the > interface on which the Router Advertisement message was received and uses > DHCP to get an address and other parameters, or the system requests only data > other than an address (for example, DNS servers) with DHCPv6. > The in.ndpd daemon receives the Router Advertisement message. It does this > automatically on all interfaces plumbed for IPv6 on the system. When in.ndpd > sees an RA that specifies that DHCPv6 should run, it invokes it." > > So it sounds like it could be expecting something from the router sending out > the RA and is not getting it. May not be an eventhook fix, but a router. I > will see what I can find. No. If you're getting output from dhcpinfo, then DHCP is running. As I noted before "ifconfig -a" will also show you that DHCP is running. The problem appears to be the local plumbing, not the router. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] some problem with oi151a
darkblue wrote: > hi, > I am a newbie with oi. > today, I installed oi151a on my workstation with oi151a-x86.iso(dvd) and > encounter some problem. > > 1. does it 32bit or 64bit? > After finished installation, I issue "uanme -a", it display: > SunOS oi-151 5.11 oi_151a i86pc i386 i86pc > > does this mean the DVD installer choose the 32bit version? No. > but curiously, when issue "top", the os could see all the RAM(16G) Try "isainfo" to see what instruction set families are supported for applications on the system, and "isainfo -k" for the single family supported for the kernel. You should see "amd64" there. > 2. > my oi-151 hang on boot, when I follow the above link tutor, failed to show > the boot process, why? > I edited the kernel line to such as: > kernel= xxx -v -m verbose > then press enter, and b > what I can see is the picture which right bottom corner is "Powered by > illumo" You need to turn off graphical boot as well. Use "d" in GRUB to remove the spashimage, foreground, and background lines, and then remove "console=graphics" from the kernel$ line. That should allow you to do a text-only boot. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] some problem with oi151a
darkblue wrote: > 2011/11/21 James Carlson >> You need to turn off graphical boot as well. Use "d" in GRUB to remove >> the spashimage, foreground, and background lines, and then remove >> "console=graphics" from the kernel$ line. That should allow you to do a >> text-only boot > > > thanks, it work for me, and OI-151 hang on: > > pseudo-device: ramdisk1024 > ramdisk1024 is /pseudo/ramdisk@1024 > pseudo-device: ucode0 > ucode is /pseudo/ucode@0 > > what does it mean, I google the last line and found nothing. The "ucode" driver does CPU-related microcode updates at boot time. I don't know that area of the code well enough to know whether that's what's going wrong, or if you possibly have another driver or structural problem (such as broken BIOS data). Besides searching for a guru in this area of the code, my next step would be to boot the kernel under kmdb with "-K", break to a prompt at the hang, and use $c to find out where it's stuck (and ::threadlist -v to see what else is going on). It might show something interesting. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Disable DHCP on a IPv6 configuration
On 11/23/2011 08:28 AM, Jeppe Toustrup wrote: Hi I am in the process of setting up IPv6 for some servers running OpenIndiana. Each server/zone has it's own IPv6 address which is configured statically in /etc/hostname6. such as: addif dead:beef:1000::11/64 up A default gateway has been set up with the "route" command: route -p add -inet6 default dead:beef:1000::1 However, when I have restarted the server (just to make sure everything works fine) I can see the interface I have configured the address for has a active dhcpagent: # ifconfig net0 inet6 dhcp status Interface State Sent Recv Declined Flags net0 SELECTING9 0 0 [V6] This is even though I haven't configured it to use DHCP in any way. How can I disable this? IPv6 is weird. The rule for DHCPv6 is that you run DHCPv6 if any of the IPv6 routers on the local network tell you to run DHCPv6. If all of them tell you not to run it, then you don't. But if there are *no* routers, then the default (rather counter-intuitively) is that you're supposed to run DHCPv6, which is what's happening here. Read the ndpd.conf(4) man page. And set "ifdefault StatelessAddrConf off" in /etc/inet/ndpd.conf. Or just ignore it. It's not hurting anyone. It's looking for a DHCP server that doesn't exist, and will do nothing as long as it never finds one. (The reason it's like this is that IPv6 "assumes" that "every" network will have at least one router. Given that you manually configured a default route, it sounds like yours may be the exception to that general rule.) ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Disable DHCP on a IPv6 configuration
On 11/24/11 16:45, Jeppe Toustrup wrote: > On Thu, Nov 24, 2011 at 22:27, James Carlson wrote: >> Read the ndpd.conf(4) man page. And set "ifdefault StatelessAddrConf off" >> in /etc/inet/ndpd.conf. > > Ah, thank you for the pointer. I tried it out and It is in fact > "StatefulAddrConf" which has to be disabled. So the line that goes > inside /etc/inet/ndpd.conf would be: > > ifdefault StatefulAddrConf off > > I like to get DHCP disabled on servers when I don't use it. There is > no need to make it easier for any rouge people to set up a > man-in-the-middle attack, by simply setting up a DHCP server on the > network. Yeah, you should force them to set up a rogue router, NDP instance, or DNS server instead. ;-} Seriously, though, if someone has physical access to your network, you'll need something stronger than just turning off DHCP. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] statfs() problem with HP-UX 11.23, 11.31 client and oi_151a server
On 11/27/11 02:03, Albert Chin wrote: > On Sun, Nov 27, 2011 at 12:48:39AM -0600, Albert Chin wrote: >> We're running oi_151a and using it to serve up file systems to HP-UX >> 11.23 and 11.31 hosts. Unfortunately, we're seeing statfs() problems >> on this NFS server. We don't see this issue on any other client >> (Solaris 2.6-10, AIX 5.1-7, HP-UX 10.20, 11.00, 11.11, Tru64 UNIX, >> IRIX, RHEL 4-6). Do you have 1TB or more in this file system? If so, then this is (unfortunately) the expected result. statfs() has int32_t structure members, which overflow if you have 2^31 blocks or more in your file system. 2^31 blocks is 1TB. > We don't see any errors from the above program when the NFS server > 11.31/IA or Solaris 10. > At a guess, smaller file systems. Just a guess, though. EOVERFLOW basically says that the result doesn't fit in the data structure available. Rather than return a wrong answer, it returns no answer. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] statfs() problem with HP-UX 11.23, 11.31 client and oi_151a server
Albert Chin wrote: > On Sun, Nov 27, 2011 at 08:04:33AM -0500, James Carlson wrote: >> On 11/27/11 02:03, Albert Chin wrote: >>> On Sun, Nov 27, 2011 at 12:48:39AM -0600, Albert Chin wrote: >>>> We're running oi_151a and using it to serve up file systems to HP-UX >>>> 11.23 and 11.31 hosts. Unfortunately, we're seeing statfs() problems >>>> on this NFS server. We don't see this issue on any other client >>>> (Solaris 2.6-10, AIX 5.1-7, HP-UX 10.20, 11.00, 11.11, Tru64 UNIX, >>>> IRIX, RHEL 4-6). >> Do you have 1TB or more in this file system? If so, then this is >> (unfortunately) the expected result. statfs() has int32_t structure >> members, which overflow if you have 2^31 blocks or more in your file >> system. 2^31 blocks is 1TB. > > I think you're correct. If we quota the exported file system to 40G, > then there is no problem. So why don't all operating systems return > EOVERFLOW? In a different environment (particularly on a 64-bit system), those values may not be just 32 bits wide. If you can't fix the application that's doing this, then I think setting a quota just under 1TB may be the simplest work-around. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] OpenIndiana/ZFS mail server HA config
Lucas Van Tol wrote: > I had been trying to work out some kind of HA using iscsi LUNS + ZFS mirror > on top of that; but I never got around to figuring out an automated failover > process. > You would want the master to not share out it's LUN; and the other node to > check if there is a system at the 'master' address before trying to become > the master. > It probably wouldn't be very fast, but it might be sufficient if you can get > the failover worked out. I can't say I've seen great results from hand-crafted reinventions of the clustering wheel. If clustering is what you need, then I suggest considering how much you value your data, and spend accordingly on a workable solution. Just my suggestion, though. If you are certain that you don't want a full clustering solution, there might be an alternative. I don't know what happened with it after the diaspora, but there was an OpenSolaris VRRP project that was intended for just this sort of individual service fail-over configuration. Even though the first "R" in that abbreviation stands for "router," the designers in that project intended to make it work primarily with things other than routing protocols. http://hub.opensolaris.org/bin/view/Project+vrrp/ Maybe you can find some pointers related to that ... -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] OpenIndiana-discuss Digest, Vol 17, Issue 11
Hans J. Albertsson wrote: > Which of the ethernet interfaces is supported, the 82579LM or the 82574L? > > Since I absolutely need at least two interfaces, preferably 4, the > answer is important. Looks like both work, assuming you have the very latest code. The latter (82574L) has been supported for a long time. The former (82579LM) is more recent: https://www.illumos.org/issues/832 -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Will an 82575EB based Supermicro AOC-SG-i2 ethernet work OK in b151a?
Hans J. Albertsson wrote: > Subject says it all. > > I suppose so, at least one shouldn't need to do anything beyond addig a > line in /etc/driver_aliases, right? The line for 8086,10a7 should already be there; it's served by "igb". -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] set up PPPoE
Daniil Zaytsev wrote: > Hi. > How can i set up PPPoE connection in oi-151. Especially i can not > understand where and how is to enter and password to be authorized by my > provider. > It needs for internet availability. There's a fairly good how-to guide here: http://www.phildev.net/solaris/spppoe.html Other places to look include the pppoec(1M) and sppptun(1M) manual pages. If you have trouble with it, please post your configuration details and the results of any debugging you've done, particularly log messages. Typically, the user name is entered into a new file in /etc/ppp/peers/ (see the "myisp.tmpl" file there for an example configuration, albeit for dial-up), and the pass phrase is added to /etc/ppp/pap-secrets (which also contains usage details). For example, you might create a file called /etc/ppp/peers/pppoeisp and put into it: sppptun plugin pppoe.so connect "/usr/lib/inet/pppoec e1000g0" noauth defaultroute user daniil and then add this to /etc/ppp/pap-secrets: daniil * "Daniil's Password" You would then invoke the connection with "pppd call pppoeisp" or (to do this with debugging enabled, and debug messages written to your terminal) "pppd call pppoeisp debug updetach". More information about the PPP level of configuration (as opposed to the low-level PPPoE plumbing) is available in the pppd(1M) manual page. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] set up PPPoE
Jerry Kemp wrote: > I have archived several dozen PPPoE on Solaris threads from misc. Solaris > mailing lists over the years. > > Most of my archived emails contained URL's to howto sites, and following up on > those sites, probably half are dead. But typically, you can still find the > archived sites on the Wayback machine and still get the data. What you're referring to here is the horrible PPPoE MTU problem. PPPoE's MTU is 1492, but most of the Internet uses 1500. And although PMTUD was supposed to fix things, it often doesn't work because lame network administrators have broken it by filtering out ICMP messages for "security" reasons. And then when you through NAT on top, you've got a real mess. The NAT solutions that "work" here actually break other protocols -- they do it by modifying the TCP MSS on the fly, by fragmenting packets marked "do not fragment" and so on. With some things, such as IPsec protection, you end up with broken bits. I agree that it doesn't work terribly well here. I'd go a bit further, though, and say that PPPoE has just plain intrinsic problems. Protocols that are designed in secret tend to be like that. > Most of these threads I follow typically end with the end user going out and > purchasing a Linksys/D-Link/some-other-generic-brand NAT box with PPPoE > capabilities. Probably so. I think they'd be better served, though, by getting rid of PPPoE entirely and getting a real Internet connection from someone who doesn't use trashy protocols. > I would also add, that the end users who did get PPPoE working never seemed > happy with the throughput they received and if they use it (PPPoE on Solaris) > for any length of time, they seem to move into a phase 2 where once PPPoE is > working, they need to fine tune it to get any network performance out of it. Unless you're referring to the MTU problem, that doesn't sound right at all. The testing we did at Sun showed that we had line performance at least at the 100Mbps level on cheap commodity hardware. If you're seeing something else, then I think you probably have other problems. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Couldnt install Nagios client nsca
On 12/25/2011 4:19 AM, Ram Chander wrote: > > # telnet 0 5667 > Trying 0.0.0.0... > telnet: Unable to connect to remote host: Connection refused I don't know anything about this nsca program, but I'd suggest using either "telnet localhost 5667" or "telnet 127.1 5667" rather than attempting to use "0" as an alias for the local system. It's a bit of an old Solaris bug that allows address 0 to work as a local address (even though it's not a valid address), and there's no guarantee that it will work on any modern Solaris system. A simple bug fix could easily break it. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Crossbow performance & bit rot
On 12/31/2011 1:27 AM, Jason Matthews wrote: > As a follow up, I have determined that crossbow is not at fault for the > degradation of the network stack performance. As it turns out, the shared > stack fails much faster than multiple zones with exclusive-ip. For what it's worth, although VNICs are a feature of Crossbow, there's no actual way to turn Crossbow on or off. It's a design and locking architectural change to the stack. You can't really exclude it except by returning to an older (Solaris 10) stack and trying the test there. > The symptoms are slow out bound connection times, high ping times between > systems on a local subnet (1ms to 500ms on gigE), and general network > flakiness. I don't know what is causing the problem you're seeing, but I do have some guesses. Assuming it affects all packets, and not just those of a particular type, the slow packet delivery sounds a bit like either a driver problem or a problem with the (Crossbow-introduced) "polling" mode that drivers can use during periods of high traffic. Another fairly likely possibility would be the hardware offload features that some drivers can use -- checksum and LSO. If the driver you're using can turn off these features, I strongly recommend trying that. I'd quickly run out of appendages before I could count the number of times that "hardware acceleration" has thrown performance in the toilet. I realize this is a production system, and that really hurts. However, since nobody else seems to have the problem, which makes solutions out of the blue less likely, it would probably be instructive to do some investigation. I suggest: - using dtrace to find out what the code paths are when traffic is working fine and when it's slow; the difference may reveal something, - installing a network interface card that uses a different driver (e.g., if you have Intel, install Broadcom) and see if that interface behaves differently. Note that you'll probably need to know a fair bit about the driver to use dtrace effectively. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] How will this change affect any future source from Oracle ?
On 1/7/12 10:43 PM, Mark wrote: > This looks to be a major change to how ON/net is being built. > > http://blogs.oracle.com/ali/entry/much_ado_about_nothing_stub > > Will this be a show stopper when integrating any future source released > by Oracle ? It certainly would not be. At least among former Sun folks, it's a long anticipated, much discussed, and very good change. It breaks up the unneeded dependencies among the subdirectories in the build, so that more things can be built in parallel. If you fear it for some reason, you can simply ignore it: continue building as you've always done (without stub libraries), using all the same dependencies as you've done before, and it'll keep working. The stubs are just a build artifact. They're generated automatically and aren't needed after the build is done. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Virtual memory problems
Gabriele Bulfon wrote: > swap -l shows this: By the way, "swap" has the "-h" and "-k" flags, just like df. Note also that you can list just the swap-mounted file systems with "df -F tmpfs -h". > swapfile devswaplo blocks free > /dev/zvol/dsk/rpool/swap 179,2 8 1048568 634816 > but if I issue zfs list rpool/swap I get: > NAME USED AVAIL REFER MOUNTPOINT > rpool/swap 544M 11.9G 346M - > ...confusedwhat is the real swap space?? > I just would like to have swap space to be 2GB at least. > I don't think I tampered the installation, but just got this after the > original install on VirtualBox. > Is it Things get a little complicated because total swap includes memory and storage devices, but the "swap -l" output includes just the configured storage, and not memory. Try using "swap -s" (or "swap -sh") to see the actual space in use. You should see that the "available" space matches up with the available swap space seen by "df". For the ZFS swap volume, you'll want to look at the "volsize" parameter. That's what sets the actual disk area available for swap. It looks like the existing volume was set to 500MB. Try "zfs list -o name,volsize rpool/swap". To change the swap size, I'd do this: # swap -d /dev/zvol/dsk/rpool/swap # zfs volsize=2G rpool/swap # swap -a /dev/zvol/dsk/rpool/swap You could also create a new swap volume with the desired size, add it, and then remove the old one. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Replacing OI 151 ssh with OpenSSH 5.9?
Gregory Youngblood wrote: > I was looking into swapping out the ssh that comes with oi151a with openssh > 5.9. I already looked in SFE and didn't see openssh, unless I missed it. > > I pulled the source and it seems to compile OK, though without tcp wrappers, > PAM, etc. The first pass was more to see what would happen before spending > any real time on it. > > Before going further, I was wondering if anyone else has done this and > whether they have any tips, instructions, or insights. Why would you want to do that ... ? It might help in getting useful responses if you described what you were hoping to accomplish by replacing that component. For what it's worth, the ssh that comes with OpenIndiana is well integrated with the existing OS features and performs decently. You may end up replicating the hard work the Sun ssh team did getting it integrated. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Replacing OI 151 ssh with OpenSSH 5.9?
Milan Jurik wrote: > in long term you will need to do the switch anyway as it is unlikely > somebody will dedicate full-time taking care about improvements and also > sync with OpenSSH forever as SUN did. Otherwise "IllumosSSH" will loose > contact with the latest versions. I think that's actually a deeper issue, because it doesn't just apply to the intentionally-forked SSH implementation, but rather to all of the Illumos source. The parts that aren't owned by someone and actively maintained may have trouble. I don't see with SSH would be special in this regard. > It would be much better to identify the needed parts and deliver them as > patch on top of OpenSSH releases. That's probably a bit easier said than done. The original Sun SSH team intentionally forked the source because there were substantial high-level design differences, particularly in the area of privilege separation. Meaningful source patches for this sort of thing are probably at least as hard to manage as are the sources themselves -- meaning that I believe you'd have no real benefit to keeping diffs instead. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Replacing OI 151 ssh with OpenSSH 5.9?
Milan Jurik wrote: > The question is if the work done for Solaris 9 is so crucial even today. > Additionally many things changed in cooperation of both sides, many > things were merged. Will such fork have so crucial and deep in design > advantages these days? "Done for Solaris 9?" Wow, I think that substantially disparages the work that the Sun SSH team did in Solaris 10 and OpenSolaris. I hope some of those folks are on the list and can respond appropriately. I wasn't a member of that team, but I was there at Sun when the discussions of why forking was necessary occurred, and the issues were (and are) not trivial. But, hey, it's your system. Install anything you want on it. Much luck. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Crossbow performance & bit rot
On 01/17/12 14:01, Jason Matthews wrote: >> Another fairly likely possibility would be the hardware offload >> features that some drivers can use -- checksum and LSO. If the >> driver you're using can turn off these features, I strongly >> recommend trying that. I'd quickly run out of appendages before >> I could count the number of times that "hardware acceleration" >> has thrown performance in the toilet. > > The igb driver doesn't have any tunables for disabling hardware > acceleration. It has a lot of tunables. First, there are the ones documented in /kernel/drv/igb.conf. Of those, perhaps the most interesting is flow_control. It looks like the hardware acceleration ones here are the queuing-related ones, but they appear to be disabled by default. Then there are ones that can be controlled via igb.conf but that aren't advertised in the default file that ships. These include: intr_force tx_hcksum_enable rx_hcksum_enable lso_enable tx_head_wb_enable tx_copy_threshold tx_recycle_threshold tx_overload_threshold tx_resched_threshold rx_copy_threshold rx_limit_per_intr intr_throttling mcast_max_num Several of those control hardware acceleration features. Then there are the private link properties that you can access via dladm show-linkprop (but that don't show up unless specifically requested): _tx_copy_thresh _tx_recycle_thresh _tx_overload_thresh _tx_resched_thresh _rx_copy_thresh _rx_limit_per_intr _intr_throttling _adv_pause_cap _adv_asym_pause_cap All of those look interesting, but would likely require some driver-level information to use properly. > I did however issue 'echo dohwcksum/W 0 | mdb -kw' > > I assume that turned off hardware checksums. Flipping that bit made no > difference, however. > > I added a Broadcom 5709 dual port card which uses the bnx driver. It > experiences the same degradation as the Intel chips. The Broadcom driver is > configurable for turning off hardware checksums and so I did that in > bnx.conf. It made no difference, the network performance still deteriorates. That's interesting. Have you tried isolating other components? Is the behavior the same on all switch ports? Does it differ if you're connected to a different brand of switch? Is there anything special going on here? For example, do you have standard IEEE link negotiation turned off -- forcing duplex or link speed? > I could find no options to disable LSO on either the Broadcom or Intel > cards. Is there an object to tweak with mdb? It's a driver property; see above. (Tweaking with mdb is at least theoretically possible, but is actually fairly hard to do.) >> I suggest: >> >> - using dtrace to find out what the code paths are when traffic is >> working fine and when it's slow; the difference may reveal something, >> > > Tracking this with dtrace is currently out of my league, but I take > direction well. It's an interactive exercise, unfortunately, and I don't think I have the time to walk through it here. > My current work around is that I expanded the number of zones running on the > four web servers from 8 zones total to 28 zones total. This has dramatically > slowed the degradation. I would have gone to 32 zones but the current IP > subnet wont support it. Before expanding to 28 zones, I was forced to delete > the vnics and reboot the zones each day. > > >>From time to time, I see correctiosn in the response time graphs. For > instance, one or more zones/vnics on the a given system experience a sudden > drop in response times. Say from 5ms to less than 1 ms. When this happens, > occasionally a cycle starts where every one to two hours the performance > resets back under 1ms(I view this as a good thing), and then begins to rise > again. Eventually, some large spike comes around in response time, the cycle > breaks, and the system resumes the slow climb to certain death. > > I could use some more ideas. I am considering putting a pre-crossbow S10, > oi148, and/or S11 on the front line here to see if the problem goes away. I > starting to scrape the bottom of the barrel for ideas. Those symptoms seem to point in the direction of something much broader; a system-wide issue with interrupts, perhaps. Have you seen the postings about APIC issues? Could those apply here? set apix:apic_timer_preferred_mode = 0x0 -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Crossbow performance & bit rot
Jason Matthews wrote: >> Have you tried isolating other components? Is the behavior the same on >> all switch ports? Does it differ if you're connected to a different >> brand of switch? > > So I have four servers performing this particular role. Three of them, > slowly and quietly march to their death. One, marches to its death but > periodically gets a 'reset' where http response time suddenly drops and the > "clock" on the march to death starts over. > > Yesterday, the 'resets' started happening on a second box. > > I current switch is a Junper EX4200 configured as a virtual switch with > reasonable size stack chassis configured as line cards. It seems to work > just dandy for the other systems connected to it. I haven't tried another > switch yet, but there are no link related issues being reported on either > side. I have used this configuration before with e1000 based nics on > OSOL2009.6 and OI148. OK. Still, if it's possible in your hardware environment, I suggest trying different connections. There are several reasons for this: 1. It will help rule out another possible source of trouble, namely some kind of compatibility problem between these two systems. This is valid regardless of what else may be attached to that switch. 2. We've observed the same bad behavior from two different network interface cards with two completely different drivers, which makes the odds of some kind of low-level kernel driver problem a good bit lower. 3. I don't know of any reports of similar behavior from anyone else, which means that either others are ignoring the problem, or that there's something that is somehow special about your environment. >> Is there anything special going on here? For example, do you have >> standard IEEE link negotiation turned off -- forcing duplex or link speed? > > Nothing particularly special. The gigE spec says to leave those in autoneg, > and they are in autoneg. Autoneg appears to work as advertised. OK; good. > The servers are connected via a LACP with 2 members in the bundle. I have > tested with LACP and with straight up Ethernet switching, it makes no > difference. That's an interesting bit. I'm not positive what you mean by "straight up Ethernet switching." Does that mean a single physical link from the server to the switch, or does it mean two links using 802.3ad link aggregation but with LACP turned off? If it means the latter, then that sounds like another variable to check out. I would configure a plain vanilla Ethernet link -- no 802.3ad -- and see if the problem can be seen there. (Traditionally, on Solaris, IPMP has been used for link facility protection. In some cases, it can detect errors that LACP cannot. I'm not saying that LACP is a bad idea at all, but rather that since it has far fewer miles on it, at least in terms of the Solaris kernel, the ice is almost certainly thinner below.) > Here is the switch config, it is pretty plain vanilla. Yes, except for the 802.3ad link aggregation, it does look pretty plain. > I havent seen the APIC issues but I have been turning the APIC knobs. I gave > apic_timer_preferred_mode a whirl. It made no impact. I also tried > > setprop acpi-user-options=0x8 and setprop acpi-user-options=0x2 > individually. These also brought me no joy. OK. That eliminates a few possibilities. > I gave disabling hw acceleration a whirl. > > tx_hcksum_enable = 0; > rx_hcksum_enable = 0; > lso_enable = 0; > > disabling the hardware acceleration earned me about 40% jump in cpu > utilization but no relief on the original problem. ... as does that. > I haven't tried connecting them to another switch, but I see no link related > issues. No discards, errors, etc. I would consider excessive packet delivery delays to be a potential link-related issue. I realize that the problem isn't causing the counters to pop, but that by itself doesn't mean that there's no issue there. Another thing to look at would be the kstats for the Ethernet drivers. It would be interesting to see what changes before and after one of these "reset" events, to see if the driver is noticing something or if the problem is actually elsewhere. > I did notice one interesting item. The server that has had the 'resets' > where performance returns to normal but then begins the march of death has a > link state of 'unknown' on its two vnics. That is interesting. Unfortunately, I'm not sure what it means. At this point I think the prime suspect would have to be 802.3ad, though I can't point at anything definitive. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] CIFS performance issues
Robin Axelsson wrote: > I looked into the /var/adm/messages and found the > > nwamd[99]: [ID 234669 daemon.error] 3: nwamd_door_switch: need > solaris.network.autoconf.read for request type 1 > > errors during the time. I'll look more carefully next time and see if > the time-stamps of these entries match the time at which I experience > those freeze-ups. I suspect that they do. That message itself should be innocuous. It means that someone tried to use the NWAM administrative interface to read status, but whoever attempted to do that lacked the right authorization to do so. I don't think anything about that message should relate to a "freeze-up." It could be a symptom, though, of other issues. If this system is intended for use as a server, it's possible that you might not want to be using NWAM at all. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] CIFS performance issues
Robin Axelsson wrote: > On 2012-01-24 16:52, Gary Mills wrote: >> On Tue, Jan 24, 2012 at 04:39:42PM +0100, Robin Axelsson wrote: >>>>> ifconfig -a returns: >>>>> ... >>>>> e1000g1: flags=1004843 mtu >>>>> 1500 index 2 >>>>> inet 10.40.137.185 netmask ff00 broadcast 10.40.137.255 >>>>> e1000g2: flags=1004843 mtu >>>>> 1500 index 3 >>>>> inet 10.40.137.196 netmask ff00 broadcast 10.40.137.255 >>>>> rge0: flags=1004843 mtu >>>>> 1500 >>>>> index >>>>> 4 >> Do you really have two ethernet ports on the same network? You can't >> do that without some sort of link aggregation on both ends of the >> connection. > I don't see why not. I've done this before and it used to work just > fine. These are two different controllers that work independently and I > do it so that the VM(s) could have its own NIC to work with as I believe > the virtual network bridge interferes with other network activity. It's never worked quite "right" (whatever "right" might mean here) on Solaris. If you have two interfaces inside the same zone that have the same IP prefix, then you have to have IPMP configured, or all bets are off. Maybe it'll work. But probably not. And was never been supported that way by Sun. > If we assume that both ports give rise to problems because they run > without teaming/link aggregation (which I think not) then there wouldn't > be any issues if I only used one network port. I have tried with only > one port and the issues are considerably worse in that configuration. That's an interesting observation. When running with one port, do you unplumb the other? Or is "one port" just an application configuration issue? If you run "/sbin/route monitor" when the system is working fine and leave it running until a problem happens, do you see any output produced? If so, then this could fairly readily point the way to the problem. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] CIFS performance issues
might want to dig up something a little more modern. Before OpenIndiana branched off of OpenSolaris (or before Oracle slammed the door shut), a lot of work went into IPMP to make it much more flexible. >> If you run "/sbin/route monitor" when the system is working fine and >> leave it running until a problem happens, do you see any output produced? >> >> If so, then this could fairly readily point the way to the problem. >> > WIth one port I mean that only one port is physically connected to the > switch, all other ports but one are disconnected. So I guess ifconfig > unplumb would have no effect on such ports. Not so! In terms of getting the kernel's IRE entries correct, it doesn't matter so much where the physical wires go. It matters a whole lot what you do with "ifconfig." > I managed to reproduce a few short freezes while "/sbin/route monitor" > was running over ssh but it didn't spit out any messages, perhaps I > should run it on a local terminal instead. If the freeze is damaging network communication, then doing that to some destination (such as "> /tmp/monitor.out") that won't be affected by the network is probably a good idea. It's a guess. I'm guessing that what's really going on is that you have either interfaces, IREs, or ARP entries flapping in the breeze due to the odd configuration on this system. "route monitor" should reveal that. But it could be almost anything else. Looking at kstats and/or capturing network traffic may be necessary in order to find the problem. > I looked at the time stamps > of the entries in the /var/adm/messages and they do not match the > freeze-ups by the minute. I assume that refers to the NWAM messages previously reported. No, I don't think those are the proximate cause of your problem. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] CIFS performance issues
Robin Axelsson wrote: > On 2012-01-24 21:59, James Carlson wrote: >> Well, unless you get into playing tricks with IP Filter. And if you do >> that, then you're in a much deeper world of hurt, at least in terms of >> performance. > Here's what the virtualbox manul says about bridged networking: > > "*Bridged networking*: > > This is for more advanced networking needs such as network simulations > and running servers in a guest. When enabled, VirtualBox connects to one > of your installed network cards and exchanges network packets directly, > circumventing your host operating system's network stack. Note what it says above. It says nothing about plumbing that interface for IP on the host operating system. I'm suggesting that you should _not_ do that, because you (apparently) want to have separate interfaces for both host and the VirtualBox guests. If that's not what you want, then I think you should clarify. Perhaps the right answer is to put the host and guests on different subnets, so that you have two interfaces with different subnets configured on the same physical network. That can have some risks with respect to multicast, but at least it works far better than duplicating a subnet. >> I suspect that the right answer is to plumb only *ONE* of them in the >> zone, and then use the other by name inside the VM when creating the >> virtual hub. That second interface should not be plumbed or configured >> to use IP inside the regular OpenIndiana environment. That way, you'll >> have two independent paths to the network. > Perhaps the way to do it is to create a dedicated jail/zone for > VIrtualBox to run in and "plumb the e1000g2" to that zone. I'm a little > curious as to how this would affect the performance I'm not sure if you > have to split up the CPU cores etc between zones or if that is taken > care of as the zones pretty much share the same kernel (and its task > scheduler). I'm confused. If VirtualBox is just going to talk to the physical interface itself, why is plumbing IP necessary at all? It shouldn't be needed. >> It's possible to have DHCP generate multiple addresses per interface. >> And it's possible to use IPMP with just one IP address per interface (in >> fact, you can use it with as little as one IP address per *group*). And >> it's possible to configure an IPMP group with some static addresses and >> some DHCP. > In order to make DHCP generate more IP addresses I guess I have to > generate a few (virtual) MAC addresses. Maybe ifconfig hadles this > internally. You don't have to work that hard. You can configure individual IPv4 interfaces to use DHCP, and the system will automatically generate a random DHCPv4 "ClientID" value for those interfaces. For example, you can do this: ifconfig e1000g0:1 plumb ifconfig e1000g0:2 plumb ifconfig e1000g0:1 dhcp ifconfig e1000g0:2 dhcp Using the old-style configuration interfaces, you can do "touch /etc/dhcp.e1000g0:1" to set the system to plumb up and run DHCP on e1000g0:1. There's probably a way to do this with ipadm, but I'm too lazy to read the man page for it. I suggest it, though, as a worthwhile thing to do on a lazy Sunday afternoon. >> But those are just two small ways in which multiple interfaces >> configured in this manner are a Bad Thing. A more fundamental issue is >> that it was just never designed to be used that way, and if you do so, >> you're a test pilot. > This was very interesting and insightful. I've always wondered how > Windows tell the difference between two network connections in a > machine, now I see that it doesn't. Sometimes this can get corrupted in > Windows and sever the internet connection completely. If I understand > correctly, the TCP stack in Windows is borrowed from Sun. I guess this > is a little OT, it's just a reflection. No, I don't think they're related in any significant way. The TCP/IP stack that Sun acquired long, long ago came from Mentat, and greatly modified since then. I suspect that Windows derives from of the BSD code, but I don't have access to the Windows internals to make sure. In any event, they all come from the basic constraints of the protocol design itself, particularly RFC 791, and the "weak ES" model. >>> I will follow these instructions if I choose to configure IPMP: >>> http://www.sunsolarisadmin.com/networking/configure-ipmp-load-balancing-resilience-in-sun-solaris/ >>> >> Wow, that's old. You might want to dig up something a little more >> modern. Before OpenIndiana branched off of OpenSolaris (or before >> Oracle slammed the door shut), a
Re: [OpenIndiana-discuss] CIFS performance issues
x certainly should be there as "/n". It's basically the same as in modern IPv4, except with 128 bits instead of 32. In modern -- CIDR -- IPv4, you don't normally refer to a subnet mask as something like 255.255.255.128, but rather as a prefix length, like "/25". Besides being more compact, the prefix length notation avoids dumb (and pointless) mistakes that occur when someone accidentally specifies non-contiguous mask bits. > "dladm" you say. I trust that VirtualBox does what it needs in that > regard and that I have to worry about it, for now. I should hope so. >> ifconfig(1M), unfortunately, comes from BSD which blurred the lines >> between datalink and network layers. They're really quite distinct in >> OpenIndiana (and Solaris before it), but the confused user interface in >> ifconfig sadly leads users astray. > I see... I read on a forum that when unplumb fails it sometimes helps to > issue the 'ifconfig down' command before unplumbing the > connection. But that was a BSD (don't know which flavor) forum. At least in terms of Solaris/OpenSolaris/OpenIndiana, I can't make heads or tails out of that suggestion. >> That seems likely. I think the whole thing was set in doubt when two >> separate interfaces were configured up on the same subnet. Everything >> past that point sounds like the experience of a test pilot. Some of the >> control surfaces departed the craft in flight, but, hey, if that weren't >> one of the possibilities, then we wouldn't need these brave souls. >> > > I tried for a change to look into the Graphical Network Adminstration > tool in Gnome (/usr/lib/nwam-manager-properties) and the e1000g2 > connection was disabled there even though 'ifconfig -a' showed that it > wasn't. I also verified with ping that this connection was not reponding > (ping 10.40.137.171) but that could be because I have done 'ifconfig ... > down' on it. Right. Marking it "down" means that it is no longer administratively available. > When I shut down the virtual machine, the e1000g2 connection disappeared > from 'ifconfig -a'. So it seems that the VM somehow blocked/prevented > ifconfig to apply the unplumbing and once the VM was shut down the > unplumbing kicked in first then. That's weird. I don't know enough about VirtualBox, though, to know how or why that would happen. I don't think it should. It kinda sounds like a bug. > I have now managed to disable the e1000g2 and the rge0 interface > permanently by the nwam-manager-properties program (by 'Edit"ing the > Network Profile). Both connections have now disappeared from 'ifconfig > -a' (also the IPv6 part is gone as well), even after a reboot, so I > consider them permanently unplumbed. It looks like this when issuing > 'ifconfig -a': > > lo0: flags=2001000849 mtu > 8232 index 1 > inet 127.0.0.1 netmask ff00 > e1000g1: flags=1004843 mtu > 1500 index 2 > inet 10.40.137.185 netmask ff00 broadcast 10.40.137.255 > lo0: flags=2002000849 mtu > 8252 index 1 > inet6 ::1/128 > e1000g1: flags=20002004841 mtu 1500 index 2 > inet6 fe80::6a05:caff:fe01:da8e/10 > > The VirtualBox Qt GUI still recognizes all physical interfaces (e1000g1, > e1000g2 and rge0) even though they are disabled from the host which is > good. > > So I guess that once again the bets are on and all is good then... That sounds much better to me. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] CIFS performance issues
Open Indiana wrote: > Please skip the whole ifconfig and plumb this or that discussion. > > Virtualbox works on any interface that is "plumbed" since only then the > interface is visible in the menu. Oh, yuck. It should be using the libdlpi interfaces (see dlpi_walk(3DLPI)), at least on OpenIndiana. If portability to older Solaris systems is necessary, it should be enumerating DLPI interfaces using libdevinfo. Piggybacking on IP isn't right at all. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] CIFS performance issues
On 01/27/12 07:51, Robin Axelsson wrote: > On 2012-01-25 21:50, James Carlson wrote: >> By default, the first IP layer object created on a given datalink layer >> object has the same name as that datalink layer object -- even though >> they're distinct ideas. The second and subsequent such objects created >> get the somewhat-familiar ":N" addition to the name. It's sometimes >> helpful to think of that first object as being really named "e1000g1:0" >> at the IP layer, in order to keep it distinct from the "e1000g1" >> datalink layer item. > > This sounds like an implementation of the OSI model which separates the > datalink layer from the network layer. Yes. The design (since Solaris 2.0) has always been internally a bit more deliberately layered, but during OpenSolaris development we put a lot of work into making the distinctions more visible in the administrative interfaces, because they're actually fairly useful when it comes to virtualization and other new functions. > When speaking of blurred lines, > it seems that the line between the network layer, transport layer and > session layer (as specified in the OSI model) is also quite blurry. Network and transport are fairly clear (though ICMP is sort of a sticky bit). Session is basically absent for TCP/IP. > In NAT mode the VirtualBox hypervisor acts as a virtual router that sits > between the IP stack of the host and the VMs. It has its obvious > limitations as you have pointed out which is why I don't use this mode. > This mode also has (or at least had in prior versions of VirtualBox) > stability/performance issues. OK >> Back in the bad old days of BOOTP, clients were in fact forced to use >> hardware (MAC) addresses for identification. That's still the default >> for DHCP, just to make things easy, but a fancy client (such as the one >> in OpenIndiana) can create client identifiers from all sorts of sources, >> including thin air. > > I guess that this ClientID feature is only used by more advanced > routers, because all my machines (virtual and physical) are identified > by a given MAC address in the router. Or maybe it is capable of ClientID > and I'm not aware of it, the router documentation is mum about this > feature though. As I said, using the MAC address to construct a client identifier is generally the default, so it's not at all surprising that this is what you see. The point is that it's not the only possibility. >> You have to tell ifconfig what you want to do. If you want to modify >> the separate IPv6 interfaces, then specify "inet6", as in: >> >> ifconfig e1000g0 inet6 unplumb > > Ok. When I plumb/unplumb a connection with ifconfig, will this > (un)plumbing be permanent or only be in effect until next reboot or > power cycle? It's non-permanent. It affects only the running system. > I would expect that this plumbing configuration is in some > /etc/ file somewhere... Yes. If you're running with the old-style start-up scripts, then the existence of /etc/hostname.XXX causes interface "XXX" to be plumbed for IPv4 and for the contents of that file to be used as the arguments and options to ifconfig. A similar thing is true for /etc/hostname6.XXX, but for IPv6. And if /etc/dhcp.XXX exists, the interface is plumbed and DHCP is run. Things changed quite a bit with both NWAM and ipadm. The latter provides both transient and permanent configuration features, and no longer relies on the /etc/hostname.* files. >> In modern -- CIDR -- IPv4, you don't normally refer to a subnet mask as >> something like 255.255.255.128, but rather as a prefix length, like >> "/25". Besides being more compact, the prefix length notation avoids >> dumb (and pointless) mistakes that occur when someone accidentally >> specifies non-contiguous mask bits. > > Ok, so I assume that the /n means that the /n/ least significant > consecutive bits are 0 in the network mask. No. It means that the "n" most significant bits are 1, and the "32-n" least significant bits are 0. So, "/24" is 255.255.255.0. "/8" is 255.0.0.0. "/28" is 255.255.255.240. > So that means I'm no longer > able to specify network masks such as 170.85.144.70 where for example > 144 in binary form is 1001, i.e. that the zeroes in the mask are not > consecutive/contiguous as there are ones in between. For IPv4 may still be able to use non-contiguous masks, but they were never a rational choice at all -- anywhere. And with certain routing protocols, they simply didn't and could not work. They're a definite case of "so, what exactly were you trying to do?" Al
[OpenIndiana-discuss] plumbing for zones [was Re: CIFS performance issues]
On 01/27/12 08:52, Open Indiana wrote: > I'm very sorry to have misinformed you. I didn't check my remarks on a > working system and I mixed up two things. > > Virtualbox will discover even an unplumbed device. > > It was the zones booting that I had in mind. On my solaris 10 server I need > to plumb all interfaces that are used inside a zone on the global zone > before the zone can use it. Yes, that's a completely different mechanism. The issue there is that with zones, there's only one kernel, and certain global operations (such as plumbing) can take place only in the global zone, not in a non-global zone. Of course, the addition of exclusive IP stacks in one of the S10 patches makes that distinction a bit muddier, but it still exists. For example, you cannot install or load a kernel module inside a non-global zone. There's no way for the kernel to find it there. And if you could do it, then you could break the security model, so the limitation is a good thing. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] CIFS performance issues
On 01/27/12 08:37, Robin Axelsson wrote: > If VirtualBox and OpenIndiana did what they promised without hickups I > wouldn't even need two network interfaces to ensure the operation of the > system. But when bugs occur we try to get around them until they are > fixed, and that requires at least some knowledge about the system which > I'm really happy to have acquired. There's obviously more to this story. I've used VirtualBox on OpenIndiana with a single network interface without a whole lot of fanfare, so it's a little surprising to hear that someone is going to a lot of effort to make things more complex in order to avoid problems. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] CIFS performance issues
On 01/27/12 08:28, Robin Axelsson wrote: > One way to make the system user-friendly is to make nwam automatically > configure IPMP when it detects two properly working ethernet connections > within the same subnet. My recollection is that automatic configuration of IPMP was on the list of things to do, but that it never got done. It just wasn't the focus, because NWAM was initially designed to handle laptops and other simple systems, not servers. What NWAM is supposed to do is configure only one usable interface (guided by user selection criteria) for the system. The fact that you got multiple interfaces configured is indeed an anomaly, and one I can't explain. I don't know how you got there in the first place. It shouldn't have happened. Someone with a deeper understanding of the "new" NWAM would have to look at your system to find out what went wrong. Unfortunately, I only remember details about the "old" one ... > Perhaps it already does so. If not it should at > least unplumb one connection to prevent the interference issues the > James Carlson was talking about, or at least give warning messages about > it. If we want to make it even more user friendly it could also have > monitoring features (such as /sbin/route monitor) and offer some > troubleshooting functionality or even warn about buggy drivers such as > the rge driver. That sounds backwards to me. If a buggy driver exists, then the bugs should be fixed, or the driver should be discarded. There's no reason on Earth to have some other bit of software "warning" users about someone else's software design failures, whether real or otherwise. At best, that other software would just become a repository of uselessly independent misjudgment -- as new, unknown buggy drivers are written and old ones are repaired. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] CIFS performance issues
Robin Axelsson wrote: > On 2012-01-27 15:32, James Carlson wrote: >> What NWAM is supposed to do is configure only one usable interface >> (guided by user selection criteria) for the system. The fact that you >> got multiple interfaces configured is indeed an anomaly, and one I can't >> explain. I don't know how you got there in the first place. It >> shouldn't have happened. > > I don't agree with you on that. Many motherboards come with dual > ethernet ports (i.e. dual NICs, I have counted the chips myself) and it > is not uncommon with laptops with one wired ethernet interface and a > wireless one. So as you said, there is the potential risk of > interference between the two interfaces even though one may not even be > connected. Don't agree how? NWAM's original mission in life was to make sure that only one interface was configured at a time, regardless of how many might be available. I'm pretty darned sure that's true, because I was involved in that project. That's sort of the whole point. NWAM looks over the available interfaces, figures out which ones are usable, then applies a set of policies to determine which one of all of those will be used. It then disables the others and properly configures the rest of the system to use that one chosen interface. If conditions change, then it reevaluates the situation. The canonical example would be a laptop with wired and wireless interfaces. The default rule would be to use wired if it's connected and working, and otherwise use the wireless interface. Not both at any one time. Things changed a bit in the next incarnation of NWAM, and I wasn't as in touch with that one. However, the fundamental design goal of producing a working configuration -- and avoiding known unworkable configurations -- wasn't abandoned. So, what you saw was either a bug or a misconfiguration of some sort, and you'd need to find someone who knows more about that second NWAM. >> That sounds backwards to me. If a buggy driver exists, then the bugs >> should be fixed, or the driver should be discarded. There's no reason >> on Earth to have some other bit of software "warning" users about >> someone else's software design failures, whether real or otherwise. At >> best, that other software would just become a repository of uselessly >> independent misjudgment -- as new, unknown buggy drivers are written and >> old ones are repaired. >> > > True, but what do you do when *all* you've got is a buggy driver that > _may_ work well on your system? Either you use the driver or you go get > a network card that is proven to work well with Solaris/OpenIndana. The > thing is that a substantial part of the development of OI depends on the > charity of willing developers and their spare time, so you have to make > the best out of what you have at your disposal. I think we have differing viewpoints on system architecture. To me, it would be a very poor design choice to embed detailed knowledge of some driver writer's parental marital status into an independent part of the system. If all compromised drivers exposed a "I'm potentially garbage" flag, then, fine, that independent part could read that flag and do whatever it wants based on it. But merely reading the letters "rge" and deciding to impugn the connection based on some history or accusations strikes me as untenable. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] CIFS performance issues
Robin Axelsson wrote: > On 2012-01-27 16:45, James Carlson wrote: >> Robin Axelsson wrote: >>> On 2012-01-27 15:32, James Carlson wrote: >>>> What NWAM is supposed to do is configure only one usable interface >>>> (guided by user selection criteria) for the system. The fact that you >>>> got multiple interfaces configured is indeed an anomaly, and one I >>>> can't >>>> explain. I don't know how you got there in the first place. It >>>> shouldn't have happened. >>> I don't agree with you on that. Many motherboards come with dual >>> ethernet ports (i.e. dual NICs, I have counted the chips myself) and it >>> is not uncommon with laptops with one wired ethernet interface and a >>> wireless one. So as you said, there is the potential risk of >>> interference between the two interfaces even though one may not even be >>> connected. >> Don't agree how? > > That systems with multiple interfaces are an anomaly, but maybe that's > not what you meant. Likely not, as multiple interfaces were exactly the reason that NWAM was invented in the first place. Without multiple interfaces, there's not a whole lot of need for something like it. The primary use-case for NWAM was a laptop with wired and wireless, and being able to switch between them when advantageous without having to get the user involved. >> If all compromised drivers exposed a "I'm potentially garbage" flag, >> then, fine, that independent part could read that flag and do whatever >> it wants based on it. But merely reading the letters "rge" and deciding >> to impugn the connection based on some history or accusations strikes me >> as untenable. >> > > The only opinion that I have is that it should work and reliably so. The > rge driver is apparently buggy and that's what people say about it in > mailing lists. It is included with the OI distribution/repository. If I > had the time and knowledge I would try and fix it myself but > unfortunately I don't. That's all well and good, but, as I was saying, I don't agree that modifying NWAM (or any other part of the system for that matter) to disparage particular drivers is a good thing at all. At a minimum, the energy spent in creating the illuminated manuscript of "bad" drivers would be better spent debugging and fixing the darned things. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Crossbow performance & bit rot
Jason Matthews wrote: > > So I have determined the trigger event for the "resets" in the response > times. It appears that there is some sort of memory leak in the kernel. When > memory utilization gets very high, I am not sure how high but it is around a > few hundred bytes on the freelists with zfs data near zero, the reset cycles > start on the vnics. If it really is a memory leak (as opposed to just a lot of memory legitimately in use), then it should be possible (albeit slightly painful) to find out where it's going. Putting "set kmem_flags=0xf" in /etc/system will cause the kernel memory allocator to keep track of allocations. You can then panic the system (as in "reboot -d"), get the kernel dump up in mdb, and use "::findleaks" to discover what's leaking memory. It's possible that this is related to zero-copy issues that cause dblks to get held down for a long time. I think there are tunables that disable the zero-copy optimizations, but I don't remember what they are. At least with some of the bugs I've seen historically in this area, the toxic behavior is to have some application that has a socket or DLPI stream open, but that doesn't bother reading from the socket. A large number of buffers can accumulate on an unread stream, and if enough of them get stuck there, you can end up with a pretty sick system. It's also possible that the causation runs the other way -- that whatever causes the problem to happen (a packet storm of some sort?) also happens to cause a large amount of kernel memory to be allocated. > I suspect excessive memory allocation and eventual starvation have a lot to > do with the weird symptoms. I wonder if the memory leak is an independent > process from the network issue or if they are directly related in some way. It's possible that they're related. It sounds to me like this is a pretty good clue. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] intermittent CIFS loss, spontaneous-reboot with OI148/151a and IBM Megaraid M5015?
On 02/01/12 03:29, Ong Yu-Phing wrote:
> We've a number of IBM 3630M3 servers, equipped with BBU M5014/5015s, running
> as CIFS server, with a mixture of OI148 and OI151a. Nothing fancy (no dedup,
> no compression), just a pool of mirrored disks aka RAID10, with CIFS access
> authenticated via MS AD.
>
> Intermittently, CIFS/SMB will go down, sometimes this can be restored via
> restarting the smb service ("enable -r smb/server"), other times it
> necessitates a server reset ("svcs | grep smb" shows that smb/server has an *
> next to it).
If you do "svcs -xv", it should show references to log files for the
services that are in trouble. For smb/server, I'd expect that to be
/var/svc/log/network-smb-server:default.log. Examining that file would
be a good first step here.
Also, it's common for services to log via syslog. /var/adm/messages
might be a good place to start there.
> And one of the servers (always the same, so far...) will intermittently
> reboot (more frequently than the SMB service going down). Sometimes in the
> middle of the day, sometimes in the evening (once it was around 6pm). This
> particular server will reboot and come back up without much delay, and the
> pool and zfs shares come back online fine.
Spontaneous reboot has to be either a kernel panic or a hardware
problem. "dumpadm" should tell you where the kernel dumps are going --
the "savecore" directory; usually /var/crash. Look for files there.
Running mdb on the files and using ::status and ::stack commands might
give a good enough signature that someone could identify the cause.
(I'm not a CIFS expert, but if you gather some basic log information
about the problem, I imagine one may be able to help.)
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Please stop retrofitting packages to require live images
On 2/17/2012 8:47 PM, Jason J. W. Williams wrote: > This is a huge issue for Chef and Puppet. The reason is that when pkg > creates a new BE for a package, Chef/Puppet make the configuration > file changes in the currently live BE. When you reboot, you end up > with an inconsistent environment missing all of the changes Chef > deployed simply because pkg decided a new BE was required. So far > I've just been culling those package from Chef's control that cause > the issue, but GCC is not one I can do that with. Rather than hacking around the problem by eliminating the useful BE creation process, why not fix the broken Chef/Puppet behavior? Modifying the current configuration makes no sense here. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Upgraded OI to oi_151.1.2, suddenly there's no default route???
Hans J. Albertsson wrote:
> I had to add it manually. What gives?
Dunno. It's hard to see your network from here.
How are your network and system configured? Are you using DHCP or
manually configured ("static") addresses? If manual addresses, are you
using ICMP Router Discovery, RIP, or some other routing protocol on your
network?
Are you using the default NWAM or some other configuration? Have you
looked at the system log files? If so, what do they say? What does
"svcs -xv" say?
In general, DHCP can (but is not obligated to) provide you with a
default route. ICMP Router Discovery can also do that. RIP-2 and OSPF
can do the same job, but are much more flexible and can provide
arbitrary network and host routes as well. If you don't use any of
those, then you have to configure the default route manually, along with
some way to make it persist.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Upgraded OI to oi_151.1.2, suddenly there's no default route???
Hans J. Albertsson wrote: > Manual, simplest possible setup, no RIP... Using "/etc/defaultrouter" or using "route -p add default" in order to establish the original route? Or perhaps some other mechanism? If you used a simple "route add" at some point and then rebooted, that's not permanent. > It was just that I went back & forth between oi151a and oi151a2, and the > route was there in 151a, and wasn't there in 151a2... BUT that can have > multiple explanations, I suppose. > > I was wondering if there is any change specific to 151a2 that could or > should have this partic consequence. > > No matter, route add default did the trick. > > Funny bit is that the default route was obviously there for a minute or > two (things happened with mail that would require a default route), then > disappeared. So I'd just like to understand. > > Still thanks for your patient interest.. :-) If it was there and then went away, then something must have removed it. If you're able to reproduce the problem, then running "route monitor" and directing the output to a file will be helpful. It should identify the process that is removing the route, which will then help focus the issue. What about logs? -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] etherstub and bridge
On 2/24/12 8:06 PM, Anil Jangity wrote: > I tried to setup a etherstub and a vnic. I then tried to setup a bridge > between that and the physical interface, as follows: > > LINKCLASS MTUSTATEBRIDGE OVER > igb0phys 1500 up zbridge-- > igb1phys 1500 up -- -- > workswitch0 etherstub 1500 unknown zbridge-- > work0 vnic 1500 unknown -- workswitch0 > zbridge0bridge1500 up -- workswitch0 igb0 Perhaps a dumb question here, but why would you do that? The whole point of an etherstub object is that it's not connected to the outside world. And if you want a connection to the outside world, why not just create the vnic on top of a real link? That aside, I think you might get further using 'dladm create-simnet' rather than an etherstub. A simnet is a simulated Ethernet interface. As for the "STATE unknown" bit, I believe that's because etherstubs don't have physical links and thus don't have physical link status. It's probably harmless. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] etherstub and bridge
On 2/26/12 1:30 PM, Michael Stapleton wrote: > Then you need to route, not bridge. Exactly. For what it's worth, even if what the original poster were doing with etherstubs had worked, it wouldn't have achieved his stated goal, because broadcasts would certainly have come through -- that's sort of the definition of bridging. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Per packet load balancing in openindiana
Hans J Albertsson wrote: > Is it at all possible to do per packet load balancing in openindiana? > > ie can one do > dladm create-aggr -P -l igp0 -l igp1 1 > and somehow manage to get (near) 2gb for, say, a zfs send over aggr1? > Or would one have to write some session-splitting sw to pipe the data thru? Not without hacking the kernel drivers. The system quite intentionally doesn't support such a thing, because it usually results in substantially degraded performance due to both packet reordering and (on the receiver's side) interrupt, cache, and lock contention. I wouldn't be much surprised, with high-speed links, to see the performance drop to less than what you get by putting all the traffic over one link. But if it's worth it to you to try, then by all means, change the driver and publish the results. ;-} -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] nfs mounting and cascading dataset access?
Scott LeFevre wrote: > I have a pools setup named tank1 with multiple datasets/filesystems > defined. At the top, I have tank1/media followed by tank1/media/Video > and tank1/media/Music. I've setup tank1/media as a nfs share > (e.g. /export/media) and can mount it from other systems. When I try to > access media/Video from the nfs client, it shows an empty directory. > (From the oi 151a2 host, everything shows up locally.) I can mount > tank1/media/Video directly from the nfs client and everything shows up > as it should. > > Is there a way to make this work where I expose just tank1/media as an > nfs export and can access the underlying datasets/filesystems (e.g. > Video and Music)? This isn't really a special issue with ZFS. NFS has always done exports by file system. If you have /foo and /foo/bar, and /foo/bar is a mount point for some other file system, then exporting /foo does not give clients access to the contents of /foo/bar, because there's no way to cross the file system boundary. Instead, clients looking at /foo/bar will see there whatever is actually in the /foo file system -- probably just an underlying empty directory used as the mount point. What you can do is set "sharenfs=on" (or some list of NFS options instead of just "on") using the zfs command on tank/media, and all of the filesystems under that point will inherit this setting. That means that clients will see separate NFS exports for each of the underlying datasets -- one for Video and one for Music in this case. Automount, of course, is your friend. ;-} -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] IPv6 DHCP
russell wrote: > Hi, > > I have configured my OI_151 installation with a static IPv4 address and > would like to configure IPv6 to work with DHCP but the notes I've found > appear to require nwam to be running but I have disabled this. Might be helpful to provide a link or a copy of those notes. They don't sound accurate. > I would appreciate a suggestion on how to configure OI manually to only > use DHCP for IPv6. I would like to have the IPv6 use both SLAAC and a > DHCPv6 server. The standards-compliant way to do this is to plumb up one or more IPv6 interfaces and make sure that svc:/network/routing/ndp:default is enabled. When you do that, in.ndpd(1M), the IPv6 autoconfiguration daemon, will run. That daemon will listen to ICMPv6 Router Advertisement messages. If the messages say that a given prefix uses DHCPv6, then it will automatically start dhcpagent(1M), and that will configure the address. (Unlike DHCPv4, the prefix length -- aka "subnet" -- comes from the RA, not from the DHCP server. Only the address itself comes from DHCP. It's how DHCPv4 should have been done ...) If you have one or more IPv6 routers, and they all say that you shouldn't run DHCPv6 on a prefix, then it will not be run. If you have no IPv6 routers (a bit of a degenerate case in the standards), then DHCPv6 is required to run, and the system will run it, but it's almost completely useless. See in.ndpd(1M), dhcpagent(1M), and ifconfig(1M) for details. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] IPv6 DHCP
Richard L. Hamilton wrote: > You have (service names from an earlier release, may not be identical): > EITHER > svc:/network/physical:nwam > OR > svc:/network/physical:default > > Only one of those can be used. The first tries to Do The Right Thing, > automagically (including DHCP and all that); the second is for a > straightforward static configuration. There's a little bit of confusion here. With IPv4, DHCP is invoked either by manual configuration or by NWAM, because there's no standard IPv4 mechanism that tells a node whether it should run DHCP on a given network. With IPv6, DHCPv6 is invoked by the actions of in.ndpd, because there's a standard Router Advertisement based mechanism that tells a node whether DHCPv6 is in use. For v6, it should have nothing to do with NWAM. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] IPv6 DHCP
Robbie Crash wrote: > Is configuring these things through nwam not the /proper/ way to do things? > I don't understand why all the help pages say to disable nwam for static IP > configuration. That part's generally correct. To do static IP configuration, you should disable NWAM. But it has little to do with how DHCPv6 works. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] USB audio input support in OpenIndiana
Dave Koelmeyer wrote: > Anyone? "It depends." The usb_as and usb_ac drivers generally handle USB audio streaming input and output devices. But not all hardware devices implement the standards properly or are bound by a driver. If you're finding that plugging in this device doesn't result in a new audio device being plumbed, then that's probably an existence proof that it's not one of those standard devices. I wouldn't be surprised to find that a webcam with microphone has a non-standard class. You should be able to find the device by wading through the "prtpicl -v" output or in the syslog messages. A key clue is seeing "usb_mid" attaching to the device when it's inserted. That means that no standard class driver works on that device, and you're getting the "generic" driver that allows user-space implementations. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Spontaneous server reboots
Martyn Klassen wrote: > I have an OI server running oi_151a2 that is experiencing random reboots. I > cannot seem to find any indication of why they are occurring in any of the > logs, and there are no core dumps even though I have core dumps enabled. > > # coreadm Core dumps are related to faults in user-level processes. If you're seeing reboots, user-level processes are (almost certainly) not to blame. Instead, you're very likely seeing kernel panics. The utility you want is "dumpadm". Typically, messages related to panics will show up in /var/adm/messages, and the files are dumped in /var/crash. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Access to /etc on a pool from another system?
Reginald Beardsley wrote: > I'm trying to access the /etc files from another system on which I installed > OI 148. I can import the pool as fpool and can access /mnt/fpool & > /mnt/export. > > But for the life of me I can't figure out how to get to the /etc filesystem > in fpool. All the examples google turns up point to things I already know > how to do (e.g access fpool/export) > > I *think* I've done this before, but don't find any notes in my logbook Can you do "zfs list -r fpool"? Normally, this is done with 'beadm'. Because you just imported the pool, I suspect that won't work, and you'll have to change the fpool/ROOT/ mount point to something temporary, and then change it back to "/" when done. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Access to /etc on a pool from another system?
Reginald Beardsley wrote: > This is in response to all. > > rhb@openindiana:~# zfs list -r fpool > NAME USED AVAIL REFER MOUNTPOINT > fpool 6.97G 105G45K /mnt/fpool > fpool/ROOT 3.72G 105G31K legacy > fpool/ROOT/openindiana 3.72G 105G 3.60G /mnt > fpool/dump 479M 105G 479M - > fpool/export2.24G 105G32K /mnt/export > fpool/export/home 2.24G 105G32K /mnt/export/home > fpool/export/home/rhb 2.24G 105G 2.24G /mnt/export/home/rhb > fpool/swap 544M 105G 523M - What does "df /mnt" say? With that layout, I'd expect /mnt/etc to contain the "/etc" from that system. If it doesn't, then perhaps it's as simple as the strange "/mnt/fpool" entry causing the "/mnt" mount to fail. Where there errors when you mounted these file systems? Perhaps one saying that the system was unable to mount fpool/ROOT/openindiana because the "/mnt" directory was not empty? -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Access to /etc on a pool from another system?
On 03/19/12 17:16, Reginald Beardsley wrote: > I would expect /mnt to contain /mnt/etc also. > > rhb@openindiana:~# df /mnt > / (rpool/ROOT/oi_151 ):360070851 blocks 360070851 files > rhb@openindiana:~# Well, there's your problem. /mnt isn't mounted. All you're looking at is your native rpool root file system, not the one in fpool. > Now that I think about it, the problems seemed to revolve around the special > way that zfs and beadm treat /. Other than being "canmount=no", it's not too special. Just look at the ZFS attributes; they tell you everything you might want to know. zfs get -o all all fpool/ROOT/opensolaris -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Access to /etc on a pool from another system?
Reginald Beardsley wrote: > Well, not quite. Look at my more recent post. I'm not yet 100% sure of the > details, but it revolves around how zfs & be interact. And most likely the > namespace collision between rpool & fpool. However, you can see & manipulate > things w/ beadm that you can't access w/ zfs. > > There are doubtless sound reasons for this hidden in the implementation > details. > > fpool was mounted under /mnt, it just wasn't the portion of fpool I wanted > to access. My observation of df over the past few years is that it doesn't > quite grok zfs yet. I find myself using "zfs list" quite a bit. > > In any event, the confluence of comments got me to the solution. Which is > what matters. None of that rings true to me, but if it's working for you, that's great. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Routing and avahi questions
Gary Gendel wrote: > I have my OpenIndiana box providing wan/lan routing with firewall/nat. > I was having some really slow wan performance so I started digging in. > The performance issue was a compromised user account and a machine on > the internet downloading everything from the account, pegging my upload > bandwidth quota. > > However, in my investigations, I've noticed a few things that was > wondering about... > > Using snoop, I'm seeing a steady flood of ARP request broadcast from my > ISP. As I only have one IP address/MAC allowed does it make sense to > filter out the "not-for-me" requests or doesn't it really matter? Is > there even a way to do this without breaking the WAN-side? I think that it's likely to be more work to filter these out than it is to let the system properly discard them as part of ARP processing. And if the filtering is not done right, there are certainly some correctness risks involved -- a "not for me" query that nonetheless indicates a source IP/mac mapping change actually must be processed, at least per the RFCs. But it's your machine. If you can figure a way to filter them, and if you can measure the result and show that it's worthwhile, go for it. I just think you're barking up the wrong tree. > The second question is that I noticed that Avahi has bound itself to > both my WAN and LAN nics. Is there a way to limit this to the LAN nic? > Does mdns have a similar issue? I discovered this by running "bssh" and > seeing the service both on my bge0 (WAN) and bge1 (LAN) nics. These should be the same thing -- just block UDP port 5353 in the places where you don't want Avahi/mDNS stuff to leak. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] REALTEK network card driver issue
mountpe...@lavabit.com wrote: > I need some info on the subject of REALTEK card support in openindiana. > Currently, when I launch driver & device detection app. My realtek card > driver is red and "searching" message appears. However I do have a "wired" > connection with ip notification from network manager. I probably can't help with that part. However, I'd expect that's just a problem in the device detection application, and not a problem with the interface. > Yesterday I tried to set up my pppoe connection (I use dsl modem with > pppoe to connect to the Internet), I could not up the connection. After > issuing "/usr/bin/pppd call myisp" command, I'm quickly returned to promt > without any signs of being connected (pppoe connection does require some > seconds to be set). "ifconfig sppp0" does show the connection was set and > my ip. My card for pppoe connection is rge0. I'm not sure but seems like > my card id is RTL8168/8111. > Anyway, is it a driver issue or something else? > I've being doing the configuration according to this guide > http://www.phildev.net/solaris/spppoe.html. I'd think that if "ifconfig sppp0" shows that there's a connection, then at least some of the negotiation went well. But that's a guess based on just the text you've written rather than hard data. It would be nice to see debug information. You could get that with: /usr/bin/pppd call myisp debug updetach That should dump the negotiation information to your screen and should show how PPP is getting along. Posting it here may be useful to anyone who might be able to help out. Anything you can post about the diagnostics and information produced by the system -- syslog output, command output, error messages, network configuration (netstat -ni, netstat -nr, ifconfig -a) -- would probably be helpful in chasing down problems. Again, posting that information somewhere would be a good idea. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
