Hi, Is there any reason why names containing "-" are not allowed? For example: # dladm create-etherstub -t switch-1 dladm: invalid link name ''switch-3'' same for vnics, etc. Allowing "-" would be very user friendly I think. ? -- Robert Milkowski http://milek.blogspot.com -- This message posted from opensolaris.org
Robert Milkowski wrote:> Hi, > > Is there any reason why names containing "-" are not allowed? > For example: > # dladm create-etherstub -t switch-1 > dladm: invalid link name ''switch-3'' > > same for vnics, etc. > > Allowing "-" would be very user friendly I think. > > ? >As the dladm(1M) man page says: link A datalink, identified by a name. In general, the name can use any alphanumeric characters (or the underscore, _), but must start with an alphabetic character and end with a number. A datalink name can be at most 32 charac- ters, and the ending number must be between 0 and 4294967294 (inclusive). The ending number must not begin with a zero. Datalink names between 3 and 8 characters are recommended. The underlying reason is that using a restricted character set here allows us to combine these names with other syntaxes more easily. For example, you could include a link name as part of an SMF URI, separated from other parts of the URI with dashes, and you''d be guaranteed that no valid link name could ever cause your parsing to come to grief. (That''s just one example; there are many.) Yes, it''s a trade-off between being "user friendly" and being "way too flexible for our own good." -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
Thank you for your reply. Still requiring that it must end with a number seems a little bit too strong. Same for "-" - it shouldn''t break SMF URIs and colon could be used instead of dash in service names which probably would be more consistent with other services (so the device would be an instance name and not a separate service). Is there anything else? i understand the need to a limited set of allowed characters but maybe allowing "-" would be actually fine? It is a very common character being used in host names, network names, etc. and having an ability to exactly match the names would be nice. -- Robert Milkowski http://milek.blogspot.com -- This message posted from opensolaris.org
Robert Milkowski wrote:> Thank you for your reply. > > Still requiring that it must end with a number seems a little bit too strong.Legacy. Data link names are used by default for IP interface names, and IP interfaces of the form "foo0" are the norm. It''s at least theoretically possible to have interfaces like "bar", but the risk of breaking software that thinks it knows something about how all interfaces are named is quite high, especially given that no other Unix-like platform appears to do anything like that.> Same for "-" - it shouldn''t break SMF URIs and colon could be used instead of dash in service names which probably would be more consistent with other services (so the device would be an instance name and not a separate service).Colon separates the components of the URI. That''s a good reason _not_ to allow colons in data link names. Another (somewhat obvious) reason is that IP uses colons to separate the interface name from the logical interface number. See ifconfig(1M).> Is there anything else? > > i understand the need to a limited set of allowed characters but maybe allowing "-" would be actually fine? It is a very common character being used in host names, network names, etc. and having an ability to exactly match the names would be nice.Given the context, I''m not sure I agree. I do agree that there ought to be a more flexible and friendly way to refer to IP interfaces, perhaps something akin to SNMP''s ifAlias (RFC 2863). -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
>Legacy. Data link names are used by default for IP interface names, and >IP interfaces of the form "foo0" are the norm. It''s at least >theoretically possible to have interfaces like "bar", but the risk of >breaking software that thinks it knows something about how all >interfaces are named is quite high, especially given that no other >Unix-like platform appears to do anything like that.Well we could put warning in documenatation that it is recommended to append a number as some software may break. When it comes to other platform at least Linux allows network device names with "-" and doesn''t require a name to end with a number, try: linux> ip link set eth1 name test-name and it will work perfectly fine. IMHO these two restriction in the OS are really irritating and force users to come up with some cryptic names.>> Same for "-" - it shouldn''t break SMF URIs and colon could be used instead of dash in >>service names which probably would be more consistent with other services (so the >>device would be an instance name and not a separate service).>Colon separates the components of the URI. That''s a good reason _not_ >to allow colons in data link names.I didn''t mean using : in data link names rather that dash should be ok and other character could be used to append data link names in smf URI if needed (or a data link name could be an instance for a service therefore :). -- This message posted from opensolaris.org
Robert Milkowski wrote:>> Legacy. Data link names are used by default for IP interface names, and >> IP interfaces of the form "foo0" are the norm. It''s at least >> theoretically possible to have interfaces like "bar", but the risk of >> breaking software that thinks it knows something about how all >> interfaces are named is quite high, especially given that no other >> Unix-like platform appears to do anything like that. > > Well we could put warning in documenatation that it is recommended to append a number as some software may break. > > When it comes to other platform at least Linux allows network device names with "-" and doesn''t require a name to end with a number, try: > > linux> ip link set eth1 name test-name > > and it will work perfectly fine. > > IMHO these two restriction in the OS are really irritating and force users to come up with some cryptic names.As a user, that makes sense. As a system designer, I don''t think it does. Allowing this means that we just cannot predict what users will do -- they''ll be *allowed* to use the full range of characters, even if some are "not recommended." Thus, when designing new subsystems and features, we''re hemmed in by these freedoms we grant to users. There''s no free lunch. Historically, users could not set interface names at all. In enabling a new feature like this, I think it''s very important not to throw the doors wide open at first. You can widen them (allowing more characters) if it''s eventually found that no feature in the system will suffer, but you just cannot close them (restricting characters that were once allowed) later. There''s a PSARC case that covers these issues in some detail, but I can''t recall the number off-hand. Perhaps someone else on the list remembers or could grep the database ...>>> Same for "-" - it shouldn''t break SMF URIs and colon could be used instead of dash in >>service names which probably would be more consistent with other services (so the >>device would be an instance name and not a separate service). > >> Colon separates the components of the URI. That''s a good reason _not_ >> to allow colons in data link names. > > I didn''t mean using : in data link names rather that dash should be ok and other character could be used to append data link names in smf URI if needed (or a data link name could be an instance for a service therefore :).Still, embedding those names is simpler if you know that they cannot contain anything surprising. svc:/this/that-myif0:default isn''t going to become svc:/this/that-those-the-other:default due to wackiness on the part of the user. For what it''s worth, I think you''re looking at this at far too low a level. Individual datalinks are not really "user" objects. They''re administrative features, where technical restrictions are a lot more reasonable to accommodate. For real user objects, I *still* agree that there should be a more flexible way to refer to things in the system. I just don''t think that''s this droid. -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
it also seems that FreeBSD allows "-" to be used in a name and doesn''t require interface name ending with a number. -- This message posted from opensolaris.org
>As a user, that makes sense. As a system designer, I don''t think it >does. Allowing this means that we just cannot predict what users will >do -- they''ll be *allowed* to use the full range of characters, even if >some are "not recommended."I''m not arguing to allow a full character set rather to: 1) remove restriction that interface name has to end with a number 2) allow one more character in interface names: "-">For what it''s worth, I think you''re looking at this at far too low a >level. Individual datalinks are not really "user" objects. They''re >administrative features,What about being admin-friendly then? And about the stigma which sticks to Solaris that it is not flexible and hard to manage? Both Linux and FreeBSD don''t have the two restrictions I''m talking about. While I agree that there needs to be a line drawn somewhere and one needs to be cautious about allowing extra characters (see ps.) I still don''t think that these two particular restrictions make sense and are definitely irritating and provide worse user/admin experience than on other UNIX-like platforms. I guess that most sysadmins would be much happier if you would restrict "_" instead of "-" (not that I''m arguing for restricting "_"). ps. I''m not arguing about going wild like FreeBSD has when it allows "%$" characters in device names and then startup scripts fail... that''s the other end of a spectrum -- Robert Milkowski http://milek.blogspot.com -- This message posted from opensolaris.org
On 07/31/09 08:20, James Carlson wrote:> There''s a PSARC case that covers these issues in some detail, but I > can''t recall the number off-hand. Perhaps someone else on the list > remembers or could grep the database ... > >PSARC/2006/499 Clearview Nemo unification and vanity naming Kais
Robert Milkowski wrote:>> As a user, that makes sense. As a system designer, I don''t think it >> does. Allowing this means that we just cannot predict what users will >> do -- they''ll be *allowed* to use the full range of characters, even if >> some are "not recommended." > > I''m not arguing to allow a full character set rather to: > > 1) remove restriction that interface name has to end with a number > 2) allow one more character in interface names: "-"Sun actually did consider those things at one point in the not-too-distant past, and rejected them for essentially the reasons I outlined -- too much flexibility means that future projects are much harder to do. And pointless flexibility is a curse.>> For what it''s worth, I think you''re looking at this at far too low a >> level. Individual datalinks are not really "user" objects. They''re >> administrative features, > > What about being admin-friendly then? And about the stigma which sticks to Solaris that it is not flexible and hard to manage? Both Linux and FreeBSD don''t have the two restrictions I''m talking about. > > While I agree that there needs to be a line drawn somewhere and one needs to be cautious about allowing extra characters (see ps.) I still don''t think that these two particular restrictions make sense and are definitely irritating and provide worse user/admin experience than on other UNIX-like platforms. > > I guess that most sysadmins would be much happier if you would restrict "_" instead of "-" (not that I''m arguing for restricting "_"). > > ps. > I''m not arguing about going wild like FreeBSD has when it allows "%$" characters in device names and then startup scripts fail... that''s the other end of a spectrumThat''s just one illustration of the problem. From the other side of the equation, if you''re a responsible developer, you''ll want to make sure that the design of your new feature doesn''t cause breakage as long as the users and administrators stayed inside the documented guidelines. Leaving such things to chance is completely unacceptable. Thus, drawing these things narrowly is a *good* thing, because it plans for the future. All that said, email is worthless. Write some code. If you really want to change this, then modify the code and work through the review process. Frankly, I don''t think these restrictions actually make Solaris in any way hard to manage, so I can''t support your quest, but don''t let that stop you. -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
> I''m not arguing to allow a full character set rather to:> > 1) remove restriction that interface name has to end with a number That would be really problematic: there are lots of pieces of code that expect datalinks and IP interfaces to end in a number. > 2) allow one more character in interface names: "-" This would be more feasible but still somewhat risky for the reasons that Jim already covered. Note that as part of Clearview IP Tunneling, Seb will be expanding the datalink character set to include ''.'', which is a useful separator -- and since ''.'' has long been allowed for IP interfaces, we have confidence that it will work without incident. Further, ''_'' is already in the character set. > I guess that most sysadmins would be much happier if you would restrict > "_" instead of "-" (not that I''m arguing for restricting "_"). If I could go back in time to 1991, I''d love to change that. In the meantime, we have built up 18+ years of software that may rely on the documented set of characters, so expanding it comes with risk of breaking that software. -- meem
> IMHO these two restriction in the OS are really irritating and force users to come > up with some cryptic names.@milek As a long time Linux and BSD user, I don''t think these Solaris naming conventions are irritating at all. What can be irritating is having your network scripts and programs break out of the blue because some maverick wants to overturn 30+ years of UNIX networking conventions just because he can, and it''s triply irritating if this breaks network scripts in a "mission critical" operating system like Solaris that is used to control very important things like telecommunications, financial transactions, oracle databases, and nuclear weapons payloads. Sometimes it''s better to be safe and just drive the speed limit, brush your teeth, name your network interface in the form "foo0", and follow all of those other annoying rules created by the "man" to oppress us than to risk creating a bug that causes e-bay or AT&T to go down. But then again, in open source projects such as BSD, Linux, OpenSolaris, etc. you are always free to add any features to the existing source code to prove to the community how good you think they might be or even fork the code and compile your own alternate version of the operating system that has those features if you really want them ;-) Just my 2 cents. -- This message posted from opensolaris.org
Peter Memishian wrote:> > I''m not arguing to allow a full character set rather to: > > > > 1) remove restriction that interface name has to end with a number > > That would be really problematic: there are lots of pieces of code that > expect datalinks and IP interfaces to end in a umber. >Are you talking about 3rd party software or a code included with (open) solaris? Can you please give some examples?> > 2) allow one more character in interface names: "-" > > This would be more feasible but still somewhat risky for the reasons that > Jim already covered. >The only reason mentioned was some future use of datalink names with SMF where "-" could be used as a separator in a service name. Perhaps different character can be used? Other than that is there anything else?> If I could go back in time to 1991, I''d love to change that. In the > meantime, we have built up 18+ years of software that may rely on the > documented set of characters, so expanding it comes with risk of > breaking that software. >Perhaps user should be warned then when creating such data links instead of completely forbiding user to do so? Or maybe a future Solaris 10 branded zone should check for it and issue a warning? I''m all for backward compatibility - it helped me some many times but at the same time I;m all for flexibility and allowing users to make a conscious decisions. At the same time I understand that there must be a balance so things won''t get too complicated for other projects. I think that one of the things people like about Linux is the freedome they get with it. It is quite often broken and badly documented but leaves a lot of freedom to sys admin on how to do things. IMHO Solaris could be better here by allowing similar freedom while providing great documentation and recommendation on how to use things. For some people backward compatibility is paramount for others it almost doesn''t matter at all - imho the best way is to make both of them happy by providing the flexibility and documentation warning about consequences. Still it doesn''t mean a total freedom like an example in FreeBSD where it allows characters which break standard system rc scripts - that of course is wrong. -- Robert Milkowski http://milek.blogspot.com
James Carlson wrote:> Frankly, I don''t think these restrictions actually make Solaris in any > way hard to manage, so I can''t support your quest, but don''t let that > stop youI agree with you, maybe I used too strong words. No these two annoyances I mention are not making Solaris hard to manage - they are just annoyances and I still haven''t been convinced they really should be enforced (nor have I managed to convince you the other way :) ). -- Robert Milkowski http://milek.blogspot.com
On 3/08/09 03:54 PM, Robert Milkowski wrote:> Peter Memishian wrote: >> > I''m not arguing to allow a full character set rather to: >> > > 1) remove restriction that interface name has to end with a number >> >> That would be really problematic: there are lots of pieces of code that >> expect datalinks and IP interfaces to end in a umber. >> > Are you talking about 3rd party software or a code included with > (open) solaris? > Can you please give some examples?IPFilter''s logging expects that Solaris network devices will all end in a number and if it doesn''t appear to then it adds one. This comes from a long history of network devices in the kernel where the number indicated the "unit" attached. It used to be that a name "foo0" was constructed using the ''unit'' (or ppa) and the device name, rather than the network interface name as a single entity. The only network interface, across all of Unix, that is enabled by default and does not end in a number is Linux''s loopback (lo) device. Darren
Robert Milkowski wrote:> Peter Memishian wrote: >> If I could go back in time to 1991, I''d love to change that. In the >> meantime, we have built up 18+ years of software that may rely on the >> documented set of characters, so expanding it comes with risk of >> breaking that software. >> > Perhaps user should be warned then when creating such data links instead > of completely forbiding user to do so? Or maybe a future Solaris 10 > branded zone should check for it and issue a warning?What I think you''re missing here is that merely warning users is not enough, if you''re worried about future projects. Any future project that deals with interface names will be *forced* to deal with the fact that these strange characters were allowed to be used, no matter how "discouraged" they might be. The alternative is to ask project designers to build applications that they _know_ will fail. Under what circumstances is that really the right answer?> At the same time I understand that there must be a balance so things > won''t get too complicated for other projects.That''s it exactly. On the one hand, we have completely pointless flexibility. On the other, we have the unknowns of future projects and existing third-party dependent applications. Which one is worth more?> I think that one of the things people like about Linux is the freedome > they get with it.You''ve got the same freedom and the same consequences here. As with Linux, you''re free to change the source and make it do whatever you want.> recommendation on how to use things. For some people backward > compatibility is paramount for others it almost doesn''t matter at all - > imho the best way is to make both of them happy by providing the > flexibility and documentation warning about consequences. Still it > doesn''t mean a total freedom like an example in FreeBSD where it allows > characters which break standard system rc scripts - that of course is > wrong.I don''t think it''s that simple. The freedom that''s being taken doesn''t have effects that are easily or reasonably predictable by those who are taking the chances (in other words: they can''t really know that it "doesn''t matter" unless they''re able to predict the future), and it constrains those who are trying to make the system work better. I know it seems like a trivial thing, but it''s these sorts of trivial things that add up to make a system either stable over time or a crime scene. -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
James Carlson wrote:> Robert Milkowski wrote: > >> Peter Memishian wrote: >> >>> If I could go back in time to 1991, I''d love to change that. In the >>> meantime, we have built up 18+ years of software that may rely on the >>> documented set of characters, so expanding it comes with risk of >>> breaking that software. >>> >>> >> Perhaps user should be warned then when creating such data links instead >> of completely forbiding user to do so? Or maybe a future Solaris 10 >> branded zone should check for it and issue a warning? >> > > What I think you''re missing here is that merely warning users is not > enough, if you''re worried about future projects. >I understand it.> Any future project that deals with interface names will be *forced* to > deal with the fact that these strange characters were allowed to be > used, no matter how "discouraged" they might be. >Well, this is where we disagree as I wouldn''t call "-" a strange character when it comes to host or data link names. And yes, any future project would have to deal with "-" character in data link names which I don''t believe should be a big deal.> The alternative is to ask project designers to build applications that > they _know_ will fail. Under what circumstances is that really the > right answer? >Generally it shouldn''t happen - no argue here. Still "-" is not a strange character when assigning host or data link names. I''m putting hostnames and datalinks together here on purpose - crossbow seems to be ideal to use with different virtualization technologies and it is a common practice to name host names like: node-1, node-2, node-3. Then this is common to name containers (zones, domU, VB, ...) after node name so: node-1, node-2,... then when creating vnic''s and assigning them to these containers it would be nice to be able to use: node-1, node-2, etc. and not node_1 or node1 or... currently this is possible on Linux, FreeBSD but not on Solaris. And again, no, no future project should break just because datalink contains "-" character - it should be taken into account.>> At the same time I understand that there must be a balance so things >> won''t get too complicated for other projects. >> > > That''s it exactly. On the one hand, we have completely pointless > flexibility. On the other, we have the unknowns of future projects and > existing third-party dependent applications. Which one is worth more? >Why is it pointless? For me introducing "." as allowed character is more pointless than "-" (but I would like actually both). Allowing "-" while not critical is definitely not pointless.>> I think that one of the things people like about Linux is the freedome >> they get with it. >> > > You''ve got the same freedom and the same consequences here. As with > Linux, you''re free to change the source and make it do whatever you want. >That''s not true - as on Linux I get that flexibility without changing source code.>> recommendation on how to use things. For some people backward >> compatibility is paramount for others it almost doesn''t matter at all - >> imho the best way is to make both of them happy by providing the >> flexibility and documentation warning about consequences. Still it >> doesn''t mean a total freedom like an example in FreeBSD where it allows >> characters which break standard system rc scripts - that of course is >> wrong. >> > > I don''t think it''s that simple. The freedom that''s being taken doesn''t > have effects that are easily or reasonably predictable by those who are > taking the chances (in other words: they can''t really know that it > "doesn''t matter" unless they''re able to predict the future), and it > constrains those who are trying to make the system work better. > > I know it seems like a trivial thing, but it''s these sorts of trivial > things that add up to make a system either stable over time or a crime > sceneI sympathize with above statement, I really do. I''m not arguing for some strange and really pointless characters to be allowed (like "%" on FreeBSD) but rather perfectly valid request for "-" and the only specific example against it so far was some future project which would like to include data link name in smf manifest and would like to use "-" as delimiter. I would argue to allow "-" in data link names and put some more thought on how to deal with it in that (and other) future projects with it. -- Robert Milkowski http://milek.blogspot.com
On Tue, 2009-08-04 at 04:02 +0100, Robert Milkowski wrote:> > That''s it exactly. On the one hand, we have completely pointless > > flexibility. On the other, we have the unknowns of future projects and > > existing third-party dependent applications. Which one is worth more? > > > Why is it pointless? For me introducing "." as allowed character is more > pointless than "-" (but I would like actually both). Allowing "-" while > not critical is definitely not pointless.Just so everyone''s clear, we''re not introducing "." because we think it would be nice, or that it''s a personal preference or convenience. There is a specific functional need to allow ".", and it''s documented in the Clearview IP Tunneling design document. See section 9.9 of: http://www.opensolaris.org/os/project/clearview/iptun/iptun-design.pdf -Seb
On 08/03/09 18:54, Robert Milkowski wrote:> Peter Memishian wrote: >> > I''m not arguing to allow a full character set rather to: >> > > 1) remove restriction that interface name has to end with a number >> >> That would be really problematic: there are lots of pieces of code that >> expect datalinks and IP interfaces to end in a umber. >> > Are you talking about 3rd party software or a code included with (open) > solaris? > Can you please give some examples?I had done some ''research'' on this when I was working on an initial version of the Crossbow How To Guide, and found it really inconvenient to not use hostname-like names for the data links. At the time I saw what looked like a tie to DLPI, which requires names to end in numbers. I was naming my zones web1, web2, app1, etc, and for multiple VNICs for a zone, thought at web1a or web1-a or even web1-1 might be meaningful names. My customers use names that include three or four letters for the location, maybe some part of the application, and there may be numbers in there as well. Don''t remember so much the -, although that would be nice. I see that any change like this affects multiple areas. Been meaning to bring this up....for months. Steffen> >> > 2) allow one more character in interface names: "-" >> >> This would be more feasible but still somewhat risky for the reasons that >> Jim already covered. >> > The only reason mentioned was some future use of datalink names with SMF > where "-" could be used as a separator in a service name. Perhaps > different character can be used? Other than that is there anything else? > >> If I could go back in time to 1991, I''d love to change that. In the >> meantime, we have built up 18+ years of software that may rely on the >> documented set of characters, so expanding it comes with risk of >> breaking that software. >> > Perhaps user should be warned then when creating such data links instead > of completely forbiding user to do so? Or maybe a future Solaris 10 > branded zone should check for it and issue a warning? > > I''m all for backward compatibility - it helped me some many times but at > the same time I;m all for flexibility and allowing users to make a > conscious decisions. > > At the same time I understand that there must be a balance so things > won''t get too complicated for other projects. > > I think that one of the things people like about Linux is the freedome > they get with it. > It is quite often broken and badly documented but leaves a lot of > freedom to sys admin on how to do things. IMHO Solaris could be better > here by allowing similar freedom while providing great documentation and > recommendation on how to use things. For some people backward > compatibility is paramount for others it almost doesn''t matter at all - > imho the best way is to make both of them happy by providing the > flexibility and documentation warning about consequences. Still it > doesn''t mean a total freedom like an example in FreeBSD where it allows > characters which break standard system rc scripts - that of course is > wrong. > > >
> Well, this is where we disagree as I wouldn''t call "-" a strange> character when it comes to host or data link names. And yes, any future > project would have to deal with "-" character in data link names which I > don''t believe should be a big deal. It can be a big deal -- for instance, see the recent discussion on brussels-dev where we''ve been talking about using "-" as the separator between the IP interface name and the IP address label. In short, namespace restrictions are important when you consider that namespaces often need to be embedded, layered, or nested. For instance, the named object may need to exist in the filesystem, be nested inside a name for another object, or be used as input to another entity like the shell. One namespace''s "generosity" with what it accepts can become a nightmare for a consumer of that namespace. All that said, if I had a time machine, I too would like to have "-" as a valid link name character -- but given that we have "." and "_" today, I''m having a tough time seeing how it''s worth the risk. -- meem
Peter Memishian wrote:> All that said, if I had a time machine, I too would like to have "-" as a > valid link name character -- but given that we have "." and "_" today, I''m > having a tough time seeing how it''s worth the risk.I think the better argument here (rather than just focusing on ''-'') is to talk about DNS requirements. Obviously, IP isn''t the only reason to have datalinks, but it''s an important one, and if people want to set the datalink name to match the host name used as an address on that link, then matching up the character set would be useful. Interestingly, a legal host name in DNS does *not* include ''.'' or ''_'' (underscore), but can include [-A-Za-z0-9] -- in other words, alphanumerics plus the dash character. -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
> I think the better argument here (rather than just focusing on ''-'') is> to talk about DNS requirements. Obviously, IP isn''t the only reason to > have datalinks, but it''s an important one, and if people want to set the > datalink name to match the host name used as an address on that link, > then matching up the character set would be useful. ... are you envisioning that the customer would also append e.g. ".0" to their interface/datalink name? Short of that, ''-'' is not the main stumbling block to having datalink names and hostnames match. -- meem
Peter Memishian wrote:> > I think the better argument here (rather than just focusing on ''-'') is > > to talk about DNS requirements. Obviously, IP isn''t the only reason to > > have datalinks, but it''s an important one, and if people want to set the > > datalink name to match the host name used as an address on that link, > > then matching up the character set would be useful. > > ... are you envisioning that the customer would also append e.g. ".0" to > their interface/datalink name?No. Though that''d apparently now be legal with the new Clearview changes.> Short of that, ''-'' is not the main > stumbling block to having datalink names and hostnames match.I''m not sure I understand what you''re saying. "foo-bar" is a legal host name. However, it''s not a legal datalink name, nor is "foo-bar0" legal, because "-" (dash) is allowed in DNS host names but not in Solaris datalink names. Thus, it''s possible to have a host name assigned that cannot be used as the actual datalink name. I don''t see what "." has to do with it. -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
> "foo-bar" is a legal host name. However, it''s not a legal datalink> name, nor is "foo-bar0" legal, because "-" (dash) is allowed in DNS host > names but not in Solaris datalink names. My point is simple: if you want to use a hostname as a datalink name without applying any transforms, you''ll need to remove the trailing digit requirement from datalink names. If you afford that datalink names need to end in a digit, then you''ll have to do a transform anyway and mapping ''-'' to some other character like ''.'' or ''_'' is at most a minor annoyance. -- meem
Peter Memishian wrote:> > "foo-bar" is a legal host name. However, it''s not a legal datalink > > name, nor is "foo-bar0" legal, because "-" (dash) is allowed in DNS host > > names but not in Solaris datalink names. > > My point is simple: if you want to use a hostname as a datalink name > without applying any transforms, you''ll need to remove the trailing digit > requirement from datalink names. If you afford that datalink names need > to end in a digit, then you''ll have to do a transform anyway and mapping > ''-'' to some other character like ''.'' or ''_'' is at most a minor annoyance.I was using a different assumption, obviously. I was assuming that writing "${HOSTNAME}0" would be a fine compromise. Under that assumption, the lack of ''-'' support is a great annoyance. You end up having to do something like "$(echo $HOSTNAME | tr - _)0", and are probably going to stumble over the difference quite often. If you want to get funky about it, you could just assert that (for a given configuration) you always assign interface-related hostnames such that the final character is "0" ... then it all lines up nicely, except for the "-". But since it''s unclear what the original user had in mind, and how far he wanted this whole thing to go, it''s hard to say. I still don''t see what that had to do with ".". I''m pretty sure that''s not related. Even if you use it, it won''t get rid of that "0" at the end. -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
> I still don''t see what that had to do with ".". I''m pretty sure that''s> not related. It''s not related. My example could''ve used ''_''. -- meem
James Carlson wrote:> But since it''s unclear what the original user had in mind, and how far > he wanted this whole thing to go, it''s hard to say. >Basically quite often I find a host naming convention to be xxxx-1.domain xxxx-2.domain xxxx-3.domain and when using zones usually I try to name a zone xxxx-1, etc. It would be nice to be able to name vnic''s assigned to a zone exactly after a zone name. Sometimes hostnames do not end-up with a number and then again it would be nice to be able to have vnics with exactly the same name. So yes you are right in assessment that allowing vnics the same character set as for dns names would be very nice. -- Robert Milkowski http://milek.blogspot.com
Robert Milkowski wrote:> James Carlson wrote: >> But since it''s unclear what the original user had in mind, and how far >> he wanted this whole thing to go, it''s hard to say. >> > > > Basically quite often I find a host naming convention to be > xxxx-1.domain xxxx-2.domain xxxx-3.domain and when using zones usually I > try to name a zone xxxx-1, etc. > It would be nice to be able to name vnic''s assigned to a zone exactly > after a zone name. > > Sometimes hostnames do not end-up with a number and then again it would > be nice to be able to have vnics with exactly the same name. > > So yes you are right in assessment that allowing vnics the same > character set as for dns names would be very nice.Note that even with "-" as a legal character, there''d be subtle holes in your plan. Although "xxxx-1" is a reasonable host name and potentially a good interface name, the parsing rules for interfaces actually say that interfaces consist of a set of alphanumerics followed by a decimal number, as in this ERE pattern (reproduced from memory; I _think_ it''s complete): ^[a-zA-Z]([a-zA-Z0-9_.]*[a-zA-Z_.]|)([1-9][0-9]*|0)$ Historically, that''s a "driver name" of "xxxx-" and a unit number or PPA of 1 for the previous example. Thus, a perfectly legal and distinct host name of "xxxx-01" would be troublesome. It wouldn''t match that above pattern, and thus wouldn''t be legal at all on a modern Solaris system. On a historical system, it would be treated as exactly equivalent to "xxxx-1" (because "01" is the same when interpreted as a decimal number), and would result in extreme confusion. There still exists code that parses out driver names and unit numbers based on this pattern. As a possibly interesting side note: when the "e1000g" interface was first introduced, we spent a long time hunting down and repairing applications that were damaged by that name. It seems that a lot of people _assumed_ that all driver names would always be simply alphabetic, and not include numerics. Many of them tried to access the "e1000" interface or even "e0" when presented with "e1000g0"! (The former incorrect result comes from thinking that the first numeric identifies the PPA. The latter comes from correctly getting the trailing PPA, but mishandling the leading driver name.) Who knows what those old applications would make of a single interface named "hme0-bge1", which would be legal under the scheme you''ve proposed? Do we know for certain that no application has *ever* created a configuration file or command line argument that uses "-" as a delimiter or special use character? I don''t think I''d want to be making the bet that this has never been done. In other words, I don''t think you can get what you want. You''re under some unobvious constraints no matter what Sun or the OpenSolaris community does with the "-" character, and an exact alignment of DNS host name strings and interface names doesn''t seem plausible. Given that situation, and the known problems that have been encountered in this particular area, I don''t think it''s terribly useful to explore changing the legal character set once again. But, as I said, it''s your project, and the code certainly is changeable, so go for it. :-/ -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>