Re: [osol-discuss] X11 XtAppAddTimeOut is not working properly.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/22/2010 7:01 AM, John Martin wrote: On 11/22/10 12:25 AM, Alan Coopersmith wrote: I believe Linux defaults to a higher resolution timer, something you can enable system-wide on Solaris, ... Just as an experiment to verify, in /etc/system add: set hires_tick = 1 and reboot. Another experiment: With the hires_tick set to the default, try requesting a smaller delay. When you want 10 try asking for 8 or 9. When you want 20 try 18 or 19. If it works you won't need any /etc/system changes. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBAgAGBQJM6saoAAoJEEADRM+bKN5waokH/RJXcoa5doQ63xPI759wgODO 50cLQxTTUNu1H6GaEPGElzSls7++U06fLqowzGQYvb7LCedi9Zx9gSyN3JBdFteq 8kQ+o3UH/h1GFrmG0qPSnwlh/scKUOHzmvV6i9CStAN3Vq54IsWxvMYQ8kUoauCp ogUEYi8SC3aNf4xw7USMvS65IhINJafmjA+N3ufJhOel8qyBCiUSOaHAoqxFqnjU rpYGW4OEUWrvmcV3CKfvA9SlxMmnmSgQ6yswmCJWaVKMKF+5+yZUcO+GzgszY8eU l+rL+hqdy5PlDLh1Ptjkgbt5t/XgG1aNC74IOtlXktMErLw3YpvNgeUAzbWG5Q0= =zkeN -END PGP SIGNATURE- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Update/patch policy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/16/2010 2:04 AM, Ian Collins wrote: On 11/16/10 07:46 PM, Sean M. Brannon wrote: It still does, whether you consider they justify the cost of support only you can say. Alas, it isn't to be I'm afraid. My work environment precludes the attachment to our network of any OS that could not be patched should security vulnerabilities arise. So you wouldn't have been able to attach an OpenSolaris system either. He might have been able to. The OpenSolaris development 2 weel release cycle might have qualified as patches. They always had all the known fixes in them. -Kyle -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBAgAGBQJM4n6oAAoJEEADRM+bKN5wAHIH/jNpGOVyQi0u/bs6k9IqfbS8 f6GyLPrVx8gO7btW1KENcfSBHpHA5sEyuuCO6h74l7Y3OayDgVhe/mci3HIkkItd cerqA/EsqU4gGzs7tc+eMq/8dT39A6fqBv5jysVSi9gHkh4DlhV/gUpstH4TDLgK G5tPtGwTIUX7nVa0SVMIiFigfXfkhbZQZXgHTt8Ueldfd/eud42PmPWltNZ1y6d2 dYsup2n6KXqYusi8NXwv2+EKE+EOPBJ3k+ZN2ts9uySdA+G/O2ytQ+fWAy0fDpE4 Ddw/C6uFN49ep0BKqRpiJRDe6fTGSxdPhvL4MLG3WttAWhQU+Z5PzKSViWobEWo= =hfJZ -END PGP SIGNATURE- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Solaris 11 Express Repository - kinda bare
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/16/2010 2:16 PM, Shawn Walker wrote: You concatenate the two parts and mount the resulting .iso file - just fine. They're actually separate ISO files -- not a physical file split. That's not true. Not according to the page you download them from anyway: The repository image is provided in two parts that must be concatenated together. Please use the following command-line instructions to successfully create a full ISO image that can be burned to a dual-layer DVD or directly mounted using lofiadm. u...@hostname:~$ unzip sol-11-exp-201011-repo-full-iso-a.zip u...@hostname:~$ unzip sol-11-exp-201011-repo-full-iso-b.zip u...@hostname:~$ cat sol-11-exp-201011-repo-full.iso-a sol-11-exp-201011-repo-full.iso-b sol-11-exp-201011-repo-full.iso - -Kyle -Shawn ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBAgAGBQJM4tjeAAoJEEADRM+bKN5wpfEH/j7gxjq6K7y+H+9/Qa+XZ5nf z/P/nY9iGL4qexVKitV+OrEDdJQKwWfz7MPpsCvoSvDTtoKiI40/p1C8IefA3pTS IvFvNU5zMNS+J4X5AnMgoHtDrs2vpObJtcatCLBm5R/FaVamyHXjysckIMGZR0pj UBsbnCmN1QkM/BHVdpn9Buu/wg7DowBYwVzUQecTr76z570K87+LQcOpRP+vgHJg IzbVaDj/eFzn85Iz26ySY40PM5K94tIMzH/qZRXKx1piHJm8GYQb9Gr2SUdvFmiE +khwtaqAWo4tAp7ILMcipcCZUmCsGmwPIm67XnejSGTmlEysZGX62jZV2V+OKO8= =9eBH -END PGP SIGNATURE- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Any opinions on the Brocade 825 Dual port 8Gb FC HBA?
Does OpenSolaris/Solaris11 Express have a driver for it already? Anyone used one already? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Merge other distros to OpenIndiana?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/16/2010 2:03 PM, Dmitry G. Kozhinov wrote: Shouldn't the same packages Oracle publishes for Solaris 11 work on OpenIndiana? - would all the dependencies break? OpenIndiana project should maintain it's own package repository. Solaris 11 packages may occur incompatible - who knows how Oracle will modify the IPS system? An will they drop us IPS source code after Solaris 11 is released? The development of IPS is still continuing as a separate OpenSource project. It has it's own source repository, and updates to it have continued even after the ON consolidation stopped. Actually IPS was listed in the 'leaked memo' as one of the external 'upstream' Open source projects that Oracle would continue to contribute to (like Apaches, etc.). That makes it sound like they view it as something outside of Solaris that they are pulling in, which is weird since they started it and they are (primarily) the only ones developing it. -Kyle Dmitry. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBAgAGBQJMkmwKAAoJEEADRM+bKN5wCwAH/1ky2WhZz24YOkJ1oIXBUhWp IS+x7ClxmNFMaq2mcdK9Uqn/KZIvhd1m1y7vbKEUw1684QMNgSQiA2Fp1rLppLou cOBCWMhiq/G86Jvtxle9o+w6zwy0EVaXjaCLKlGd9JKI76PRhCp0gwrLej3QVZ1g zhaSD7DKsF/r5LZ3AkYvDEOO9CZwGQBDB72WdIcrQNAclqwSeJhkw93POH1Z+6AU h+QMDcd8aCFc70ZGLPaY1Cs7QTQrRlj39B/qROvrDOIV4YPewZmNrV52WjRMjksh 86qseRBFQZv6zYAgGwuhv/qCDjElLZiC+6O2a6ERV/M4aE64QvrD/Coqan05Niw= =M8xR -END PGP SIGNATURE- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Solaris 10,Oracle Solaris Express new license
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/10/2010 6:11 PM, Edward Martinez wrote: It appears this is the license Solaris 11 Express wil be under and it's solaris 10 new license, an OTN lincese. http://c0t0d0s0.org/archives/6891-Licensing-Change-for-Solaris-10-and-Solaris-Cluster.html I find this section of the license even more interesting: Open Source Software Open Source software - software available without charge for use, modification and distribution - is often licensed under terms that require the user to make the user's modifications to the Open Source software or any software that the user 'combines' with the Open Source software freely available in source code form. If you use Open Source software in conjunction with the Programs (or if you plan on licensing your own application under an Open Source license), you must ensure that your use does not: (i) create, or purport to create, obligations with respect to the Oracle Programs; or (ii) grant, or purport to grant, to any third party any rights to or immunities under our intellectual property or proprietary rights in the Oracle Programs. For example, you may not develop a software program using an Oracle program and an Open Source program where such use results in a program file(s) that contains code from both the Oracle program and the Open Source program (including without limitation libraries) if the Open Source program is licensed under a license that requires any modifications be made freely available. You also may not combine the Oracle program with programs licensed under the GNU General Public License (GPL) in any manner that could cause, or could be interpreted or asserted to cause, the Oracle program or any modifications thereto to become subject to the terms of the GPL. They make it sound like they feel threatened by OpenSource software, the GPL in particular. While I have no love for the GPL, I've never thought that any OSS license would create the need for language like that. -Kyle -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBAgAGBQJMi4tRAAoJEEADRM+bKN5wQOoH/0lKaY++68JniCWCmvmse/uc /LmI9BZrjB6bHaWdwW3DufL0Gxt/0R2gviDGzBexMqvIswEOyds3jkkUwKlxQ94H IK+VJenQgsDQ7ZjBdxqMHMxdhNPV7QVcElzioDeWly6MCWKASxvY8tewl04z11Wu a7icqTRx6GcnwYBK0gMdtFfKtGHtPI6BoiaNHqFftPiPdfPIG5rG9ijqs1wuku3J EB1VMwBXYCBsG6EnV0XUcKpy1XSlXEvsedadGvxTXEuqNG4Sl+RTSnfpiJMEN/g0 9ADW6BAiVaErvt5gwSWbctaoyHcSKH7WR2ScRKqdAuVKePjYmBHg8+W62ph7vXM= =f3Ll -END PGP SIGNATURE- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris cancelled, to be replaced with Solaris 11 Express
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/9/2010 9:15 AM, Matthias Pfützner wrote: Remember: Even withe the old E10K, Solaris at GA date was capable to use all that hardware from a single kernel... And that's more than 12 years back... ;-) So, scaling on cores, CPUs and thread is what Solaris still does better than any other big commercial OS on this planet... It never shipped, (well it did kinda, but not in it's full glory) but the group I was in at Sun had developed HW to connect multiple E6K, and E10K machines (up to 16 if I remember correctly) together, and scale a single kernel instance across all of them. There just weren't enough places interested in buying a machine that large. -Kyle -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBAgAGBQJMiOX/AAoJEEADRM+bKN5woh4H/idoRCYR50tb9cSZWu6V3IxQ lCsvEvj/RJ6Ad0DRCFp9IoTiemG9tikyQ0Wn/s1R34DQyTD6qO/+0P31tGYbOtkK 1nG4ikSpyiTJXkovLPd4EuxyqyYfVlL1QOTz9vEhI4nI5iYlzsUMHMlTGfQYRFAK STVweWbiMJChlMvYBxK09k3/+qmn1E1nJHSK+3dVgcaHVBugRefNP/hZA+ORuIOz e8/vk2480/QMPhX0Bhi3MAxNndg6KQ8NlLktPIMvyzoj/p4Ch6n6d4Q8bA69Dulh YkHqG2iYDpavT6ZGF3Xz+Rf/5+xoZuCLQhyJox+rOPT4AZLwSn7IJvvthq0vnFQ= =EOMK -END PGP SIGNATURE- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris cancelled, to be replaced with Solaris 11 Express
On 9/9/2010 9:49 AM, Kyle McDonald wrote: It never shipped, (well it did kinda, but not in it's full glory) but the group I was in at Sun had developed HW to connect multiple E6K, and E10K machines (up to 16 if I remember correctly) together, and scale a single kernel instance across all of them. Sorry, actually, I have the models confused. It was developed for multiple F6000/F6500, and I think it was planned to work in the F15K also. The HW did ship to some limited customers I beleive, but only as a HPC shared memory interconnect, (RSM might have been the product name) between multiple kernels. I'm pretty sure we had the single kernel scaling well in the lab though before the project was scrapped. If anyone cares there was an earlier project to do a similar connection between 4 E6000's, but that was killed when Sun bought Cray, and acquired what became the E10K. After the project for the F series was killed, the same group started working on parts of the system (Millenium/Eagle) that would follow the F series. At one point there was talk of doing it again running 1 kernel on multiple boxes over IB, but that whole system was scrapped in favor of Niagra/Fujistu systems in the short term, and 'ROCK' in the long term... But but ROCK was also scrapped not too long before Oracle bought Sun. As others have said Sun was great as the engineering side of things. Not so great at deciding what to (or not to) engineer, and not the best at marketing the things they did engineer and build. -Kyle There just weren't enough places interested in buying a machine that large. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris cancelled, to be replaced with Solaris 11 Express
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/9/2010 11:42 AM, Octave Orgeron wrote: There was a solution for the Sun Fire 6800-25k servers that allowed you to do this. The name escapes me, but I know Sun had a course for it and sold it to several universities and of course the US government. Basically it consisted of some HBA's and a custom switch. The project name was 'WildCat' - The F6800/6900 (I guess the model numbers were still wrong in my second post - where is my memory going?) were project 'serengeti' and the CPU's were members of the cat family like 'jaguar'. The product was able to do RSM (remote shared memory) between multiple kernels, and SSM (scalable shared memory) between boxes for 1 kernel. As far as I know, while the HW shipped was capable of both, the only SW/drivers that ever shipped were for RSM mode only. Back in the E10k and Exx00 days, this was also doable through extending the UPA bus. This sounds like the earlier project 'WildFire' (for the Sunfire project machines). As I recall it relaced the IO 'blade', and was a custom bus. It may have beta'd to a few places but It never shipped. - -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBAgAGBQJMiQ0RAAoJEEADRM+bKN5wGxAH/17IP5J6FOXr1+jbSjxpYAHA OADCX6JT7YrniLk+RnlvmD1eZIX5QRE9/07AAqP0Bv0G8C8FLWi2Yhm3k88TsfKd KhlRgjt0GqDoVGQTm0+UC9yexRhpdRAIhoMSRdJ4gwv55vhr18czpeeAbMbTw7Ep zTdRgHaHwtAFLVyx33XeBq9ntEfcRaCPZfyBSHuNJXiSY+Bo7obDT5pZ3OrgwdQy XEP8TL2Tqxwm6WmCp5TKpXd6iFVrtD0K05ZeI8M7k89Vebc+umTBHSloLNAfYTUe kIcC2HSksNANZebd/pEYUD7UV022fZavQwciHPkOJR6AFLHps1L2ORH2B8SHs3w= =HCKM -END PGP SIGNATURE- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris cancelled, to be replaced with Solaris 11 Express
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/9/2010 10:27 AM, Matthias Pfützner wrote: No, I was not talking about that, I simply meant: The E10K had 64 CPUs and at GA date, Solaris was ready to use 64 CPUs from a single kernel... Unlike the IBM 795, which can currently have MORE CPUs than AIX is capable of handling... ;-) Yes. I know you weren't talking about that HW. I was taking it further, and adding how much further than that Solaris scaled. The E15K I believe eventually got dual core CPU's and so went 128 cores later. Solaris handled that in stride too. Yes, I know about all those single image things ACROSS boxes, but that's not, what I meant in my post... ;-) Matthias But the WildCat project would have taken 16 F6900's linked together to 768 cores running 1 instance of Solaris. 1 box or 16, when run like that it behaves like 1 box. If you're not in the room looking at the machine you'd never know it wasn't 1 box. I thought the fact that Solaris could scale that far in 2002 or so helped proved your point even further. -Kyle -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBAgAGBQJMiQ8+AAoJEEADRM+bKN5wiNMIALdKqLhWo6o/K7cnidPsho+o Ty4YYsT0QMCSt4Bn2Q7lq5qaQLm8mC7t3Iq3Rb1/h8QLuF1heYdSIeAk7yCHmaUR 2pnPWip5wmWAS4n6eE3DtTzaPIemIzpMZ8e1AOwpguQwCO/uQ6gstufW5hq6lHah r+TxSxvuUo+IC3r8e/Ke0TAcO1rYRH5PD2DDKRHxbadTbXNDsI7euhQEfmjuqzl8 wlF7B70iUH69EeWTZ9JBkq14+0S1BhA0L448Co1a5cnFcwQHBwyXYAhe/N46gaCW XNQ8F6k0uizC3HFCZU3FCPbR8XNEivDr77KmPbppdrLVm1h6yXySs6Qy9D4NC0I= =8NM6 -END PGP SIGNATURE- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Indiana - what comes closest to it?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/2/2010 10:41 AM, Alan Coopersmith wrote: illumos is roughly equivalent to ON by itself. An OpenIndiana distro would have to add the other 80% of the OpenSolaris distro that comes from outside ON/illumos - SFW, X, JDS, etc. Hi Alan, Where can I find a definitive list of what's in the 'etc.' you refer to? I know I need to build ON, SFW, JDS, X, and PKG, but I'm not sure what else there is. I've only just begun, and I was planning on comparing what pkgs get created with those in IN and guessing what else I needed, but if there's a list somewhere, it'd make things easier. -Kyle -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBAgAGBQJMf88QAAoJEEADRM+bKN5wPIMH/RaZxMHUCp54Easu9TWONbAx kmhF0xM1nGDu5obY+4bwqF7BBJ0R7Vg5m/zhoZ0GWn2ksupL//abw5ttDlLUsyMy ufvk4kJEI0n7Z4ZNg7O1Ltvi5lTluOSW6bY7ZMwVw8b10CE3eq9rQVZ8z3dPDSss AR3GfjoAJ3eYRSd7/vJ0dQon7Nw8dO/pxKcS/m0abFkd4SBgRmYDxQwdzBL1vNVf 4Vje0Pke/PakjD+Qi9bRcK0N1ud1uuTVdf0CJY+UMfLhk51Mt9i4yH8XIyIjy81x LjkAdjAtJBzuXMfShILWiRKFEMP7kp5UOC2q+If2ZQX57UfyPAwpiaq33iCV6DA= =iq6t -END PGP SIGNATURE- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Indiana - what comes closest to it?
The people working with Alasdair already made this list, but if you're trying to independently recreate it, you can get a list of included consolidation incorporations by doing: pkg contents -t depend -a type=incorporate -o fmri -r entire You could run a similar command on each of those listed incorporations to find out which packages each includes. Ok. So is there a 1:1:1 relationship between an 'incorporation' and a 'consolidation' and a source 'repository'? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] root roles security holes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/30/2010 4:24 PM, Will Fiveash wrote: On Fri, Jul 30, 2010 at 12:44:43PM -0700, David Brodbeck wrote: On Jul 30, 2010, at 12:26 PM, Will Fiveash wrote: I'm in total agreement from a security aspect (recall that OpenSolaris's roots are in the enterprise server world and not wide open desktop land). I would ask you why root shouldn't be a role? Hopefully the answer won't involve convenience. It can be awkward if you're using LDAP or NIS and the server is down or the client is incorrectly set up. This *can* be worked around by making sure every machine has a valid local user with access to the root role -- sort of. pfexec becomes extremely slow if you have incorrectly configured LDAP -- as in several minutes of waiting to run a single command. I suspect it tries to look up userIDs via LDAP first and has a long timeout. Best to su to root in that situation. This is a variant of the convenience argument. Systems with root as a role require a local user account with Primary Administrator role. When I installed OpenSolaris it did the right thing and created such an account that does not depend on NIS or LDAP and is thus insulated from issues with those servers. That user account should only have local paths in the PATH and a local home directory for greater reliability. I actually like root as a role, but it strikes me that by forcing all machines to have a single local user with a pw that everyone knows, you've totally re-opened the hole that this was supposed to close. Anyone can login as that local user, and assume the root role anonymously. Isn't there anything that can be done so that these local accounts aren't needed? -Kyle -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBAgAGBQJMUzcqAAoJEEADRM+bKN5wL00H/RDHf/o3lNk+v2ZbVTXWkS4w P5IWdJkQvCiHoegL579MwHXgNIqgVQITIzOn5p+SHRLgErxnZNKATBJ3Aivo1+ta ddmPfMIgyaN3V14O2Y85EMF4+8EhhyUh1i7BuaOZTcqJr8i5K934mv6DCw8Ifnhy L/lVB5mci3imoBL7Kk/7XbExf4eNu+1YDYR4ZIDg8AVy+1SdsS5fpjB0p/bdPcdj 5noKc1IMsThX5iwig9fxnO81YUUpFNb60/yA1GrgO/3vMoplGI+YjPfZEbP46Okh 048NRxNolIKDN27+Xx+uWL1MUG2xy4VhMwCrEojlsEIZWQR611Vmi0iSyWZ7mPw= =AL0w -END PGP SIGNATURE- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] root roles security holes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/30/2010 4:54 PM, Will Fiveash wrote: On Fri, Jul 30, 2010 at 04:33:47PM -0400, Kyle McDonald wrote: On 7/30/2010 4:24 PM, Will Fiveash wrote: On Fri, Jul 30, 2010 at 12:44:43PM -0700, David Brodbeck wrote: On Jul 30, 2010, at 12:26 PM, Will Fiveash wrote: I'm in total agreement from a security aspect (recall that OpenSolaris's roots are in the enterprise server world and not wide open desktop land). I would ask you why root shouldn't be a role? Hopefully the answer won't involve convenience. It can be awkward if you're using LDAP or NIS and the server is down or the client is incorrectly set up. This *can* be worked around by making sure every machine has a valid local user with access to the root role -- sort of. pfexec becomes extremely slow if you have incorrectly configured LDAP -- as in several minutes of waiting to run a single command. I suspect it tries to look up userIDs via LDAP first and has a long timeout. Best to su to root in that situation. This is a variant of the convenience argument. Systems with root as a role require a local user account with Primary Administrator role. When I installed OpenSolaris it did the right thing and created such an account that does not depend on NIS or LDAP and is thus insulated from issues with those servers. That user account should only have local paths in the PATH and a local home directory for greater reliability. I actually like root as a role, but it strikes me that by forcing all machines to have a single local user with a pw that everyone knows, you've totally re-opened the hole that this was supposed to close. Anyone can login as that local user, and assume the root role anonymously. Just because a system has a local user account doesn't imply that everyone should know the password. Well, 'everyone' in my statement refered to 'all admins' or 'all people who traditionally would have had access to the traditional root pw. Granted, in this config it could be limited furhter, to the 'core admins', but I doubt any enterprise would want only one person to know this password, and once 2 people know it, there is no knowing for sure who did what. Isn't there anything that can be done so that these local accounts aren't needed? Actually, it may be possible to configure a system with no local user accounts but if the network or nameservice is down it may be a hassle to login to that system and may require booting off the install DVD. Yes, I was asking if there was some way to eliminate that hassle without requiring adding a single local account. One person has suggested making NIS or LDAP cache userinfo locally for use when the directory can't be contacted. Windows does a form of this I beleive. In theory this cacheing could be controlled or limited to a subset of users I suppose. -Kyle Note that I have not tried such a config. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBAgAGBQJMU2JGAAoJEEADRM+bKN5wX1IH/1Mh0vPhcczeB78WayBpUZhR 90Ti7bhBmm0oWQfpdQeehfi49MpBG/v54Mfq33H51dFarwXrO2TmLGicE9nDmA1i Iv6Y2yFZ0TpwNEM6g6wLr4fZfFwZiwu2jFbhYuYSzBa8sp5phr7qhOOVcn7DdYY0 JCw+jvesAwFH0ggHBhcOU/J/cxCPGVLNElo8Jf8IqLQLe0tht6ZLfOM8el3EfK1i nCjD54sCcrv12bp0kChBMhxHXMFjrgKQtX30plfhQlRkNe1v3fD/nBbGlFPnz88S 8hESjB9s+easwQxOEUXC+gYYbwc5Dp5hyxz0kqZva797VFvadjJCa9O0D6dlJy4= =ZlXl -END PGP SIGNATURE- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Yet another warning about behaviour on this list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/15/2010 11:48 AM, Gary wrote: Please remove me or give me the link so I may do it myself. Though I did post comment on threads about OpenSoalris, at some point it became too much and I asked for the tabloid reading material to cease, but unfortunately some take that as a cattle prod to poke people or make snide remarks. If there was legitimate conversation about features that could/should be adopted, or otherwise interesting banter about the product, I wouldn't mind. However, that doesn't appear likely to happen, so I would prefer to be removed rather than be subjected to unflattering comment which I cannot ignore, and thus in return make unprofessional comments. The mailman interface, and instructions are available on the opensolaris.org website (click the 'discussions' link at the top of the page on the right.) It's the same page you used to subscribe in the first place - Unless you used some other method I've never heard of. Note that if you prefer a more technical discussion about features, the I suggest subscribing to one or more of the specific mailing lists that covers your area of interest. While subscribed, I generally don't read this list much at all, instead I've also subscribed to zfs-discuss, driver-discuss, x11-discuss, pkg-discuss, install-discuss, caiman-discuss, networking-discuss, etc. And I think you'll find more of what you're looking for on those lists. This list is for general discussion of things about OpenSolaris that *aren't* covered by those other mailing lists - News and discussion of it's future I think falls within that description. There are many many people here who haven't made up thier minds yet about how all the questions invloving oracle and OSol will finally be answered. So I don't think that posting news articles or other info people stumble across (which they think others might find useful) is that unreasonable a use for this list. Even when this list didn't have those discussions, I don't think it really had much of the types of discussions you're talking about either. -Kyle -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBAgAGBQJMPzB/AAoJEEADRM+bKN5wONEH/RhCsvvtqeBwSkwu28h0xTog ckh1G423KEi+4VMDaa09HJE3ESBnKTLqMsr/EJnNfLgxEVvPBx+nmRQRc+FgHbys hFbsP6OUlY3TRjKcIxfglaDOItYwdan1at0PRC/yosSTkU4Km1XpgcKXHfbRBWF8 ovta0H5h/jXN30PqcZNtDf8EEJh4FUy3QcHg9HKli8amcaq0sB6aSEZdX3CvNTjN pm7/xHjcV1R6UxX099qA/0Zg9SCCTrBBk9w/6AT7iQZSHJBBMa7DAp4l8XWpgGTx fn4Ld3qowxEDbNOhv/5OAYQZhB2CA8gt+fqDP2QF0XhDh0kXltYG1U3e+EXxjaw= =QM/r -END PGP SIGNATURE- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why do we need Oracle's permission or vision for OpenSolaris?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/14/2010 7:11 PM, Alan Coopersmith wrote: joerg.schill...@fokus.fraunhofer.de wrote: The community needs to be able to prevent moves into a direction that is aparently driven by customers but against the will of the majority of the users and the community needs to be able to put back their developments results. That will only happen if the community makes its own fork. Neither Sun nor Oracle would put the community wishes ahead of customer requirements, nor do I know of any successful open source OS driven by majority votes of users. While understand that there are good reasons for wanting totally ditch the Oracle provided infrastructure here, I wonder if that's really needed. Obviously Solaris is a commercial product owned by Oracle, and no-one but Oracle is going to control whats in the code repository it's built from. Likewise, whether we like it or not, the build and distribution of OpenSolaris code that is named OpenSolaris is also under Oracle's total control. What I've wondered about for a while is why can't (under the existing rules) a new project be created whose sole purpose is to create (build and make available for download) a new distribution from the source repositories (which are still being updated by Oracle.) Is there anything in the rules that prohibits this be done right here at OS.org? Does the infrastructure exist for this type of project? (Servers to do the compilation? bandwidth for the files to be downloaded?) If this distribution were available from the OpenSolaris.org website (on the project's page?) Is it allowed to contain the closed binaries? Of course this only resumes the availability of the dev builds, but that is a good start I think. Another thing I've wondered about is, would the current rules allow us to within this project or another clone the hg repository, and create the equivalent of an 'Community ARC' to review the changes made to the Oracle repositories, and whether or not the community wants to accept and merge them into the Community Repo. I've always felt that what this community needs isn't really a 'fork' but instead a common source base that *all* the distributions (even Oracle's OpenSolaris) both pull from and contribute back to. Of course the community doesn't have any way of forcing Oracle to push it's changes out any further than it's repository, so as alan said, the community would have to pull the changes they want. Depending ont the changes the community and other distributions make to the source base, Oracle (if they find changes they want) may in the long run, find it easier to present it's changes to the community for acceptance into the community source, since it will make merging later community out easier. Then again, maybe I'm just dreaming here... -Kyle -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBAgAGBQJMPl0TAAoJEEADRM+bKN5wAN0H/1iNuadMhqtHuLOwuaZG7kPa W1OfM359PAtrtdbERU82JY8iB9sfx9Evyb0+3mrwLw2rgxpA01tIuoVkA00UVLuO H6N8bi9zvtO1Q4uVal8aqIW4pZS5vqNydvHfN7/zJ5YMfd1Ka1e4RdE91aOT5Lqo 4/dRXkmFmXSDri2CRj5Amu/dvpgxro4EwFQV7Bk/htR4ycVBsYbbbJdkGbVgO8A1 lxjNkikKni+ZUac4rQ6dBxLyey8akY2MfHeSlUBr9M0XFt/fEDIRYQAS98XtylBg 19yQyz7xCFoeduwCU5uuMNnG0+zMv7kijht3OJyHhTcu1io6Q/QT9F7xvmcWD5k= =anEe -END PGP SIGNATURE- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Move the network related configuration file on Solaris10 but not go into effect
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/30/2010 11:33 AM, Gary wrote: It looks for /etc/hostname.* so /etc/hostname.ce0 or /etc/hostname.ce0_i_should_not_have_named_it_this are the sname thing. Actually it looks for /etc/hostname.*[0-9], so the file should still need to end in a numeric digitto be found. Also it also grabs the interface name from the file name, so if your example actually matched it would try to run: ifconfig ce0_i_should_not_have_named_it_this plumb Unless you have an interface on the system named 'ce0_i_should_not_have_named_it_this' I would expect that to fail. Even if you did have such an interface it shouldn't configure ce0. RHEL does the same thing if you move /etc/sysconfig/network-scripts/ifcfg-eth0 to ifcfg-eth0_do_not_configure_this_interface it will still bring it up. Ah, but the ifcfg-eth0 file has a line in it similiar to DEVICE=eth0 I suppose if the OP was taking advantage of some similiar option in Solaris then that might explain the behavior. I've never heard of such an option. So I'd have to say that the OP needs to look for another explanation. Like maybe there is a dhcp.ce0 file there, and the DHCP server is configured to supply the same IP address? Or it may depend on what they mean by 'os reset'. If they mean they rebooted, then that is strange. But if they mean they ran: svcadm restart network/physical:default or even if they stopped and started it, once the file was renamed, it may have caused the service to ignore the interface while bringing down all the interfaces, as well as ignoring it when bringing them up again. This would leave the ce0 interface configured the whole time. Just an idea... -Kyle -Kyle -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBAgAGBQJMK4BnAAoJEEADRM+bKN5wB5YH/3hmKqesj2z/2ZDodoZin894 2NHRRX9sP2XSyUS8D80lQsnviG855xwLSm90oum+A8q/D8mmcdLEKbJ+Vm2w8FTM o/z1bZo+hV1oZQWTLYOGeW+twFo9w7YGeOgcSEcm1erD91bUXeQ+M30WfA6fMJUi eu3D+0eJBSe/WmFY6J6CYPCPskSMJnU+KQI609fPdJKvKz6HOs8D8oPE6oTNFhnJ lAQBOlRsBkf/et7DtoMkj9OR9EXlYJwuQ/9SmqNtQbHARia+z42Qz/INBM6SsBhi Bvi0WDA7/20vP/++/GySPSy7Q2wLFkgCBnp7uKT4JxO/U3w8DtxZhZpa9eQ6z+Y= =CfxD -END PGP SIGNATURE- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Installed OS now Win7 won't hibernate?
Hi all, When I originally installed my laptop last time, I put OS in a partition, and it booted fine with grub. I also loaded Win7 X64 in a second partition, and as MS is known to do it rewrote the MBR and made itself the active partition. I ended up using Win7 mostly for the past few months and didn't need to boot into OS at all, so I never put grub back in the MBR. During this time Win7 had no problem Hibernating. Recently I actually installed OS b134 into that first partition, and it put grub back for me. I edited the grub file so that booting Win7 works great, now I can go back and forth. But I noticed pretty quickly that now when I'm booted in Win7 and request it to hibernate, it goes through the motions, but end up just basically locking the screen and staying awake - Almost like it hibernated and then automatically woke up. I'm wondering if Win7 might have noticed that the MBR changed? Maybe it needs to have a specific MBR in order to track something about hibernation? Anyone else seen anything like this? Anyone know how to maybe get Win7 to put what ever it needs at the beginning of it's partition, instead of in the MBR? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Issues with graphical boot in b134?
Hi, I recently installed b134 from the live CD on my Dell Lattitude D630 laptop. I can't remember now if the live CD used a graphical boot, but if it did it worked fine. The graphical boot on the installed system however spontaneously reboots my machine every time within 1-2 seconds of displaying the splash screen. I don't know if the kernel even gets loaded, and I don't beleive there is a panic since I go from seeing the splash image to the screen clearing and the Dell BIOS POST running again. I'd like to be able to use this, so I'd like to help debug it and provide the information needed to fix it, but I'm really at a loss to as to how to collect that info. Any ideas? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] kernel panic on build 130?
So I'm booting SXCE (yes I know but for now I'm stuck) sNVb130 on a machine that has worked fine with Nevada for a long time, and I'm getting this panic: SunOS Release 5.11 Version snv_130 64-bit Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. panic[cpu0]/thread=fbc2e3a0: mutex_enter: bad mutex, lp=c0 owner=f000cc73f000cc70 thread=fbc2e3a0 fbc4f9a0 unix:mutex_panic+73 () fbc4fa00 unix:mutex_vector_enter+446 () fbc4fa90 genunix:timeout_generic+83 () fbc4fac0 genunix:timeout_default+5b () fbc4fb00 genunix:delay_common+9d () fbc4fb40 genunix:delay+c4 () fbc4fb80 unix:page_resv+79 () fbc4fc10 unix:segkmem_xalloc+a7 () fbc4fc70 unix:segkmem_alloc_vn+cd () fbc4fca0 unix:segkmem_alloc+24 () fbc4fde0 genunix:vmem_xalloc+546 () fbc4fe40 genunix:vmem_alloc+161 () fbc4fe80 genunix:kmem_alloc+64 () fbc4fec0 genunix:kmem_zalloc+3b () fbc4fee0 acpica:AcpiOsAllocate+1c () fbc4ff30 acpica:AcpiUtAllocate+6e () fbc4ff80 acpica:AcpiUtAllocateZeroed+3f () fbc4ffe0 acpica:AcpiDsBuildInternalBufferObj+cc () fbc50040 acpica:AcpiDsEvalDataObjectOperands+dd () fbc50080 acpica:AcpiDsExecEndOp+3c5 () fbc500d0 acpica:AcpiPsParseLoop+353 () fbc50120 acpica:AcpiPsParseAml+163 () fbc50160 acpica:AcpiPsExecuteMethod+180 () fbc501a0 acpica:AcpiNsEvaluate+3c0 () fbc50210 acpica:AcpiUtEvaluateObject+86 () fbc50260 acpica:AcpiRsGetCrsMethodData+54 () fbc502b0 acpica:AcpiGetCurrentResources+5d () fbc50310 acpica fbc50160 acpica:AcpiPsExecuteMethod+180 () fbc501a0 acpica:AcpiNsEvaluate+3c0 () fbc50210 acpica:AcpiUtEvaluateObject+86 () fbc50260 acpica:AcpiRsGetCrsMethodData+54 () fbc502b0 acpica:AcpiGetCurrentResources+5d () fbc50310 acpica:parse_resources+3b () fbc503b0 acpica:isa_acpi_callback+2ca () fbc50430 acpica:AcpiNsGetDeviceCallback+15f () fbc504d0 acpica:AcpiNsWalkNamespace+14e () fbc50560 acpica:AcpiGetDevices+a0 () fbc50590 acpica:acpi_isa_device_enum+11c () fbc50630 isa:isa_enumerate+107 () fbc50650 unix:impl_bus_initialprobe+60 () fbc50680 unix:impl_setup_ddi+130 () fbc50690 genunix:create_devinfo_tree+b7 () fbc506a0 genunix:setup_ddi+13 () fbc506d0 unix:startup_modules+297 () fbc506e0 unix:startup+50 () fbc50710 genunix:main+2c () fbc50720 unix:_locore_start+92 () I get the same thing with b129 also, but I just booted b127 this morning and it works fine. Is this a known issue, or should I file a bug? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] kernel panic on build 130?
On 4/1/2010 2:49 PM, Shawn Walker wrote: On 04/ 1/10 01:24 PM, Kyle McDonald wrote: So I'm booting SXCE (yes I know but for now I'm stuck) sNVb130 on a machine that has worked fine with Nevada for a long time, and I'm getting this panic: SunOS Release 5.11 Version snv_130 64-bit Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. panic[cpu0]/thread=fbc2e3a0: mutex_enter: bad mutex, lp=c0 owner=f000cc73f000cc70 thread=fbc2e3a0 fbc4f9a0 unix:mutex_panic+73 () fbc4fa00 unix:mutex_vector_enter+446 () fbc4fa90 genunix:timeout_generic+83 () fbc4fac0 genunix:timeout_default+5b () fbc4fb00 genunix:delay_common+9d () fbc4fb40 genunix:delay+c4 () fbc4fb80 unix:page_resv+79 () fbc4fc10 unix:segkmem_xalloc+a7 () fbc4fc70 unix:segkmem_alloc_vn+cd () fbc4fca0 unix:segkmem_alloc+24 () fbc4fde0 genunix:vmem_xalloc+546 () fbc4fe40 genunix:vmem_alloc+161 () fbc4fe80 genunix:kmem_alloc+64 () fbc4fec0 genunix:kmem_zalloc+3b () fbc4fee0 acpica:AcpiOsAllocate+1c () fbc4ff30 acpica:AcpiUtAllocate+6e () fbc4ff80 acpica:AcpiUtAllocateZeroed+3f () fbc4ffe0 acpica:AcpiDsBuildInternalBufferObj+cc () fbc50040 acpica:AcpiDsEvalDataObjectOperands+dd () fbc50080 acpica:AcpiDsExecEndOp+3c5 () fbc500d0 acpica:AcpiPsParseLoop+353 () fbc50120 acpica:AcpiPsParseAml+163 () fbc50160 acpica:AcpiPsExecuteMethod+180 () fbc501a0 acpica:AcpiNsEvaluate+3c0 () fbc50210 acpica:AcpiUtEvaluateObject+86 () fbc50260 acpica:AcpiRsGetCrsMethodData+54 () fbc502b0 acpica:AcpiGetCurrentResources+5d () fbc50310 acpica fbc50160 acpica:AcpiPsExecuteMethod+180 () fbc501a0 acpica:AcpiNsEvaluate+3c0 () fbc50210 acpica:AcpiUtEvaluateObject+86 () fbc50260 acpica:AcpiRsGetCrsMethodData+54 () fbc502b0 acpica:AcpiGetCurrentResources+5d () fbc50310 acpica:parse_resources+3b () fbc503b0 acpica:isa_acpi_callback+2ca () fbc50430 acpica:AcpiNsGetDeviceCallback+15f () fbc504d0 acpica:AcpiNsWalkNamespace+14e () fbc50560 acpica:AcpiGetDevices+a0 () fbc50590 acpica:acpi_isa_device_enum+11c () fbc50630 isa:isa_enumerate+107 () fbc50650 unix:impl_bus_initialprobe+60 () fbc50680 unix:impl_setup_ddi+130 () fbc50690 genunix:create_devinfo_tree+b7 () fbc506a0 genunix:setup_ddi+13 () fbc506d0 unix:startup_modules+297 () fbc506e0 unix:startup+50 () fbc50710 genunix:main+2c () fbc50720 unix:_locore_start+92 () I get the same thing with b129 also, but I just booted b127 this morning and it works fine. Is this a known issue, or should I file a bug? Do these look familiar or seem to apply? http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6916573 Well, the stack dump is longer than the one in the bug above, and my system doesn't hang, it mentions there being no dump device (I'm network booting for a Jumpstart Install) and it reboots the machine so I'm not sure, BUT, it did start with b129, AND my hardware is also a IBM x346 Servers Model 8840 but mine is 2x 2.8Ghz with 4GB memory. So http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6907022 I don't see a stack trace in this one, and it also hangs which mine doesn't so I don't know. I'll have to try to boot OS 131 or newer and see if it disappears. Not that it will help me out though. -Kyle They apply starting with 129 I think, and weren't fixed until 131. -Shawn ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] kernel panic on build 130?
Reading more, it looks like it might be: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6905550 Which both of those bugs seem to relate to. -Kyle On 4/1/2010 2:49 PM, Shawn Walker wrote: On 04/ 1/10 01:24 PM, Kyle McDonald wrote: So I'm booting SXCE (yes I know but for now I'm stuck) sNVb130 on a machine that has worked fine with Nevada for a long time, and I'm getting this panic: SunOS Release 5.11 Version snv_130 64-bit Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. panic[cpu0]/thread=fbc2e3a0: mutex_enter: bad mutex, lp=c0 owner=f000cc73f000cc70 thread=fbc2e3a0 fbc4f9a0 unix:mutex_panic+73 () fbc4fa00 unix:mutex_vector_enter+446 () fbc4fa90 genunix:timeout_generic+83 () fbc4fac0 genunix:timeout_default+5b () fbc4fb00 genunix:delay_common+9d () fbc4fb40 genunix:delay+c4 () fbc4fb80 unix:page_resv+79 () fbc4fc10 unix:segkmem_xalloc+a7 () fbc4fc70 unix:segkmem_alloc_vn+cd () fbc4fca0 unix:segkmem_alloc+24 () fbc4fde0 genunix:vmem_xalloc+546 () fbc4fe40 genunix:vmem_alloc+161 () fbc4fe80 genunix:kmem_alloc+64 () fbc4fec0 genunix:kmem_zalloc+3b () fbc4fee0 acpica:AcpiOsAllocate+1c () fbc4ff30 acpica:AcpiUtAllocate+6e () fbc4ff80 acpica:AcpiUtAllocateZeroed+3f () fbc4ffe0 acpica:AcpiDsBuildInternalBufferObj+cc () fbc50040 acpica:AcpiDsEvalDataObjectOperands+dd () fbc50080 acpica:AcpiDsExecEndOp+3c5 () fbc500d0 acpica:AcpiPsParseLoop+353 () fbc50120 acpica:AcpiPsParseAml+163 () fbc50160 acpica:AcpiPsExecuteMethod+180 () fbc501a0 acpica:AcpiNsEvaluate+3c0 () fbc50210 acpica:AcpiUtEvaluateObject+86 () fbc50260 acpica:AcpiRsGetCrsMethodData+54 () fbc502b0 acpica:AcpiGetCurrentResources+5d () fbc50310 acpica fbc50160 acpica:AcpiPsExecuteMethod+180 () fbc501a0 acpica:AcpiNsEvaluate+3c0 () fbc50210 acpica:AcpiUtEvaluateObject+86 () fbc50260 acpica:AcpiRsGetCrsMethodData+54 () fbc502b0 acpica:AcpiGetCurrentResources+5d () fbc50310 acpica:parse_resources+3b () fbc503b0 acpica:isa_acpi_callback+2ca () fbc50430 acpica:AcpiNsGetDeviceCallback+15f () fbc504d0 acpica:AcpiNsWalkNamespace+14e () fbc50560 acpica:AcpiGetDevices+a0 () fbc50590 acpica:acpi_isa_device_enum+11c () fbc50630 isa:isa_enumerate+107 () fbc50650 unix:impl_bus_initialprobe+60 () fbc50680 unix:impl_setup_ddi+130 () fbc50690 genunix:create_devinfo_tree+b7 () fbc506a0 genunix:setup_ddi+13 () fbc506d0 unix:startup_modules+297 () fbc506e0 unix:startup+50 () fbc50710 genunix:main+2c () fbc50720 unix:_locore_start+92 () I get the same thing with b129 also, but I just booted b127 this morning and it works fine. Is this a known issue, or should I file a bug? Do these look familiar or seem to apply? http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6916573 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6907022 They apply starting with 129 I think, and weren't fixed until 131. -Shawn ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] OpenSolaris 1002 preview based on b126?
I checked GenUnix, and don't see anything to download. Any news? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Driver trouble on Nevada...
Hi, I have several types of IBM BladeCenter blades (mostly HS20 and LS20.) The BladeCenter manages these blades through a BMC with IPMI, and provides access to the serial console (ttyb) of the blades through the Serial Over LAN (SOL) feature of the BMC. When I user Solaris10 on these blades, Access to the serial console is fine. When I install SXCE (sNVb120 through 125 at least,) the console connection is terminated (not gibberish - The BMC stops sending the SOL data) shortly after the kernel boots, and the management module for the BladeCenter reports that 'SOL is not ready' for the blade I'm using, until I reboot it. I've played a bit with the BMC BIOS Settings, but I don't think that's the problem since this works fine in s10. How can I collect more info, or narrow this problem down further so that I can file a useful bug report? The output from booting SXCE sNV b125, as you can see it disconnects after loading the sysidcfg info, previous builds used to disconnect while 'Configuring /dev' if I recall. SunOS Release 5.11 Version snv_125 64-bit Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. NOTICE: Invalid iBFT table 0x1 Configuring /dev WARNING: emlxs: ddi_modopen drv/fct failed: err 2 Custom JumpStart Reading ZFS config: done. Setting up Java. Please wait... Serial console, reverting to text install Beginning system identification... Searching for configuration file(s)... Using sysid configuration file 172.30.171.30:/ex/Inst/SysID/Def/sysidcfg Search complete. Discoveri system console -T blade[3] SOL is not ready system The 'system' prompt is the CLI for the mmanagement module. The 'console -T blade[3]' command is me trying to reconnect to the SOL console. Anyone know of any changes in sNV that might have triggered this? It's making all of these blades useless for OpenSolaris. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Driver trouble on Nevada...
Hi, I have several types of IBM BladeCenter blades (mostly HS20 and LS20.) The BladeCenter manages these blades through a BMC with IPMI, and provides access to the serial console (ttyb) of the blades through the Serial Over LAN (SOL) feature of the BMC. When I user Solaris10 on these blades, Access to the serial console is fine. When I install SXCE (sNVb120 through 125 at least,) the console connection is terminated (not gibberish - The BMC stops sending the SOL data) shortly after the kernel boots, and the management module for the BladeCenter reports that 'SOL is not ready' for the blade I'm using, until I reboot it. I've played a bit with the BMC BIOS Settings, but I don't think that's the problem since this works fine in s10. How can I collect more info, or narrow this problem down further so that I can file a useful bug report? The output from booting SXCE sNV b125, as you can see it disconnects after loading the sysidcfg info, previous builds used to disconnect while 'Configuring /dev' if I recall. SunOS Release 5.11 Version snv_125 64-bit Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. NOTICE: Invalid iBFT table 0x1 Configuring /dev WARNING: emlxs: ddi_modopen drv/fct failed: err 2 Custom JumpStart Reading ZFS config: done. Setting up Java. Please wait... Serial console, reverting to text install Beginning system identification... Searching for configuration file(s)... Using sysid configuration file 172.30.171.30:/ex/Inst/SysID/Def/sysidcfg Search complete. Discoveri system console -T blade[3] SOL is not ready system The 'system' prompt is the CLI for the mmanagement module. The 'console -T blade[3]' command is me trying to reconnect to the SOL console. Anyone know of any changes in sNV that might have triggered this? It's making all of these blades useless for OpenSolaris. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [driver-discuss] Driver trouble on Nevada...
I tried booting again with -kv : module /platform/i86pc/kernel/amd64/unix: text at [0xfb80, 0xfb938f93] data at 0xfbc0 module /kernel/amd64/genunix: text at [0xfb938fa0, 0xfbb8f897] data at 0xfbc80b40 Loading kmdb... module /kernel/misc/amd64/kmdbmod: text at [0xfbcf0730, 0xfbd939a7] data at 0xfbd939b0 module /kernel/misc/amd64/ctf: text at [0xfbb8f8a0, 0xfbb9a1f7] data at 0xfbdaed10 SunOS Release 5.11 Version snv_125 64-bit Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. features: 614dcpuid,mwait,cx16,sse3,asysc,htt,sse2,sse,sep,pat,cx8,pae,mca,mmx,cmov,de,pge,mtrr,msr,tsc,lgpg mem = 8387812K (0x1fff39000) Using default device instance data initialized model-specific module 'cpu_ms.GenuineIntel' on chip 0 core 0 strand 0 root nexus = i86pc pseudo0 at root pseudo0 is /pseudo scsi_vhci0 at root scsi_vhci0 is /scsi_vhci npe0 at root: space 0 offset 0 npe0 is /p...@0,0 PCI Express-device: i...@1f, isa0 NOTICE: Invalid iBFT table 0x1 pseudo-device: acpippm0 acpippm0 is /pseudo/acpi...@0 pseudo-device: ppm0 ppm0 is /pseudo/p...@0 ramdisk0 at root ramdisk0 is /ramdisk root on /ramdisk:a fstype ufs SMBIOS v2.3 loaded (2026 bytes)acpinex0 at root acpinex0 is /fw pseudo-device: dld0 dld0 is /pseudo/d...@0 PCI Express-device: pci8086,3...@3, pcieb0 pcieb0 is /p...@0,0/pci8086,3...@3 PCIE-device: pci8086,3...@0,2, pcieb2 pcieb2 is /p...@0,0/pci8086,3...@3/pci8086,3...@0,2 PCIE-device: pci1014,2...@1, bge0 bge0 is /p...@0,0/pci8086,3...@3/pci8086,3...@0,2/pci1014,2...@1 PCIE-device: pci1014,2...@1,1, bge1 bge1 is /p...@0,0/pci8086,3...@3/pci8086,3...@0,2/pci1014,2...@1,1 Ethernet address = 0:14:5e:3d:5a:f3 ISA-device: asy0 asy0 is /p...@0,0/i...@1f/a...@1,3f8 ISA-device: asy1 asy1 is /p...@0,0/i...@1f/a...@1,2f8 PCI Express-device: pci8086,2...@1c, pci_pci0 pci_pci0 is /p...@0,0/pci8086,2...@1c PCI Express-device: pci8086,2...@1e, pci_pci1 pci_pci1 is /p...@0,0/pci8086,2...@1e PCI Express-device: pci1014,2...@1d, uhci0 uhci0 system The one thing I can think of, is that IBM warns on these blades that the network connection for the BMC is shared (hijacked) from bge0, and that if you PXE boot over bge0, the PXE code will reset the bge interface in a way the will disconnect the SOL connection. Given this, I wonder if the disconnection is a (delayed) consequence of the bge0 driver loading shortly before the disconnection? -Kyle Kyle McDonald wrote: Hi, I have several types of IBM BladeCenter blades (mostly HS20 and LS20.) The BladeCenter manages these blades through a BMC with IPMI, and provides access to the serial console (ttyb) of the blades through the Serial Over LAN (SOL) feature of the BMC. When I user Solaris10 on these blades, Access to the serial console is fine. When I install SXCE (sNVb120 through 125 at least,) the console connection is terminated (not gibberish - The BMC stops sending the SOL data) shortly after the kernel boots, and the management module for the BladeCenter reports that 'SOL is not ready' for the blade I'm using, until I reboot it. I've played a bit with the BMC BIOS Settings, but I don't think that's the problem since this works fine in s10. How can I collect more info, or narrow this problem down further so that I can file a useful bug report? The output from booting SXCE sNV b125, as you can see it disconnects after loading the sysidcfg info, previous builds used to disconnect while 'Configuring /dev' if I recall. SunOS Release 5.11 Version snv_125 64-bit Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. NOTICE: Invalid iBFT table 0x1 Configuring /dev WARNING: emlxs: ddi_modopen drv/fct failed: err 2 Custom JumpStart Reading ZFS config: done. Setting up Java. Please wait... Serial console, reverting to text install Beginning system identification... Searching for configuration file(s)... Using sysid configuration file 172.30.171.30:/ex/Inst/SysID/Def/sysidcfg Search complete. Discoveri system console -T blade[3] SOL is not ready system The 'system' prompt is the CLI for the mmanagement module. The 'console -T blade[3]' command is me trying to reconnect to the SOL console. Anyone know of any changes in sNV that might have triggered this? It's making all of these blades useless for OpenSolaris. -Kyle ___ driver-discuss mailing list driver-disc...@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/driver-discuss ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [driver-discuss] Driver trouble on Nevada...
Stewart Walters wrote: Kyle McDonald wrote: The one thing I can think of, is that IBM warns on these blades that the network connection for the BMC is shared (hijacked) from bge0, and that if you PXE boot over bge0, the PXE code will reset the bge interface in a way the will disconnect the SOL connection. Given this, I wonder if the disconnection is a (delayed) consequence of the bge0 driver loading shortly before the disconnection? -Kyle Just on that note, and I know this is going to sound like a typical IBM response, but have you taken the Bladecenter chassis BIOS, BMC and RSAII firmware revisions all to the latest level? For that matter, have you also taken the Blade BIOS and BMC firmware to the latest revision? I roll my eyes every time I get that response from IBM. I know. It's like Windows service people asking you if you've rebooted yet. But with the IBM Bladecenters - I just go straight to the latest firmware before I even call them now. Applying the latest firmware revisions often do fix up the quirky problems you can receive on BIOS's, BMC's and RSAII Adaptors. When I ran in to this problem the first time (about a year ago) I did have them up to date. I'll have to go check the current versions and download any I don't have, but since S10 is working fine, I didn't think of it. -Kyle Regards, Stewart ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] KSH93 problem?
Hi! Yesterday while debugging a shell script I think I may have found a bug in ksh93 from sNV b124. The script is basically checking a large list of DNS hostnames for ones that already end in a '.'. I've boiled it down to a simpler test case: while true; do if ! echo gretsch-p21-396 | grep '\.$'; then true; else echo false; fi; done If I run the above line at the shell prompt, for a long period of time I get no ouput at all, which is to be expected. However, pretty regularly rhe shell will be 'stopped' (as if I'd hit CTRL-Z) and I'll be returned to my login shell. If I continue the test by typing 'fg', then eventually, that 'if' statement will actually echo 'false' to stdout. In my original script that was having issues, I only ever saw the 'if' take the wrong path, and I never saw this 'Stopped' problem. What could cause the system to send 'SIGSTOP' to the ksh93 process? Here is a sample: while true; do if ! echo gretsch-p21-396 | grep '\.$'; then true; else echo false; fi; done [1]+ Stopped ksh93 37fg ksh93 false [1]+ Stopped ksh93 38fg ksh93 [1]+ Stopped ksh93 39fg ksh93 [1]+ Stopped ksh93 40fg ksh93 [1]+ Stopped ksh93 41fg ksh93 [1]+ Stopped ksh93 42fg ksh93 [1]+ Stopped ksh93 43 Is it me, or is this wierd? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KSH93 problem?
A new test script:
#!/bin/ksh93
COUNT=0
OLDCOUNT=0
while true; do
if ! echo gretsch-p21-396 | grep '\.$'; then
true
else
echo false - $? - ${COUNT} - $(( COUNT - OLDCOUNT ))
OLDCOUNT=${COUNT}
fi
COUNT=$(( COUNT + 1 ))
done
Produces output like:
false - 1 - 181500 - 181500
false - 1 - 181501 - 1
false - 1 - 181502 - 1
false - 1 - 181503 - 1
false - 1 - 181504 - 1
false - 1 - 181505 - 1
false - 1 - 181506 - 1
false - 1 - 181507 - 1
false - 1 - 181508 - 1
false - 1 - 181509 - 1
false - 1 - 181510 - 1
false - 1 - 181511 - 1
false - 1 - 181512 - 1
false - 1 - 181513 - 1
false - 1 - 181514 - 1
false - 1 - 181515 - 1
false - 1 - 181516 - 1
false - 1 - 181517 - 1
false - 1 - 181518 - 1
false - 1 - 181519 - 1
false - 1 - 181520 - 1
false - 1 - 181521 - 1
false - 1 - 181522 - 1
false - 1 - 181523 - 1
false - 1 - 181524 - 1
false - 1 - 181525 - 1
false - 1 - 191527 - 10002
false - 1 - 191528 - 1
false - 1 - 191529 - 1
false - 1 - 191530 - 1
false - 1 - 191531 - 1
false - 1 - 191532 - 1
false - 1 - 191533 - 1
false - 1 - 191534 - 1
false - 1 - 191535 - 1
false - 1 - 191536 - 1
false - 1 - 191537 - 1
false - 1 - 191538 - 1
false - 1 - 196464 - 4926
false - 1 - 196465 - 1
false - 1 - 196466 - 1
false - 1 - 196467 - 1
false - 1 - 196468 - 1
false - 1 - 196469 - 1
false - 1 - 196470 - 1
false - 1 - 196471 - 1
false - 1 - 196472 - 1
false - 1 - 196473 - 1
false - 1 - 196474 - 1
false - 1 - 196475 - 1
false - 1 - 196476 - 1
false - 1 - 196477 - 1
false - 1 - 196478 - 1
false - 1 - 196479 - 1
false - 1 - 196480 - 1
false - 1 - 196481 - 1
false - 1 - 196482 - 1
false - 1 - 196483 - 1
false - 1 - 196484 - 1
false - 1 - 196485 - 1
false - 1 - 196486 - 1
false - 1 - 196487 - 1
false - 1 - 196488 - 1
false - 1 - 196489 - 1
false - 1 - 206493 - 10004
false - 1 - 206494 - 1
false - 1 - 206495 - 1
false - 1 - 206496 - 1
false - 1 - 206497 - 1
false - 1 - 206498 - 1
false - 1 - 206499 - 1
false - 1 - 206500 - 1
false - 1 - 206501 - 1
false - 1 - 206502 - 1
false - 1 - 206503 - 1
false - 1 - 206504 - 1
And it's still running.
Given that the exit code from the pipe is '1', I figured it might be a
bug in grep, but the same script with the first line changed to
#!/bin/bash has been running for a while now and hasn't spit any
problems out yet.
-Kyle
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KSH93 problem?
ольга крыжановская wrote: On 10/28/09, Kyle McDonald kmcdon...@egenera.com wrote: [Resend to opensolaris-discuss too.] Hi! Yesterday while debugging a shell script I think I may have found a bug in ksh93 from sNV b124. Please test if the ksh93 download from http://hub.opensolaris.org/bin/view/Project+ksh93-integration/2009-10-18 solves your problem. Nope. The problem is still there: 82/tmp/test.sh false - 1 - 11284 - 11284 false - 1 - 11285 - 1 false - 1 - 11287 - 2 false - 1 - 11288 - 1 false - 1 - 11289 - 1 false - 1 - 11290 - 1 false - 1 - 11291 - 1 false - 1 - 11292 - 1 false - 1 - 11293 - 1 false - 1 - 11296 - 3 . . . The same script running in bash is still running error free. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] What do these messages mean?
Hi, I'm PXE booting the SXCE b123 ISO, and on boot the kernel shows these messages: SunOS Release 5.11 Version snv_123 64-bit Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Configuring /dev WARNING: emlxs: ddi_modopen drv/fct failed: err 2 pseudo0: invalid op (6) from tpm0 WARNING: tpm_attach: tpm failed to attach Custom JumpStart What do they mean? Should I roll back to 122? Should I report this as a bug? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] What does this mean?
When I loop-back mount an ISO on Solaris NV (b103) I see a file that tells me this: This disc contains a UDF file system and requires an operating system that supports the ISO-13346 UDF file system specification. Do I need a special mount option? or is this not supported on Solaris? man mount_hsfs didn't mention UDF. and there is no mount_udf. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] IBM BladeCenter BMC and Serial over LAN issues?
Hi all, I have an IBM BladeCenter with several HS20 blades. Each of these has a BMC module and one of the ways to use the console of the blade is to redirect the console to the blade's serial port which the BMC module then translates to SOL protocol, which you can access through the network. I am having a problem (on sNV97 and sNV98) maintaining the console access this way when running Solaris on these blades (I am going to test linux next.) The SOL console works great through POST, all the BIOS menus, grub, and even the initial Kernel startup. But as soon as the Solaris kernel boots (banner appears) and the message about configuring /dev comes up, something in Solaris causes the BMC to drop the SOL connection and refuses to restart it (reports 'SOL not ready'.) As soon as the blade is rebooted and POST starts it starts working again. There is one known similar problem. Since the network connection to the BMC is shared with the first ethernet port on the blade, it is known that PXE/DHCP booting the blade using the first ethernet interface, resets the NIC and will cause the active SOL console session to be disconnected just like what I'm describing above. This isn't my problem (I'm not PXE/DHCP booting, and when I do I use the second ethernet not the first,) but it sounds very similar. So I'm wondering 2 things: 1.) Could the Broadcom ethernet driver be 'reseting' the first NIC exactly the same way the PXE/DHCP boot would, and therefore be triggering the same issue? 2.) I seem to recall a recent integration or change involving a Solaris driver to interact with the BMC module. Could that or something else in the kernel be resetting the BMC directly, or otherwise causing the SOL connection to drop? I need to go back and test earlier sNV builds and s10 (which IBM claims works fine) but I thought I'd ask here first. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] BIND update?
Hi all, Where can I look to be able to tell if NV will be , or has been, updated with a version of BIND that has the latest exploit patches installed? While NV policy is production code all the time, I understand that it's still not totally considered production environment, and therefore integrating these patches might not be a high priority. I'm just looking to guage if/when I should go compile it from source - Actually I've already started that. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] BIND update?
Milan Jurik wrote: Hi Kyle, V st, 06. 08. 2008 v 17:50, Kyle McDonald píše: Hi all, Where can I look to be able to tell if NV will be , or has been, updated with a version of BIND that has the latest exploit patches installed? To Sun Alert or blogs.sun.com/security I didn't realize that Sun's Security Alerts covered NV. Cool. While NV policy is production code all the time, I understand that it's still not totally considered production environment, and therefore integrating these patches might not be a high priority. I'm just looking to guage if/when I should go compile it from source - Actually I've already started that. Isn't Bind 9.3.5-P1 part of build 95? 95. That was what I was looking for. Thanks! If all will go well, I will integrate improved 9.3.5-P2 in the next days, probably for build 97. That will be even better! Cool! -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [cifs-discuss] Windows-Solaris Name Service Cooperation?
Nicolas Williams wrote: I'm glad I asked :) Me too. :) OK then the prescription is: - setup a Unix nameservice for the Solaris and Linux systems - AD SFU *will* do if you can get Linux's nss_ldap to use it (I'm sure you can). And AD SFU *will* make admistration easier for you. - setup either directory-based name mapping or name-based mapping rules for the Solaris file servers. - Make sure that for every Windows user and group that will be referenced by the Windows clients (when talking CIFS to the Solaris servers) there exists a user and group in the Unix nameservice and corresponding mappings. - Keep in mind that Windows groups can own files, so you may need to ensure that each Windows group (and even users) maps to a Unix user and a Unix group. I think this is becoming clearer. I was thinking that SID's needed to be converted to UID/GID's at login time also or Linux and S10 wouldn't get put the right UID/GID in the NFS operations. But really UID's and GID's are just looked up normally by username at login time, SID's are only mapped to UID/GID's when CIFS operations come into the Server. So I need a NameService. Either my own (NIS, NIS+, or LDAP) where I manage accounts and mappings, or a SFU/AD setup and run by IT here they manage accounts and mappings? If I choose my own NameService, then all I need for NFS between Linux, S10, and Nevada is for all of those to use it for username/passord lookups at login time, and The mappings only come into play when Windows clients connect to the Nevada Servers. The upside here is that I have to run a NameService eitherway if I want to manage the AutoMount, and other tables myself. The only down side is I end up creating accounts for all employees in my NameService and dealing ith password issues (lost, can't change, etc.) -- Unless I continue to 'steal' IT's NIS password and group maps, or Is it possible to setup my own LDAP server with the Mapping, AutoMount, and other Unix 'Tables', but which proxies or refers LDAP clients to the AD server for Password and Group info? or will that require SFU also? On the other hand if I can get SFU installed by IT, then all the Linux, S10, and Nevada machines can do lookups to SFU/AD (through LDAP? Is that the only choice?) to handle Logins, and the Nevada Servers will beable to also look up mappings for the Windows clients that connect? Upside here is IT add's new user accounts, and deals with password problems. Down side is they might not be willing to install it. I just don't want to be in the bussiness of creating and managing user accounts. Today, the IT dept has several separate user databases, that they create accounts for new employees in when they join the company. As long as you intend to use NFSv3 you have little choice. I don't mind managing a mapping table (though I'd rather not.) It's dealing with lost passwords, problems changing passwords, locked accounts, etc. I'd rather not have to deal with. How is it that NFSv3 makes this a requirement? Make sure that your Linux and Solaris clients can use Kerberos to authenticate users via AD. If you can make sure that AD usernames can be used as Unix usernames (keep them short and free of funny characters) then this is trivial. IT already does a decent job of this today since they always make matching accounts on the linux NIS server now. All usernames I've seen are all lowecase alpha characters, Usually 9 characters or less (long enough to screw up ls output but not too long. ;) Is Kerberos only needed if I use SFU, and logins are done against AD? Or are is it required even with a separate Name Service for logins? I've been debating with myself whether to convert my NIS to NIS+ to get the SecureRPC's and enable SecureNFS... Or to convert to LDAP and either Secure RPC/NFS, or Kerberos. or just keep it simple and stick ith NIS, and wide open NFS for simplicity The NIS+/SecureNFS combo I've done before, so setting that up doesn't seem that bad. The LDAP/Kerberos combo I've never done, but I know it is the future and more likely to be useful when I start to factor AD into the picture. If I can use my own LDAP, with 'referals' or proxies to some user and group from AD, then it might make sense to bite the bullet and go with LDAP and Kerberos now... Especially if Linux nss_ldap can be setup to work through my LDAP server to AD. That's going to have to change. It will. At least it will for any machines I manage. If I stick with my own Name service, I'll be making that available to anyone ho wants to use it on Linux machines they manage (Most are developer's machines, or Lab (Dev and QA) machines with no central management. Some get reinstalled so often they won't spend much time actually in a domain of any type. If IT will do SFU it'll be a little trickier... I'll have to show everyone how to use my Name
Re: [osol-discuss] [cifs-discuss] Windows-Solaris Name Service Cooperation?
Thanks Nico! I didn't know you were involved with this. More below... Nicolas Williams wrote: On Tue, Jun 17, 2008 at 01:43:46PM -0400, Kyle McDonald wrote: The part I'm fuzzy on are the nameservies interoperation. I know the CIFS server required a bunch of work to deal with windows user and groups for file ownership and access control. What is new in Solaris though for shareing usernames and passwords (and other account information) between Windows and Solaris? For example, is it possible for a Solaris machine to participate in a Windows Active Driectory Domain as a client? Yes. Cool. as a Domain Controller? No. That's OK. But (liking Solaris as much as I do,) it seems a shame to leave Windows as the only system that can be the authoritative source for this stuff. :) Another question, is if/when Windows users login on Solaris, where/how is the UID/GID assigned? See the ID mapping portion of the CIFS guide. Thanks, I'll go look for that now. The reason I ask is that I'm really looking for a solution that will let me set both linux and Solaris to share usernames and passwords with Windows, while Linux and Solaris share files through NFS. The solution we use works for Solaris. We made no changes to Linux. You can still interop with Linux and use Windows identities provided that you have a Unix name service with users and groups that are the equivalents of Windows ones. SFU will do as a such a name services. Is SFU the only option right now? Is MS still developing/supporting SFU? I thought it was either dead or at least on life support only now? What are my choices if the people who run the AD and Windos infrastructure refuse to install SFU? So how does Solaris handle this (if it does?) If it does it in simliar way to WinBind, is it too much to hope that it uses the same algorithm for SID--UID as WinBind? I mean I can deal with a 1 time chown, but to It's not the same algorithm, except for name-based mapping, where it's close enough. I'm not sure I get this statement, but maybe I'll get after I read all the other blogs and docs you pointed me to. Thanks! do what I need on the Unix/NFS side I really need Solaris and Linux to agree on UIDs and GIDs. Is there someway that Solaris can export it's tranlation to linux through an AD-NIS converter? No, but if you can use SFU (i.e., assign UIDs and GIDs in AD itself) then you're fine. We're considering adding more ID mapping options too. What types of things are you considering? (If you can talk about them?) Where's the best place to read up more on this? Try the CIFS guide. There's also plenty of blogs linked to from the storage blog: http://blogs.sun.com/storage/en_US/entry/what_we_re_reading_alan http://blogs.sun.com/storage/en_US/entry/more_on_cifs Thanks! -Kyle Nico ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [cifs-discuss] Windows-Solaris Name Service Cooperation?
Nicolas Williams wrote: The solution we use works for Solaris. We made no changes to Linux. You can still interop with Linux and use Windows identities provided that you have a Unix name service with users and groups that are the equivalents of Windows ones. SFU will do as a such a name services. Is SFU the only option right now? If you want NFSv3 interop with Linux, yes. Other options: interop with Linux via CIFS. Is SFU required to use only NFSv3 between Solaris Machines? Is NFSv4 required for any of this? What are my choices if the people who run the AD and Windos infrastructure refuse to install SFU? No interop with Linux with NFSv3. Try using CIFS. But Linux SMB mounts are done as a single UserID right? If IT will allo me to run my own AD sub domain, can I run SFU only there, and pass the parent domain User/Passord info through to Solaris and Linux? That's not exactly ideal, but might ork better than getting them to run SFU the way I'd need them to. I'm guessing SFU basically adds a AD-NIS proxy to the AD server? Does it appear as a NIS server to the Linux and Solaris clients? or something else? NIS+? Any idea if a Solaris NIS server can be a slave to the SFU one (assuming my guess above is correct?) It's not the same algorithm, except for name-based mapping, where it's close enough. I'm not sure I get this statement, but maybe I'll get after I read all the other blogs and docs you pointed me to. Thanks! idmapd supports just these ID mapping methods: - directory-based name mapping - rule-based name mapping - ephemeral ID mapping - local SID mapping The first one works by adding attributes to your AD or native LDAP schema to name an entity's equivalent entity on the other side. That sounds the most striaght forward, but that's the one Linux doesn't support yet right? The second works by providing local rules that tell you how to map an entity on one side to one on the other. These rules also work with names. Even that sounds good to me. Ephemeral ID mapping dynamically allocates UIDs and GIDs to Windows entities on demand. The pool of UIDs and GIDs used for this is the 2^31 to 2^31-2 range of UID/GID values. We took pains to make sure that the system does not store these anywhere permanently, and we restart the allocations on reboot. ZFS stores SIDs now. That sounds like it might be great in some situations, but I don't think it'll ork for me... Than again after I read everything I might change my mind. Local SID mapping is used to map non-ephemeral UIDs/GIDs to RIDs relative to the local SID when there's no other way to map them. By local, you mean local to the local machine? or can these mappings be stored in NIS or NIS+? and shared beteen machines? For that matter can the Rule Mapping mentioned above be distributed in NIS, NIS+, or someother (non-AD) LDAP? Either way I bet Linux doesn't have anything that matches up. We're considering adding more ID mapping options too. What types of things are you considering? (If you can talk about them?) Direct support for SFU (right now you have to configure either DS-based name mapping or local name rules + nss_ldap with schema mapping to get SFU support). I guess I need to go read up on SFU too. It looks like I've put this off way too long. Also, perhaps we might want to add some algorithmic ID mapping schemes. Cool, I'll keep my eyes open. Any chance any of this will be prted to linux anytime soon? Note to Sun: I'd be wiilling to install (and buy!) Sun Software on all my linux machines, in order to make this all place nice together! -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [cifs-discuss] Windows-Solaris Name Service Cooperation?
Nicolas Williams wrote: On Wed, Jun 18, 2008 at 04:39:52PM -0400, Kyle McDonald wrote: Is SFU required to use only NFSv3 between Solaris Machines? No. A Unix name service is strongly implied. That could be SFU. Could be SFU? I thought if you want Windows, Linux and Solaris, it had to be SFU? No interop with Linux with NFSv3. Try using CIFS. But Linux SMB mounts are done as a single UserID right? I don't know. I haven't tried (and don't have a Linux system to try with). I'm pretty sure you put the Username (and password!!) as options to mount in the /etc/fstab. But there could be something newer now. If IT will allo me to run my own AD sub domain, can I run SFU only there, and pass the parent domain User/Passord info through to Solaris and Linux? We run an AD domain. So do others. I'm not sure what you mean by pass the parent domain User/Passord info through to Solaris and Linux. I meant, I'm not looking to manage accounts. I was thinking that if I had a PDC (or whatever AD calls it) for a subdomain, that I could run and manage SFU, while passing through the parent domains user accoutn DB... I think older NT domains called this 'Trusting'... I kno enough to kno it's different ith AD, but not *how* it's different. In AD you don't use passwords -- you use NTLM and Kerberos V credentials. Yes, those are generally obtained via passwords (ignore PKINIT for now), but once acquired you don't use your password. KerberosThat's my next project... :) Does that make the Solaris Windows integration easier or harder? idmapd supports just these ID mapping methods: - directory-based name mapping - rule-based name mapping - ephemeral ID mapping - local SID mapping The first one works by adding attributes to your AD or native LDAP schema to name an entity's equivalent entity on the other side. That sounds the most striaght forward, but that's the one Linux doesn't support yet right? Samba supports name-based mapping rules. I don't recall if it supports anything like directory-based name mapping. Samba won't help as I don't plan on serving any files to indows from Linux.. Thought there may cases in the future where I can't avoid it. The second works by providing local rules that tell you how to map an entity on one side to one on the other. These rules also work with names. Even that sounds good to me. It's easy! But it needs to be distributed to each client identically. Then again the DS based mapping is hat needs SFU right? and I bet SFU needs to run on the AD server that has all the other info about the accounts right? I mean it's not like the AD on a subdomain could have a sparse AD LDAP database that adds the mapping info but refers requests for the rest through to the IT Corp AD Domain LDAP database? Ephemeral ID mapping dynamically allocates UIDs and GIDs to Windows entities on demand. The pool of UIDs and GIDs used for this is the 2^31 to 2^31-2 range of UID/GID values. We took pains to make sure that the system does not store these anywhere permanently, and we restart the allocations on reboot. ZFS stores SIDs now. That sounds like it might be great in some situations, but I don't think it'll work for me... Than again after I read everything I might change my mind. It's great if you're building file servers. file servers that only serve windows (or at least SMB) clients right? If you're building clients then you need nss_ad (ongoing project) and even then that doesn't help you with NFSv3. What is nss_ad going to allow? For that matter can the Rule Mapping mentioned above be distributed in NIS, NIS+, or someother (non-AD) LDAP? No. If you need to distribute your name mappings, use directory-based name mapping. Or there's always Rsync, or Scp. ;) Either way I bet Linux doesn't have anything that matches up. Just rules. Local Rules... Similiar to Solaris's? I mean even if the file format to specify them is different, is it possible to setup the same local rules mapping on both Solaris and Linux? I guess I need to go read up on SFU too. It looks like I've put this off way too long. So, what are you trying to do? I need to setup a new farm of software build servers. They'll consist of all different versions of Linux (multiple versions of RHEL, and SLES) and a few S10 for building our software. I also need to setup a bunch of NFS fileservers to support this build Farm. The Developers all have indows desktops that are clients of the IT 'CORP' AD domain, and they'll also want access to the files on the servers through CIFS, so I really want to setup sNV servers ith ZFS and CIFS. So for the most part, it's Solaris to Windows with CIFS, and Solaris to Solaris and Linux with NFS. There might be a fe Linux
[osol-discuss] Windows-Solaris Name Service Cooperation?
Hi all, I know Sun has made some big additions to Solaris in the area of Windows-Solaris interoperability. The part I'm most familiar with is the CIFS server and client. The part I'm fuzzy on are the nameservies interoperation. I know the CIFS server required a bunch of work to deal with windows user and groups for file ownership and access control. What is new in Solaris though for shareing usernames and passwords (and other account information) between Windows and Solaris? For example, is it possible for a Solaris machine to participate in a Windows Active Driectory Domain as a client? as a Domain Controller? Another question, is if/when Windows users login on Solaris, where/how is the UID/GID assigned? The reason I ask is that I'm really looking for a solution that will let me set both linux and Solaris to share usernames and passwords with Windows, while Linux and Solaris share files through NFS. The easiest way I know of to get a linux machine to join an AD domain, is with WinBind, but AFAIK WinBind isn't a great solution if your users already have UIDs and GIDs assigned on Linux, since it wants to create newones from the Windows SID. I suppose normally it would just mean a large number of chown's, but it's not that easy when the files that need to change are in something like ClearCase. So how does Solaris handle this (if it does?) If it does it in simliar way to WinBind, is it too much to hope that it uses the same algorithm for SID--UID as WinBind? I mean I can deal with a 1 time chown, but to do what I need on the Unix/NFS side I really need Solaris and Linux to agree on UIDs and GIDs. Is there someway that Solaris can export it's tranlation to linux through an AD-NIS converter? Where's the best place to read up more on this? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] PANIC! mounting cdrom slice on b78
Hi All, I have sNV b78 installed (I know I'm working on upgrading to b90.) I was attempting to mount /dev/dsk/c2t0d0s4, which is an ATAPI DVDROM drive containing S10 03/05 CD1, and the machine panic'd when I did 'mount -F hsfs -o ro /dev/dsk/c2t0d0s4' Here's what came up on the console... I can try to get the core also if needed. panic[cpu0]/thread=ff02d5810140: BAD TRAP: type=e (#pf Page fault) rp=ff0010896a20 addr=20 occurred in module mntfs due to a NULL pointer dereference hald: #pf Page fault Bad kernel fault at addr=0x20 pid=700, pc=0xf78da280, sp=0xff0010896b10, eflags=0x10246 cr0: 8005003bpg,wp,ne,et,ts,mp,pe cr4: 6f8xmme,fxsr,pge,mce,pae,pse,de cr2: 20cr3: 22fd88000cr8: c rdi:0 rsi:a rdx:a rcx:0 r8: 60 r9: 3a rax: 60 rbx: 42 rbp: ff0010896b50 r10:b r11: ff001089691d r12: 18ba r13:0 r14:0 r15: ff04b36e3da8 fsb:0 gsb: fbc26770 ds: 4b es: 4b fs:0 gs: 1c3 trp:e err:0 rip: f78da280 cs: 30 rfl:10246 rsp: ff0010896b10 ss: 38 ff0010896900 unix:die+c8 () ff0010896a10 unix:trap+13b1 () ff0010896a20 unix:cmntrap+e9 () ff0010896b50 mntfs:mntfs_global_len+30 () ff0010896be0 mntfs:mntfs_snapshot+111 () ff0010896d30 mntfs:mntioctl+31c () ff0010896db0 genunix:fop_ioctl+7b () ff0010896ec0 genunix:ioctl+174 () ff0010896f10 unix:brand_sys_sysenter+1e6 () syncing file systems... 2 done dumping to /dev/dsk/c1t0d0s3, offset 431030272, content: kernel 100% done: 311409 pages dumped, compression ratio 4.14, dump succeeded rebooting... If there's a better email list to post this to, please let me know. Or if this is a known issue, is it fixed in b90? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] PANIC! mounting cdrom slice on b78
It happenned again. Only this time it happenned when I started 'bash' (after failing[no such device] to mount s7 of the same CD.) Here's the panic this time: # mount -F hsfs -o ro /dev/dsk/c2t0d0s7 /mnt mount: /dev/dsk/c2t0d0s7 no such device # bash panic[cpu0]/thread=ff02d58d46e0: BAD TRAP: type=e (#pf Page fault) rp=ff00104e7db0 addr=a occurred in module unknown due to a NULL pointer dereference sh: #pf Page fault Bad kernel fault at addr=0xa pid=1199, pc=0xa, sp=0xff00104e7ea0, eflags=0x10246 cr0: 8005003bpg,wp,ne,et,ts,mp,pe cr4: 6f8xmme,fxsr,pge,mce,pae,pse,de cr2: acr3: 22fd88000cr8: c rdi: ff02d46a9400 rsi: ff030240d040 rdx: ff02d58d46e0 rcx:3 r8: ff02faddc628 r9: ff02faa16708 rax:e rbx: fbc77b90 rbp: ff02d4f7f048 r10: ff02d560c008 r11:0 r12: 4af r13: 2eb r14: ff02d59171f0 r15: ff02d58d46e0 fsb:0 gsb: fbc26770 ds: 4b es: 4b fs:0 gs: 1c3 trp:e err:0 rip:a cs: 30 rfl:10246 rsp: ff00104e7ea0 ss: 38 ff00104e7c90 unix:die+c8 () ff00104e7da0 unix:trap+13b1 () ff00104e7db0 unix:cmntrap+e9 () warning! 8-byte aligned %fp = ff02d4f7f048 ff02d4f7f048 a () syncing file systems... done dumping to /dev/dsk/c1t0d0s3, offset 431030272, content: kernel 100% done: 272320 pages dumped, compression ratio 5.20, dump succeeded rebooting... Is this machine suffering a Hardware failure? or is this a bug? (It could be a bad CD I suppose, but I'd think it was a bug if a bad CD can panic the system.) -Kyle Kyle McDonald wrote: Hi All, I have sNV b78 installed (I know I'm working on upgrading to b90.) I was attempting to mount /dev/dsk/c2t0d0s4, which is an ATAPI DVDROM drive containing S10 03/05 CD1, and the machine panic'd when I did 'mount -F hsfs -o ro /dev/dsk/c2t0d0s4' Here's what came up on the console... I can try to get the core also if needed. panic[cpu0]/thread=ff02d5810140: BAD TRAP: type=e (#pf Page fault) rp=ff0010896a20 addr=20 occurred in module mntfs due to a NULL pointer dereference hald: #pf Page fault Bad kernel fault at addr=0x20 pid=700, pc=0xf78da280, sp=0xff0010896b10, eflags=0x10246 cr0: 8005003bpg,wp,ne,et,ts,mp,pe cr4: 6f8xmme,fxsr,pge,mce,pae,pse,de cr2: 20cr3: 22fd88000cr8: c rdi:0 rsi:a rdx:a rcx:0 r8: 60 r9: 3a rax: 60 rbx: 42 rbp: ff0010896b50 r10:b r11: ff001089691d r12: 18ba r13:0 r14:0 r15: ff04b36e3da8 fsb:0 gsb: fbc26770 ds: 4b es: 4b fs:0 gs: 1c3 trp:e err:0 rip: f78da280 cs: 30 rfl:10246 rsp: ff0010896b10 ss: 38 ff0010896900 unix:die+c8 () ff0010896a10 unix:trap+13b1 () ff0010896a20 unix:cmntrap+e9 () ff0010896b50 mntfs:mntfs_global_len+30 () ff0010896be0 mntfs:mntfs_snapshot+111 () ff0010896d30 mntfs:mntioctl+31c () ff0010896db0 genunix:fop_ioctl+7b () ff0010896ec0 genunix:ioctl+174 () ff0010896f10 unix:brand_sys_sysenter+1e6 () syncing file systems... 2 done dumping to /dev/dsk/c1t0d0s3, offset 431030272, content: kernel 100% done: 311409 pages dumped, compression ratio 4.14, dump succeeded rebooting... If there's a better email list to post this to, please let me know. Or if this is a known issue, is it fixed in b90? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] PANIC! mounting cdrom slice on b78
And Again. I don't know enough about the panic dumps to say if they're the same or not, but I've been doing (slightly) different things st the time of each panic. Here's the latest dump: # mount -o ro /dev/dsk/c2t0d0s1 /mnt1 Jun 11 17:02:26 Boot ufs: NOTICE: mount: not a UFS magic number (0x6c8) mount: /dev/dsk/c2t0d0s1 is not this fstype # mount -F hsfs /dev/dsk/c2t0d0s1 /mnt1 hsfs mount: /dev/dsk/c2t0d0s1 is not an hsfs file system. # mount -o ro /dev/dsk/c2t0d0s2 /mnt1 mount: /dev/dsk/c2t0d0s2 is not this fstype # bash bash-3.2# mount -F hsfs -o ro /dev/dsk/c2t0d0s2 /mnt1 hsfs mount: /dev/dsk/c2t0d0s2 is not an hsfs file system. bash-3.2# mount -F hsfs -o ro /dev/dsk/c2t0d0s3 /mnt1 mount: /dev/dsk/c2t0d0s3 no such device bash-3.2# mount -o ro /dev/dsk/c2t0d0s3 /mnt1 mount: I/O error mount: Cannot mount /dev/dsk/c2t0d0s3 bash-3.2# mount -o ro /dev/dsk/c2t0d0s4 /mnt1 mount: I/O error mount: Cannot mount /dev/dsk/c2t0d0s4 bash-3.2# mount -f hsfs -o ro /dev/dsk/c2t0d0s4 /mnt1 mount: /dev/dsk/c2t0d0s4 no such device bash-3.2# mount -f hsfs -o ro /dev/dsk/c2t0d0s5 /mnt1 panic[cpu2]/thread=ff02d573d760: BAD TRAP: type=e (#pf Page fault) rp=ff001047d9b0 addr=40 occurred in module genunix due to a NULL pointer dereference mount: #pf Page fault Bad kernel fault at addr=0x40 pid=1172, pc=0xfba81ac3, sp=0xff001047daa0, eflags=0x10207 cr0: 8005003bpg,wp,ne,et,ts,mp,pe cr4: 6f8xmme,fxsr,pge,mce,pae,pse,de cr2: 40cr3: 22cbb9000cr8: c rdi: fbca24e0 rsi:1 rdx:8 rcx:4 r8: fbca26b0 r9:0 rax:0 rbx:0 rbp: ff001047dac0 r10: 270005 r11: 2c r12: 270005 r13: 270005 r14: ff001047db08 r15:0 fsb:0 gsb: ff02d50aaac0 ds: 4b es: 4b fs:0 gs: 1c3 trp:e err:0 rip: fba81ac3 cs: 30 rfl:10207 rsp: ff001047daa0 ss: 38 ff001047d890 unix:die+c8 () ff001047d9a0 unix:trap+13b1 () ff001047d9b0 unix:cmntrap+e9 () ff001047dac0 genunix:vfs_devismounted+23 () ff001047dbd0 hsfs:hs_getmdev+12b () ff001047dc70 hsfs:hsfs_mount+195 () ff001047dca0 genunix:fsop_mount+21 () ff001047de00 genunix:domount+8fa () ff001047de80 genunix:mount+d2 () ff001047dec0 genunix:syscall_ap+8f () ff001047df10 unix:brand_sys_sysenter+1e6 () syncing file systems... done dumping to /dev/dsk/c1t0d0s3, offset 431030272, content: kernel 100% done: 260327 pages dumped, compression ratio 5.74, dump succeeded rebooting... -Kyle Kyle McDonald wrote: It happenned again. Only this time it happenned when I started 'bash' (after failing[no such device] to mount s7 of the same CD.) Here's the panic this time: # mount -F hsfs -o ro /dev/dsk/c2t0d0s7 /mnt mount: /dev/dsk/c2t0d0s7 no such device # bash panic[cpu0]/thread=ff02d58d46e0: BAD TRAP: type=e (#pf Page fault) rp=ff00104e7db0 addr=a occurred in module unknown due to a NULL pointer dereference sh: #pf Page fault Bad kernel fault at addr=0xa pid=1199, pc=0xa, sp=0xff00104e7ea0, eflags=0x10246 cr0: 8005003bpg,wp,ne,et,ts,mp,pe cr4: 6f8xmme,fxsr,pge,mce,pae,pse,de cr2: acr3: 22fd88000cr8: c rdi: ff02d46a9400 rsi: ff030240d040 rdx: ff02d58d46e0 rcx:3 r8: ff02faddc628 r9: ff02faa16708 rax:e rbx: fbc77b90 rbp: ff02d4f7f048 r10: ff02d560c008 r11:0 r12: 4af r13: 2eb r14: ff02d59171f0 r15: ff02d58d46e0 fsb:0 gsb: fbc26770 ds: 4b es: 4b fs:0 gs: 1c3 trp:e err:0 rip:a cs: 30 rfl:10246 rsp: ff00104e7ea0 ss: 38 ff00104e7c90 unix:die+c8 () ff00104e7da0 unix:trap+13b1 () ff00104e7db0 unix:cmntrap+e9 () warning! 8-byte aligned %fp = ff02d4f7f048 ff02d4f7f048 a () syncing file systems... done dumping to /dev/dsk/c1t0d0s3, offset 431030272, content: kernel 100% done: 272320 pages dumped, compression ratio 5.20, dump succeeded rebooting... Is this machine suffering a Hardware failure? or is this a bug? (It could be a bad CD I suppose, but I'd think it was a bug if a bad CD can panic the system.) -Kyle Kyle McDonald wrote: Hi All, I have sNV b78 installed (I know I'm working on upgrading to b90.) I was attempting to mount /dev/dsk/c2t0d0s4, which is an ATAPI DVDROM drive containing S10 03/05 CD1, and the machine panic'd when I did 'mount -F hsfs -o ro /dev/dsk/c2t0d0s4
Re: [osol-discuss] Is there a change list for the upcoming
andrew wrote: Support for using ZFS as the root filesystem was added in build 88, but there is not yet support for installing Solaris to a ZFS filesystem in the installer. This is expected soon - possibly build 90. If you want ZFS root support, wait for build 88 and use jumpstart to perform an install. If you don't like this idea, then another month or so should see support added to the installer. This might be real good news... JumpStart is the only way I do my installs... Is what you said above really right? JumpStart installs of b88 *will* be able to install on ZFS? If so, it looks like the wait might only be about 2 weeks. -Kyle Cheers Andrew. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is there a change list for the upcoming
Glenn Lagasse wrote: * Kyle McDonald ([EMAIL PROTECTED]) wrote: andrew wrote: Support for using ZFS as the root filesystem was added in build 88, but there is not yet support for installing Solaris to a ZFS filesystem in the installer. This is expected soon - possibly build 90. If you want ZFS root support, wait for build 88 and use jumpstart to perform an install. If you don't like this idea, then another month or so should see support added to the installer. This might be real good news... JumpStart is the only way I do my installs... Is what you said above really right? JumpStart installs of b88 *will* be able to install on ZFS? If so, it looks like the wait might only be about 2 weeks. I wouldn't hold my breath. Jumpstart lives in the Install consolidation and those changes haven't been integrated yet. I won't. Thanks Glenn. Maybe Andrew was refferring to the .tar file that is available for downlaod that can patch the install server... I've tried that, and it's neat. But I'm looking to settle these machines on the 'final' diesgin for ZFS install. I'll just wait and see what 89, 90, and the others bring. -Kyle Cheers, Glenn ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Is there a change list for the upcoming b87 release anywhere?
Hi all, If my counting is right, b87 should be out any time now. What are the changes I can expect to see in it? or where can I read about them myself? Specifically, I'm curious abotu SX installing/booting from ZFS? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is there a change list for the upcoming b87 release anywhere?
Alan Coopersmith wrote: Kyle McDonald wrote: Hi all, If my counting is right, b87 should be out any time now. What are the changes I can expect to see in it? or where can I read about them myself? As always, you can see the ON X consolidation changes on our community pages: ON Flag days (high level details of big projects/etc.): http://www.opensolaris.org/os/community/on/flag-days/86-90/ Complete ON changelog: http://dlc.sun.com/osol/on/downloads/b87/ Complete X changelog: http://opensolaris.org/os/community/x_win/changelogs/ You can also usually find the JDS SFW change logs by finding their new build available e-mails in the desktop-discuss sfwnv-discuss archives. Thanks everyone. I didn't know it would be announced today or I wouldn't have posted. I knew this info comes out when the build is posted, but I wasn't sure what info was available *before* the build is posted. I'll check the links first nexttime. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is there a change list for the upcoming b87 release anywhere?
Glenn Lagasse wrote: * Kyle McDonald ([EMAIL PROTECTED]) wrote: Hi all, If my counting is right, b87 should be out any time now. What are the changes I can expect to see in it? or where can I read about them myself? Specifically, I'm curious abotu SX installing/booting from ZFS? Not gonna see that in B87. At last check, that project was targeting build 90 (but that's not a guarantee). Bummer. I thought it was 87 or 88 last time I saw the question asked on the ZFS list. (I was trying to figure out a newer answer, without actually asking the same old question again.) Oh well, that's only another month... If it doesn't slip more. ;) -Kyle Cheers, Glenn ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] How can I tell what kind of blank media is in a CD/DVD recorder before I burn it?
I'm trying to use cdrecord to burn .iso files I create on OpenSolaris. Some need to go on DVD's even when they're not bigger than a CD. Others need to go on CD's no matter what. I've been tasked with writing a front-end script for users to use to burn the ISO's, and I'd like to have the script verify that the type of media in the drive matches the requested type before I burn it. Since it's a multi-user machine with 4 recorders, we keep the drives loaded with blank media, but sometimes one drive is left with the wrong blank media, and a CD ISO is burned to DVD (or the other way around) by mistake. I've read through the cdrecord (and a couple other cdrtools) man pages, and I didn't find anything that was obviously what I wanted there. I did see the -inq option to cdrecord, and I tried it, but it only gives info about the drive itself, and not the media currently loaded in it. I also noticed that cdrecord will complain if the .ISO is too big for the media, but the most common corner case I really need to catch the case where it's too small for a DVD an should go on a CD instead. Any ideas? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] How to get platform name...
Hi, I've noticed that on the IBM machines I have here, Solaris's FMA framework is able to determine that it is running on an IBM xSeries 346 model 8840. An example of this is: Mar 17 12:48:10 Boot fmd: [ID 441519 daemon.error] SUNW-MSG-ID: ZFS-8000-D3, TYPE: Fault, VER: 1, SEVERITY: Major Mar 17 12:48:10 Boot EVENT-TIME: Mon Mar 17 12:48:10 EDT 2008 Mar 17 12:48:10 Boot PLATFORM: eserver xSeries 346 -[8840D1U]-, CSN: KQKYG4G, HOSTNAME: Boot Mar 17 12:48:10 Boot SOURCE: zfs-diagnosis, REV: 1.0 Mar 17 12:48:10 Boot EVENT-ID: 419f2d7b-9e25-c325-8486-ac33c1216729 Mar 17 12:48:10 Boot DESC: A ZFS device failed. Refer to http://sun.com/msg/ZFS-8000-D3 for more information. Mar 17 12:48:10 Boot AUTO-RESPONSE: No automated response will occur. Mar 17 12:48:10 Boot IMPACT: Fault tolerance of the pool may be compromised. Mar 17 12:48:10 Boot REC-ACTION: Run 'zpool status -x' and replace the bad device. Where does FMA get the info for the PLATFORM: line? Can I get it myself? Can I get it myself easily from a shell script? or do I need a C program? The Serial number (CSN: KQKYG4G) especially intrigues me, for asset tracking, etc. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Getting a Type7 :-)
andrew wrote: Yes - the type 6 has a beep. I got a brand new one with my old Ultra 10 I bought off eBay. ;-) I'd double check that. Type 6 is USB. An Ultra 10, was Sun's proprietary serial keyboard. Type 5c and Type 6 look almost identical except for color of the plastic (5c - white/off-white, 6 - grey and sun purple), but 5c was still Sun Serial. Type 6 changed the color, and the interface. Type 6 shipped with SunRay's and SunBlades. Ultra 10's shipped with the white type 5c. Cheers Andrew. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [solarisx86] Picking a Laptop for S10/x86
Ian Collins wrote: UNIX admin wrote: Maybe, just maybe, if the clowns at the DLC figure out, that regardless of their attempts to obfuscate the download process, that there are reasonable people who can always outwit them, then they'll give up their demented plan to marginalize SXCE. I guess you are joking, but I'll indulge in pointing the obvious: the notorious Sun marketing wants to track who is downloading Nevada. I guess they figure they can get the poor IT guys to do the slaving and perform the data mining for them. The end goal should be obvious, not all Nevada downloads are by geeks. Some of the people downloading might actually have money, or work at places willing to shell out money for overpriced Sun gear! No wonder why Sun marketing is so notoriously bad. Irritating: OpenSolaris should have NOTHING to do with Sun, especially Sun marketing. The fact that it still does is frustrating, to say the least. OpenSolaris != SXCE. Exactly. More to the point SXCE != OpenSolaris. SXCE is Nevada which is Sun Solaris, which while based on OpenSolaris is not OpenSolaris. Sun are free to distribute their OpenSolaris distributions anyway they see fit. Whether they shoot them selves in the foot is their business! That too. -Kyle Ian ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] configuring DNS
Hugh McIntyre wrote: Prashant Poman wrote: What is DNS search list?How to decide what should be there? To add to the info the previous commenters supplied: You can have a series of domain names to use for lookups. For example, some bits of Sun might use sfbay.sun.com sun.com, meaning to look for host.sfbay.sun.com, and then host.sun.com if the first lookup fails. Here at home I use i.mcintyreweb.com (for hosts inside NAT) and then mcintyreweb.com (for some other non-NAT hosts). This is not at all common though. Unless you have a very unusual setup, you probably only want a single domain, if that. Though when your domains are related like that, it's easier to just use the 'domain' keyword: domain sfbay.sun.com or domaini.mcintyreweb.com Because those will cause dns to try the listed domain, and then repeatedly remove the leftmost subdomain, and retry until there are only 2 parts left. For example: domain a.b.c.d.foo.com will search for 'host' in this order: host.a.b.c.d.foo.com host.b.c.d.foo.com host.c.d.foo.com host.d.foo.com host.foo.com 'search' is useful when your domains to search aren't related at all, like a.b.foo.com, and d.e.bar.org -Kyle Hugh. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Any reason to keep my Ultra 10?
UNIX admin wrote: Oh, I see. They have money, so let's skin them! Nice. And the prices are completely and totally out of touch with reality. No it's more like: They have needs that they feel require a higher end product, and are *willing* to pay for it. - So let's make it for them. It's the market Sun has chosen to go after. As long as that market is willing to pay, you won't see much change. You're not willing to pay for it. It's your choice. I'd be wiling to bet that if Sun did what it would take to compete at the price level you're asking for, you wouldn't prefer their servers any more, you'd think they were just as bad as the others. It maybe true that you've had a drive that failed quickly. That's not what MTBF means. The M is for 'Mean' or 'Average'. Just because some still fail early doesn't mean that the parts, processes, testing etc. that go into the model you pay more for don't (on average) last longer. If you really beleive that Sun is lying when they publish specs that are higher than for other drives, why would you trust them on other things? Ditto with memory. Memory, CPU, and ASIC vendors are known to test the chips that come off the assembly line, and label them with different part numbers, speeds, or other characteristics. Likewise Micron and the like charge more for the chips that test better. If Sun was charging more, and claiming they were better, but the specs were actually the same, then I'd agree with you. But to the best of my knowledge the specs are higher. -Kyle This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] MultiBoot Anyone Any time Sometime?
Joerg Schilling wrote: Uwe Dippel [EMAIL PROTECTED] wrote: [i]I thought I read somewhere that the fdisk spec says that there can only be one fdisk partition of a particular type, thus your experiment in creating two Solaris2 fdisk partitions is invalid and that is perhaps why Solaris does not behave correctly.[/i] I mentioned already: - Multiboot is a term introduced by GRUB and unrelated to your problem - Solaris x86 supports up to 16 slices in a primary fdisk partition. 14 of them are usable for your wishes. You don't get less partitions with Solaris than you get with Linux. So what is your problem? His problem (as I read it) is that the different Solaris installers don't (by default) make it easy to use those slices. The default GUI install for SXCE/SXDE creates only slices for the BootEnv it is creating and one other. The Indiana installer currently forces you to take the whole Solaris Partition for the ZFS root pool. Indiana should offer more choices later I beleive. SXCE/SXDE, do offer (at the grub menu) the older manual install where you could direct the installer on hom amny slices to create, what sizes, and what to put where - but to most new users it's not obvious this is there or how to get to it. -Kyle Jörg ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] MultiBoot Anyone Any time Sometime?
Joerg Schilling wrote: Joseph Mocker [EMAIL PROTECTED] wrote: I thought I read somewhere that the fdisk spec says that there can only be one fdisk partition of a particular type, thus your experiment in creating two Solaris2 fdisk partitions is invalid and that is perhaps why Solaris does not behave correctly. Correct! Jörg Hmm. I wonder why Microsoft was happy to let you make 4 primary DOS partitions? Oh wait they're Microsoft... specs don't apply to them. ;) -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Any reason to keep my Ultra 10?
UNIX admin wrote: So you your university was paying a 100% premium for hardware. I bought two full tricked out U10 directly from the Sun website when they first came out for less than that SARCASM Good to know that Sun treats everyone fairly and equally, isn't it? /SARCASM Back then, you didn't even have to be a big customer, if you were an educational institution, you got a decent discount off Hardware. Then there were preconfigured educational promo packages for things like U10's that were even better - Usually in the Apr-Jun quarter which turns out to be Sun's, and most schools 4th fiscal quarter. Software was usually even bigger discount. But that was back then. Who knows what it is now. I'm guessing that your institution wasn't experienced buying sun equipment so didn't have people in purchasing who were aware of these things. Worse they may have just asked for a quote for the U10's from the same computer hardware reseller that they ordered everything else from. Resellers were notorious for not always letting EDU's know they could get a much better price direct from Sun. If my Univ. hadn't already had a an assigned Sun Sales Rep, I never would have known about any of the promos either. But back then Sun had it's own US tele-sales 800 number, and I think if you called it and told them you were an .EDU they would have gotten you in touch with the right rep. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Any reason to keep my Ultra 10?
UNIX admin wrote: Probably a guy like me. Those were fine little boxes for what the price back then. In retrospective, considering the U10 hardware, they were outrageously expensive back then. Really? For workstations in general, and SPARC in particular they seemed cheap to me. Promotions combined with my Universities discount (no larger than other large commercial accounts got,) I often got Ultra 5's for around/under $2000, and Ultra10's for less than $3000 (I doubt those were creator3D models though.) The higher end PC's we bought at the time (94-97) were also around $1500-$2000, so It wasn't much more for a workstation or a SPARC. Especially when compared to the SPARC 2's. 10's, and 20's I was replacing. But it was a different time, I was young and high on the purple Sun logo. I'm surprised that you'd even consider buying workstation-class hardware which isn't meant to go into a rack. That's just a tremendous waste of precious space, something that's not justifiable even for the most modern desktop system. If' it's a workstation, isn't it supposed to go on a desk? Why would I put something 'workstation class' in a rack? That's what the rack mount servers are for. Or am I missing something? -Kyle Again I say, the Ultra 10 was a quiet machine. But maybe I'm just deaf. Years of fan noise whirr from a rack full of servers less than a meter away, with fans blowing at full speed because there's no CPU stepping driver in Solaris 10, will do that to one. I should know, since I just described myself (:-/ Wrong. I'll put the framerate and OpenGL tessalation rate with gourand shading from that Creator card up against your $75 ATI or NVidia card and see what the truth is. Sorry but I just don't see the comparison. What good will that graphics test do you when it is time to package Oracle, or compile a whole webstack worth of PHP dependencies? If you have ever tried compiling on an Ultra5 or Ultra10 hardware, you would have learned the new levels of pain and a whole new definition to the age old watching the paint dry saying. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [advocacy-discuss] OpenSolaris Developer Preview
Lurie wrote: Right, as a Solaris replacement Indiana isn't there yet by a long shot. true. but I don't think it's because of the reasons you mentioned (It misses SPARC support, should be there within several months liveupgrade, this is superceded by zfs cloning on upgrades But that won't help people use live-upgrade to move to IN will it? upgradability from pre-Indiana releases I don't think this will ever be possible ? Then it's not really a Solaris replacement. NV can do this. and has too much uncontrolled entropy (for lack of a better word) yeah, it needs time. +1 This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [advocacy-discuss] OpenSolaris Developer Preview
First I'd like to say, that I searched high and low in my inbox for the original message Mario is replying to. I'm not even sure who wrote it. I'd much rather have replie dto it directly. Mario Goebbels wrote: It's true, OpenSolaris (Indiana) will replace Solaris Express Developer Edition after SXDE 1/08. I think (and it's just my interpretation) that this really means 'SXDE'. Meaning Sun plans to keep making SXCE (Sun does most of the work for that internally anyway,) and that instead of putting a few of those builds a year through extra QA to be 'stamped' as good for developers to use, they'll be directing the developers to use Indiana instead. Not all bad in my opinion since we'll still have access to SXCE (I assume,) and I agree that it doesn't make sense to polish 2 distributions for distribution to developers, which I beleive I understand correctly as the goal - attacting more and more developers. Indiana is not an experiment--it is the preview of Solaris Next now. Well. I'm not sure how you can know that Solaris Next will look anything like Indiana, since so much of Indiana has yet to go through ARC review, and could change. Not to mention that so much of 'Solaris' is just missing from Indiana. It seems to me that NV (aka SXCE) is more representative of the next version of Sun Solaris. (yes Sun Solaris, since NV/SXCE includes so much that isn't in OS, I don't know how it can be called OpenSolaris.) I wonder how many of the newly attracted developers who beleive the marketing that Indiana is the future are going to like re-working their code, and figuring out solutions to the changes ARC review will require to the things in Indiana. Since it doesn't make sense to maintain two previews, we are phasing out SXDE. Not that I don't get the reason behind the decision, actually I feel positive towards it because we get things like ZFS root and Caiman quicker this way, but for being a community thing, there's quite a bunch of things being decided in private. I think there is quite a bit of good in IN, and NV. I don't know how much is happenning in private, but there is the appearance that there is some, and that it's not possible to tell how much, and when you have appearances like that, reality doesn't matter much. and I worry about that wuite a bit when it comes to building a community. Such an attitude towards those working in the area of marketing is disheartening, and to me, against our core community values. I think I (at least) expect Marketing to under stand the importance of public image, and following through on promises made. I find it hard to beleive (unless you know something I don't) that you're wililng to promise that Indiana is (exactly) the future when it seems it is really a playground or concept car where new ideas are being tried and field tested. I certainly wouldn't expect the auto industry to market a concept car to aftermarket part developers as the the next model of their vehicle. Only to upset them and make them feel misled when only features from the concept appear in the real next version of their vehicles and then not exactly the same either. Forcing developers of add-ons to your product to rework their designs after the y followed and relied on your promises doesn't exactly strike me as a good way to build a critical mass of developers. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Right mailing list for NIS/NameService discussions?
I see no [EMAIL PROTECTED] mailiing list. (I also didn't see a nameservice-discuss, or ldap-discuss list either) Is there a goo list whee one can find experts or developers for the differen nameservices in solaris? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: On Feb 6, 2008 4:14 PM, Kyle McDonald [EMAIL PROTECTED] wrote: Shawn Walker wrote: On Feb 6, 2008 3:37 PM, Kyle McDonald [EMAIL PROTECTED] wrote: Shawn Walker wrote: On Feb 6, 2008 3:18 PM, a b [EMAIL PROTECTED] wrote: Oh, and as far as the enterprise argument, go talk to some of the enterprise sysadmins who post here; they hate that /bin/sh isn't anywhere near portable across systems. It's also not part of any standard, so how could it really? That doesn't excuse having a good standard shell for /bin/sh. What reason is there for the 'standard' shell to be named /bin/sh though? You didn't answer this one. You seem to think that 'bin'sh is the name of the 'default system shell', and therefore if it's desirable for the default system shell to be POSIX compliant, then /bin/sh has to be also. Your premise is false. the name /bin/sh is not annointed with any special posers to be any more important of a shell on a system than any other. It's just the traditional name for the 'bourne shell'. People have written millions of line s of script code that depends on the behaivior of the bourn shell being found at /bin/sh. You want to tell all of the users of that code 'Opps, sorry. This is progress.' instead of just using the standarized, portable, method for loacating a standards compliant shell at whatever path the system decides to install it. When there is a standards compliant shell at another name that will work, Don't know; don't care. All I know is that other platforms are moving that way and it can only be a good thing in the long-term. Only if the move is really a step forward. Linux put bash as /bin/sh because GNU didn't have another sheell at the time. Now, from posts in this thread, it appears some are looking to get away from 'bash' because it wasn't a good choice. I guess it was good we didn't follow linux's lead back then huh? Just because everyone is doing it doesn't make it good or right. And I don't aggree it's 'good' or 'right' to do the same thing just to be the same either. The long-term view is that other platforms will have a POSIX shell at #!/bin/sh and OpenSolaris, in my view, should have one as well to meet those changing market conditions. Changes to 'market conditions' are made by the customers, not the developers. Just because a developer makes a change does not mean his customers were asking for it. Here in this list we have heard from several Sun customers who are specificall asking for this not to happen. There was I think one (pother than you) who thought it was a good idea. Where is the loud call for this form the market? There is a mechanism in POSIX for a script to determine where on a system a POSIX shell is located. Any script author who wants to write his script once for all posix platforms should use that mechanism to make sure his script is run. *If they haven't done this, then they haven't written a POSIX portable script.* Trying to use software on a system other than what the developer intended is asking for problems. Obviously the developer didn't test it on these other platforms either. I disagree. You don't think developers should not test their code on all the platforms they want it to run on? You think you should have guarantees that a program from one platform will run on any other without change or testing? When I want that, I look at languages that run in a virtual machine environment. Not Shell scripts. Given that there is no standard for how /bin/sh should work, it's possible that those scripts even take advantage of non-standard differences of the /bin/sh, and that they still won't work on strictly POSIX compliant /bin/sh that doesn't also emulate the other behaviors of the /bin/sh sheel they written for You missed what I really said: Not only will scripts that work today break. But all those scripts you're hoping to make just magically work will probably still need work! Some things become standards because the market adopts them. No. Standards are things that a product or porogram can be tested against and verified to meet. Not every standard comes about as the result of a committee; some come about by changes in the market. Maybe in the beginning, but they are documented, considered, revised, commented on. etc. before becoming standards. They're not created just from shear critical mass. If these scripts will magically start working when /bin/sh is ksh93 (which I doubt) then they'll also start working if the users edit them to start with #!/bin/ksh. And sinve that is (more?) standards compliant,that should still work on the platforms the scripts already work on. That is not really a practical option in the long term. The only practical option long term is to start writing portable scripts using standards that platforms and programs can
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: On Feb 6, 2008 4:44 AM, Joerg Schilling [EMAIL PROTECTED] wrote: Shawn Walker [EMAIL PROTECTED] wrote: You need to install GNOME libs in order to run a X-less base OpenSolaris installation. Do you believe this is correct? No, but I suspect it's a result of packaging, not software. If this should read that you believe it is not correct, I concur... Yes, I don't think one should need GNOME libs in order to run an X-less base installation -- as long as DBUS and HAL are rightfully not considered GNOME libs; since they are not in the relevant sense. Agreed. It was just an example of how bad things can get when dependencies aren'ta primary consideration during integration. There are general structural problems with the arbitrary project boundaries that should be fixed in future. If I did put parts of the cdrtools source into a separate package that you need to doenload from a different location, people would be angry with me Yes, I am trying to say that packaging is the issue here, not software. No. Dependencies are the issue. Many dependencies are created when the code is written. And some dependencies won't be fixable by changing the packaging. Dependencies need to be considered during development, not after. Hard thought needs to be put into what the use case of a package might be, and both how reasonable it is to require another package in that case, and what problems requiring the other package may cause. I'm all for improving the Solaris packaging technology. But I don't beleive these problems will be fixed, no matter how much improvement is made in the packaging tools, or file formats. Also I think most dependency problems that can be fixed by re-packaging, can be fixed today with the current pacakging tools. It just takes a finer resolution of packges, and likely an explosion in the number of packages. The problems in the packaging, and the problems being solved in the packaging tools I think, are largely ( though maybe not entirely) orthogonal, and unrelated. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: On Feb 6, 2008 6:02 AM, Joerg Schilling [EMAIL PROTECTED] wrote: Shawn Walker [EMAIL PROTECTED] wrote: No. You mistaken. We didn't change anything related to core libraries and applications. Changes only related to packaging but than again, packaging supposed to be changed, or otherwise what is the value behind any of distribution derivatives? No, I am not mistaken. Just because you didn't change the existing userland, but added to it, makes you divergent. Remember that ON is a bundle of *all* the userland. Not true: ON contians e.g. parts of the new volume mamagement system only. You mistaken again - SVR4 packaging is well supported (or at least we try to be compatible here) option for us. *And* it is NOT part of ON. No I am not. IPS != SVR4 packaging. I suspect IPS will eventually be part of ON. When that happens and as SVR4 is phased out, that will make Nexenta very divergent in terms of packaging. To be correct, if Indiana introduces a different packaging system, it is Indiana that introduces divergence. Really Joerg; that's just silly. Sun is the one spending time and money on Indiana and obviously plans to see it incorporated into Solaris. Indiana isn't introducing divergence; at least none relevant to this thread. I think an analogy that might clear up what indiana is or isn't might be to think of it like the concept cars some car makers send to to car shows. You probably won't ever see that same exact car for sale in a dealer, but you may see (over varying periods of time) different features, most likely refined, and possibly even hard to recognize, from them appear in the regular models that are later available for sale. Indiana to me sounds like a testing ground for several projects to make early access available to the community to what they are doing. Each of these projects I imagine will integrate (or not) into Sun's Solaris at varying points in the future, and the ARC reviews may or may not require them to end up different than they appear in indiana. I'm alright with this. It's good to have an experimental playground for new things to be tried. I'm confident that the ARC will do it's job well, when integration comes around for each project. If there's one thing I've always thought Sun did well with Solaris (and my major objection to linux) it's the real engineering, and architecture, thought, consideration, and review that goes into Solaris. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: On Feb 6, 2008 10:31 AM, Kyle McDonald [EMAIL PROTECTED] wrote: Shawn Walker wrote: Yes, I am trying to say that packaging is the issue here, not software. No. Dependencies are the issue. Many dependencies are created when the Dependencies are a result of packaging in most cases, so I don't see how what you are saying is much different than what I am saying. I'm fairly certain we're effectively saying the same thing. No you're missing the distinction (it may be fine, but it's important.) Hypothetically, Say you're creating some new modular administration tool for all of Solaris, You're thought is to make it web based, and write it in PHP, and use Apache to have it run by default. Serious thought needs to go into whether or not you want basic installs of Solaris to now be *forced* to install Apache and PHP. Alternatives should be considered. Or You're integrating some new feature that you have to have a newer version of Perl than is in Solaris already. Do you just add a second or third version of perl to solaris for you're project? Do you work hard to find a way to get what you need in the existing one? Do you campaign and help to get the other features that use the older versions to move up to your version? Do you Punt on Perl and go back to C? I don't know what the right answer is, but I know I'd hate to end up with 3 version of Perl on my machine. Some base things need to be defined as 'base Solaris' building blocks, and the code for other software allowed to depend on being there. It should be a rare exception that an optional piece of solaris is allowed to require a part that isn't one of these basic blocks. I doubt one group of blocks could be made to work. However, I think a layered set of multiple groups of blocks could be designed so that exceptions would be very rare indeed. But tought and engineering needs to go into this list of goupr of building blocks needs to be available when projects are being planned and coded, not just when they are packaged. I wasn't suggesting packaging technology was a solution to this. Oh. My misunderstanding. Also I think most dependency problems that can be fixed by re-packaging, can be fixed today with the current pacakging tools. It just takes a finer resolution of packges, and likely an explosion in the number of packages. The problems in the packaging, and the problems being solved in the packaging tools I think, are largely ( though maybe not entirely) orthogonal, and unrelated. Didn't I just say the problem is the packaging? I was trying to add that I believe fixing packaging boundaries, and dependencies is a higher priority than new packaging technology. Enough so that a coordinated examination and effort (Is there one already?) across all of solaris would be a good idea, rather than leaving it to the different projects to realize the limits of their current pacakges, and fix them at their own pace. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
Joerg Schilling wrote: Shawn Walker [EMAIL PROTECTED] wrote: 1) *NOT* POSIX compliant If you have problems with that, you may modify /etc/passwd Since it seems that one group cares more about what they end up with when they login as, or su to root, and the other group seems to care more about scripts that use #!/bin/sh running correctly, then maybe, just maybe (dare I say it?) the solution is to just make the default passwd entry for root specify /bin/ksh (or ksh93 if they aren't the same?) That seems to cover most if not all of the concerns I've heard voiced, unless I missed something. Personally, when I work as 'root' I automatically get the shell from my own account, not root's so this change doesn't affect me much. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: On Feb 6, 2008 11:41 AM, Kyle McDonald [EMAIL PROTECTED] wrote: Shawn Walker wrote: On Feb 6, 2008 10:31 AM, Kyle McDonald [EMAIL PROTECTED] wrote: Shawn Walker wrote: Yes, I am trying to say that packaging is the issue here, not software. No. Dependencies are the issue. Many dependencies are created when the Dependencies are a result of packaging in most cases, so I don't see how what you are saying is much different than what I am saying. I'm fairly certain we're effectively saying the same thing. No you're missing the distinction (it may be fine, but it's important.) snip No, I'm actually not. Development decisions had no relevance (in my mind) to the original perceived issue in question. DBUS and HAL are reasonable dependencies to have, and I don't see any practical alternatives unless you want to have to maintain multiple methods of doing the same thing. Yes in that example they were reasonable. Should have been in separate package, and all would have been well. I'm trying to make 2 points: 1) The case for the integration of the new removable media volume manager should have identified this problem, and required it to be fixed before integration. In other words the development process for proposing, considering, and integrating changes, should have packaging as a high level consideration. 2) There are many other examples where the solution is not as easy as DBUS and HAL. a) Xscreensaver. The dependency on GTK might be solved similiar to DBUS and HAL with packaging. It's my suggestion though that if the dependencies for XscreenSaver were considered harder, then a better solution might have been found for integrating the Accessibility technology into it. For instance it could have been coded to dynamically load (and call into) the accessibility libs only if they were present. This would have allowed it to be installed and function with out any GNOME packages, and the the dependencies they bring, and yet would have enable that functionality if they were present. b) The perl example I listed in my last email, actually happened in Solaris. I don't remember when (Solaris 8 or 9 maybe.) I didn't need perl on any of my machines, I was willing to live with one version, but was unable to remove either one, because that require removing features I wanted to keep. Why couldn't these other features use the same perl? (limited development resources, I know - but still not a good design.) Both of those examples requre thought and consideration at design and coding time, and no packaging changes are going to fix the dependencies. I was trying to add that I believe fixing packaging boundaries, and dependencies is a higher priority than new packaging technology. Enough so that a coordinated examination and effort (Is there one already?) across all of solaris would be a good idea, rather than leaving it to the different projects to realize the limits of their current pacakges, and fix them at their own pace. In the original case being discussed, I still think it is packaging (which I think boundaries falls within) Yes I agree package boundaries falls in the subject of packaging. that was the issue and not development choices. In that case yes. But not all cases. -Kytle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: On Feb 6, 2008 11:59 AM, Kyle McDonald [EMAIL PROTECTED] wrote: Joerg Schilling wrote: Shawn Walker [EMAIL PROTECTED] wrote: 1) *NOT* POSIX compliant If you have problems with that, you may modify /etc/passwd Since it seems that one group cares more about what they end up with when they login as, or su to root, and the other group seems to care more about scripts that use #!/bin/sh running correctly, then maybe, just maybe (dare I say it?) the solution is to just make the default passwd entry for root specify /bin/ksh (or ksh93 if they aren't the same?) That seems to cover most if not all of the concerns I've heard voiced, unless I missed something. Personally, when I work as 'root' I automatically get the shell from my own account, not root's so this change doesn't affect me much. The issue doesn't have to do with which default shell the user has; It has to do with what shell is used when a script is executed that has #!/bin/sh at the top. For system administrators that have to maintain software for a non-heterogeneous environment, it is one more thing they have to deal with. I think you mean 'non-homogeneous'. ;) Otherwise you'd have no problems because you'd have no different platforms. If linux is one of your platforms though, then you still have problems, since /bin/sh is bash on there, and not ksh93, and you'll still have feature, and behaviour differences to work around. -Kyle Ensuring that #!/bin/sh was a POSIX-compliant shell on the majority of UNIX and UNIX-like environments would go a long way towards easing administrative and development pain for many individuals. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: On Feb 6, 2008 1:16 PM, Joerg Schilling [EMAIL PROTECTED] wrote: Shawn Walker [EMAIL PROTECTED] wrote: Compared to bash, /bin/sh (the Burne Shell) is bug-free. I don't think you'll find many users that agree. This is because most bash users don't understand POSIX nor care about bugs. They are not even interested in knowing the reason for a problem. Exactly! So why not give them a shell that is POSIX and that is full featured and provides something that makes them feel much more at home. How is that an 'Exactly!'??? If they don't understand what it means to be POSIX? and they don't care if there are bugs, or care why things are the way they are, How will they notice that you've given them these things they don't care or know enough to recognize? How will it make them more at home? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
Alan Coopersmith wrote: Kyle McDonald wrote: a) Xscreensaver. The dependency on GTK might be solved similiar to DBUS and HAL with packaging. It's my suggestion though that if the dependencies for XscreenSaver were considered harder, then a better solution might have been found for integrating the Accessibility technology into it. For instance it could have been coded to dynamically load (and call into) the accessibility libs only if they were present. This would have allowed it to be installed and function with out any GNOME packages, and the the dependencies they bring, and yet would have enable that functionality if they were present. The missing link here is deciding it's worthwhile to do that work. Yes. I expected that there will be times when the work is considered too large a job for the immediate timeframe. It was just the best example I could come up with, to show what I was thinking of, and explain where I think the *process* should change to at least stop, consider options like this and make a consious decision whether to require the work be done now, postpone it for the future, or skip it forever. Maybe this happens now. But I get the (possibly wrong) feeling that some of these things aren't really even thought about. When xscreensaver was added to Solaris during one of the Solaris 9 update releases it was explicitly to provide a screensaver for the GNOME 2.0 desktop.Making it depend on GTK+ was a goal of that work - making it installable without any GNOME libraries was not, and is still not a goal today for those at Sun paid to do this work. These resource constraints are always going to exist. Even if a community memeber wnated to make these changes, it seems to me that they'll always be playing catchup, always be after the fact, because I don't see any company allowing the community to say Wait, don't integrate that until we have a chance to do all the other work that we think needs to be done, that you're not willing to pay for. So what can we do to stop situations like these from even being introduced into solaris to begin with? -Kyle If a community member felt that this was so worthwhile to put in the work themselves, the code is open, and we take contributions, but Sun has no reason to spend its resources doing it ourselves. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: On Feb 6, 2008 2:26 PM, Kyle McDonald [EMAIL PROTECTED] wrote: Shawn Walker wrote: On Feb 6, 2008 1:16 PM, Joerg Schilling [EMAIL PROTECTED] wrote: Shawn Walker [EMAIL PROTECTED] wrote: Compared to bash, /bin/sh (the Burne Shell) is bug-free. I don't think you'll find many users that agree. This is because most bash users don't understand POSIX nor care about bugs. They are not even interested in knowing the reason for a problem. Exactly! So why not give them a shell that is POSIX and that is full featured and provides something that makes them feel much more at home. How is that an 'Exactly!'??? If they don't understand what it means to be POSIX? and they don't care if there are bugs, or care why things are the way they are, How will they notice that you've given them these things they don't care or know enough to recognize? They do care and they do recognize bugs and problems with Solaris /bin/sh. GNU/Linux users don't notice these issues with bash is what Joerg was talking about. ANd giving them ksh (or even dash I imagine) on Solaris isn't going to be that noticeable then, or any better. Theonly thing they'll appreciate is giving them bash complete with it's bugs. How will it make them more at home? A modern shell, such as ksh93, has functionality and locale support that is near equivalent or superior to bash. But if they don't care, why would they notice? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: On Feb 6, 2008 2:35 PM, Kyle McDonald [EMAIL PROTECTED] wrote: Shawn Walker wrote: On Feb 6, 2008 2:26 PM, Kyle McDonald [EMAIL PROTECTED] wrote: Shawn Walker wrote: On Feb 6, 2008 1:16 PM, Joerg Schilling [EMAIL PROTECTED] wrote: Shawn Walker [EMAIL PROTECTED] wrote: Compared to bash, /bin/sh (the Burne Shell) is bug-free. I don't think you'll find many users that agree. This is because most bash users don't understand POSIX nor care about bugs. They are not even interested in knowing the reason for a problem. Exactly! So why not give them a shell that is POSIX and that is full featured and provides something that makes them feel much more at home. How is that an 'Exactly!'??? If they don't understand what it means to be POSIX? and they don't care if there are bugs, or care why things are the way they are, How will they notice that you've given them these things they don't care or know enough to recognize? They do care and they do recognize bugs and problems with Solaris /bin/sh. GNU/Linux users don't notice these issues with bash is what Joerg was talking about. ANd giving them ksh (or even dash I imagine) on Solaris isn't going to be that noticeable then, or any better. Theonly thing they'll appreciate is giving them bash complete with it's bugs. A working backspace key isn't going to be noticed? I was under the (possibly wrong) imporession that that was a terminfo, or other terminal definition problem. Not the shell. Their programs suddenly working without requiring the shell scripts for them to be changed isn't noticeable? And people who's programs ans shell scripts suddenly stop working won't be noticeable? Who's going to check all the scripts in the world and update them? Not just the scripts in solaris itself. Just think of all the Per or Post install or remove scripts in the packages in BlastWave, or aome other repository? What solaris user is going to be happy when they want to install VRTSvxfs pacakge and it fails? If you want to be able to write modern portable POSIX shellscripts then you should push for all the other UNIXes to have a /bin/ksh, and write your scripts with #!/bin/ksh With the exception of Linux (and you might be able to fix that for your machines with 'ln /bin/sh /bin/ksh' - I don't know.) I'm pretty sure the other unixes already have a decent ksh. -Kyle Working locale support won't be noticed? Forgive me, but I think you don't realise just how broken /bin/sh is. How will it make them more at home? A modern shell, such as ksh93, has functionality and locale support that is near equivalent or superior to bash. But if they don't care, why would they notice? They do care and do notice. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: On Feb 6, 2008 3:18 PM, a b [EMAIL PROTECTED] wrote: Oh, and as far as the enterprise argument, go talk to some of the enterprise sysadmins who post here; they hate that /bin/sh isn't anywhere near portable across systems. It's also not part of any standard, so how could it really? If they want to write portable scripts they should use /bin/ksh. It's that simple. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: On Feb 6, 2008 3:37 PM, Kyle McDonald [EMAIL PROTECTED] wrote: Shawn Walker wrote: On Feb 6, 2008 3:18 PM, a b [EMAIL PROTECTED] wrote: Oh, and as far as the enterprise argument, go talk to some of the enterprise sysadmins who post here; they hate that /bin/sh isn't anywhere near portable across systems. It's also not part of any standard, so how could it really? That doesn't excuse having a good standard shell for /bin/sh. What reason is there for the 'standard' shell to be named /bin/sh though? When there is a standards compliant shell at another name that will work, If they want to write portable scripts they should use /bin/ksh. It's that simple. They're not the ones who wrote the scripts from what I gather. They are the ones trying to use software across multiple systems. Trying to use software on a system other than what the developer intended is asking for problems. Obviously the developer didn't test it on these other platforms either. Given that there is no standard for how /bin/sh should work, it's possible that those scripts even take advantage of non-standard differences of the /bin/sh, and that they still won't work on strictly POSIX compliant /bin/sh that doesn't also emulate the other behaviors of the /bin/sh sheel they written for. If these scripts will magically start working when /bin/sh is ksh93 (which I doubt) then they'll also start working if the users edit them to start with #!/bin/ksh. And sinve that is (more?) standards compliant, that should still work on the platforms the scripts already work on. Is the bourne shell old? Yes. Are different implementations of the Bourne Shell incompatible? Yes. But also: Is /bin/sh the tradition location/name of the Bourne Shell? Yes. Platforms should feel free to stop including a /bin/sh altogether. There's no reason to have one if you don't want one. But what they replace it with shouldn't be called /bin/sh unless it is. At least with a POSIX shell for /bin/sh, there is a far better chance of getting scripts written by third parties to work. Only if they were written to only use strictly POSIX syntax. And if that's the case then they should also wrtie tehm to use the things the POSIX standard specifies in order to find the POSIX shell they want to run in. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
Joerg Schilling wrote: I still cannot understand why a Sun controlled login (via PAM) depends on Mozilla's /usr/lib/mps/libssl3.so but /usr/sbin/pkgadd depends on /usr/sfw/lib/libssl.so.0.9.8 This is the problem I'm more concerned about than including the 'Linux Suite' of software. I'm more concerned about Solaris *depending* on this mulittude of libraries and binaries strewn all across the filesystem and more importantly the packages. I'm still of the belief that having the 'linux suite' is nice to have for people looking for it, I don't have a problem with installing it by default even, but it should be optional, and easily removed.I think we should all think hard and set some hard and fast rules for what and how other parts of solaris can depend on them. I'm happy to see new things in Solaris, and the work on the packing system software is welcome. I just think that the way pieces of solaris are allowed to depend on other things, and the way the files are divided into packages is a much bigger problem than the technology available to install and remove, and manage these packages. For instance, I understand that in the linux world 'DBUS' and 'HAL' have come from the same (or closely connected) community that GNOME comes from. So I don't see a problem with the GNOME team at sun being responsible for integrating them into Solaris. But when the program that manages automatically mounting removable media was integrated and required these API's, libraries, and daemons, I think it should have been obvious to move them to some other more 'system level' package and not allowed to stay in large GNOME packages that have a multitude of other package dpenedencies. Right now you can't install a headless machine without GNOME that will still mount a CD when it's inserted. Another example, is Xscreensaver. I always used to be able install that with only X11 installed. Now not only does GNOME have to be installed too, So does large portions of Evolution!! What on earth does Evolution have to do with a ScreenSaver? So, If attention is paid to dependencies, and the likely use-cases when the files are divided among packages, I don't have much problem with this additional software. But today it's already too much like linux for me. The situtation described above about upgrading one piece, and being forced to upgrade half the machine is for me here already. I can't remove a large number of pacakgeswithout removing ones I want. I can't add ones I want without adding a huge number of pacakge I don't want. And I don't accept the argument that 'Disk is cheap - Install it all!' -Kyle The Jörg ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
Alan Coopersmith wrote: Kyle McDonald wrote: Another example, is Xscreensaver. I always used to be able install that with only X11 installed. Now not only does GNOME have to be installed too, So does large portions of Evolution!! What on earth does Evolution have to do with a ScreenSaver? In order to support users who need accessibility helpers to unlock their screens, Sun modified xscreensaver to use a GTK-based unlock dialog and the GNOME accessibility framework. It should only depend on the GNOME base libraries - I have no idea why there would be any linkage to Evolution unless the GNOME base libraries or accessibility packages brings them in - the package dependencies in xscreensaver's package (SUNWxwsvr) don't specify them. It's good to enable accessibility. Though even that should be optional I feel (I'd opt for it but I don't know if everyone would.) You're correct, that XscreenSaver only directly requires a few packages. It's the packages those packages require, and so on that become the problem. Is anyone a fan of installing systems that have unsatisfied package dependencies? Will the libs Xscreensaver needs work even if the dependencies of the packages they come in aren't met? Will Xscreensaver work without the accessibility features if the library packages are left out? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
Moinak Ghosh wrote: BTW on a side note I just checked the dependencies here. SUNWhal and SUNWrmvolmgr depend on SUNWgnome-base-libs. SUNWgnome-base-libs != GNOME. Then why does it say 'gnome' in the name? How would someone new to Solaris know that it wasn't part of gnome? Why wouldn't they question why they needed this part of GNOME (even if it didn't pull in X11 stuff) on a headless machine? GNOME included in Nevada consists of about 181 packages as of B78. However SUNWgnome-base-libs does have a bunch of other dependencies including Xorg libs that are redundant on a headless system. Those are my my main point. Another example, is Xscreensaver. I always used to be able install that with only X11 installed. Now not only does GNOME have to be installed too, So does large portions of Evolution!! What on earth does Evolution have to do with a ScreenSaver? Again, that's a packaging issue and has absolutely nothing to do with this mysterious Linux suite you keep mentioning. Yep. SUNWxwsvr also includes Xscreensaver GNOME integration. Maybe that can be separate package. Will the base Xscreensaver run with out the integration files? If so then I agree it'd be great if it was seperated. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Tab auto-completion doesn't work?
UNIX admin wrote: on none of the linux distributions tcsh is the default shell; better advise him something familiar such as bash :) And what then? Breed an army of users using creating bash script monstrosities? How are they ever going to learn something new (and good) if we never show it to them? Then teach them ksh (or ksh93) not tcsh. Teach them something where the script language is useful. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Any update on build 79 release
Derek Cicero wrote: Mike DeMarco wrote: check out this post: [osol-announce] No update on SXCE Build 79 Looks like a major issue is brewing. I have been asking but I have not heard an update on the status. I would have to assume at this point they are going to skip 79 and the next release will be 80. As soon as I hear something I will post an announcement. What is the life cycle of a bvuild within Sun before it's seen outside as SXCE? and how much time normally passes between states? Before I ever saw SXCE b79 mentioned, I saw several posts from Sun Employees stating they were running NV b81... With SXCE b78 being delayed so long, I'm surprised the jump to b80 wasn't made before b79 was even mentioned. -Kyle Derek This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Anyone know how to purchase a b78 DVD?
James Carlson wrote: Dennis Clarke writes: My download speed is way to slow, anyone know where I can purchase a DVD? Well we have two problems. Firstly, you can not freely redistribute the snv_78 DVD so therefore I can not just burn the media for you. Secondly ... it isn't for sale. You can, though, get a Developer Edition DVD for free: http://developers.sun.com/sxde/download.jsp And I believe an update to SXDE is coming shortly that will bring it up to something (at least as new if not) newer than b78. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Crontab -- is cron.d not really a .d directory?
David Dyer-Bennet wrote: I bet that since you're coming from a Linux background, you're coming to Solaris with a understanding that what's in Linux is what's been Universally True since the dawn of *NIX. However, this isn't as Linux distros as we know them today have been around for only ~15 years. SunOS goes back father than this. For those of us who have used SunOS/Solaris since before Linux, we see the Linux as the perversion here... so who is right or wrong is a matter of perspective depending on who you ask. You'd lose. My first personal contact with Unix was around 1983, at DEC-Marlboro, and that was Ultrix-32 on a Vax (I'd been developing software professionally for 14 years before that). Then I had contact with SunOS at Network Systems in the 1986 timeframe (in fact I was de-facto admin for one server and two workstations hanging off it). Then I was news admin at mtn.org and shortly after at gofast.net, on SunOS/Solaris boxes (I forget exactly where we were on that line) in the early 90s. My first Linux box ran kernel 0.99pl13, I believe, but that was after I'd had quite a lot of time on Sun and other Unixes. No, the trouble is that I haven't touched Solaris *since* then, and it's changed a lot from what I dimly remember, and in directions different from what Linux was doing. And I develop on and for Linux in my day job at the moment, so that's what keeps getting reinforced. One thing that may help is to prepend /usr/ucb to yout $PATH before /usr/bin. This will bring the Berkley UNIX flavor of many commands to the forefront. I think this will help because all the UNIX variants you list above (except Linux which isn't UNIX) are of the Berkley flavor - it sounds like the the SunOS/Solaris you mention was the SunOS 4.x/Solaris 1.x variety. At the very least it will get you the Berkley type 'ps' options, ls output, and probably the touch and date options you're used to. Solaris 2 switched sun to the System V flavor by default, and left the berkley flavor in /usr/ucb, and added one or more POSIX flavors too. I think one of the things Solaris2+ has that other UNIX varieties don't (like SMF, and ZFS) is this ability to change flavor just by adjusting your $PATH. Solaris 2 (IIRC) arrived in the earliey 90's, but really didn't seem to get any traction till Solaris 2.4 or 2.5 in '95 or so. Also note, that all the other UNIX brands around from major players are also (to the best of my knowledge) System 5 flavor, many with out the Berkely /usr/ucb options: AIX, IRIX, HP-UX. There are a bunch of standards an OS needs to meet to be considered UNIX, and Solaris still tries to meet them, so that people who expect that behavior don't end up feeling exactly how you are feeling now. Without the standards I think that the feelings of chaos many of us feel when using Linux would appear on Solaris also. Well, here we are in a Open Source world. Never assume never and participation is where the rubber meets the road in the purest sense of the definition. I'm sure you can find people other than yourself who have their own bone to pick with Solaris's cron facility. If you truly want to be here in a way that's more than being a Tourist, feel free to organize and front your ideas and ask others to join you in adding features to cron. Describe a design, find someone (or yourself) to provide code diffs and manage the review process for it. If you want to just be a Tourist here, that's perfectly fine too. Just keep the vitriol to an absolute minimum and remember that you brought yourself to try Solaris in the first place. That's all... First, if I'm heading that direction, I should look at what the other distros are packaging; they may very well have more the feel I'm looking for. That's true. Several of the other distributions set out to provide a much more linux like face to solaris. Also, one thing I'm trying to communicate is that, to an awful lot of people coming to Solaris today, it looks and feels archaic. Capabilities I'm used to finding are missing from all sorts of tools, in particular; that looks like lagging behind the rest of the world. Different is a thing that happens, and if one is investigating a *different* system, it's expected to some extent. Better is a good thing -- ZFS is better for what I want than the alternatives I know of, and I'm putting up with a lot of pain on account of wanting that, in addition to learning ZFS itself from scratch. The svc administration system, although I don't understand it thoroughly yet, shows definite signs of being significantly *better* than what any Linux distro I've worked with has in that area. The in-kernel CIFS system has the possibility of being definitely *better* than SAMBA, though I haven't worked with it yet (I've got a samba-based solution in production right now at home). Zones are probably a very useful and
Re: [osol-discuss] Crontab -- is cron.d not really a .d directory?
Joerg Schilling wrote: Kyle McDonald [EMAIL PROTECTED] wrote: One thing that may help is to prepend /usr/ucb to yout $PATH before /usr/bin. This will bring the Berkley UNIX flavor of many commands to the forefront. I think this will help because all the UNIX variants you list above (except Linux which isn't UNIX) are of the Berkley flavor - Be extremely careful if you _really_ plan to do this. It will create you an environment where you cannot compile anymore. Yep. I was talking about the interactive 'experience'. The UCB variant of the commands did not make it into the standard and recent software will not compile in a UCB environment. At source level, Linux does not use the UCB flavor. Solaris 2 switched sun to the System V flavor by default, and left the berkley flavor in /usr/ucb, and added one or more POSIX flavors too. I This switch happened 18 years ago and it was also a result of the upcomming POSIX standard (the first one has been approved in 1988). I can understand where Linux being the newcomer (albeit more than 15 years old now,) seems to be the new and better way of doing things. How ever I've used several UNIX variants over the past 15+ years, and when you need to bounce between them often it's usually Linux that looks like the odd ball one doing things a different way. Where do you believe is Linux better than other UNIX? I don't. All I said was that I can see how others might arrive at that conclusion. The strange observation with Linux is that e.g. the program ifconfig on Linux has more deviations from the UNIX flavor than the program ipconfig on MS-WIN. Yep. Don't be. Sharing is how we all learn. I made this BSD to SVR4 switch back in '94-'95. It was rough for me too ( I bet going back would be even tougher for me now.) That was when I was just starting to leave I did it in 1992 and it was not a big change anyway. You basically have to learn how to set up your login environment. Exactly. -Kyle Jörg ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nameclash on svn_77 because Sun is ignoring PSARC discussions
Joerg Schilling wrote:
Kyle McDonald [EMAIL PROTECTED] wrote:
Could you please explain why some people including you try to convert
a general problem (that I mentioned some time ago) into a personal problem?
I'm not making it personal. I don't see how you read that into what I
wrote. I was just applying what I understand (now) the process to be to
the example someone else asked about.
Then I must have missunderstood you - sorry.
It seems that this is just to pretend it is less important than it really
is.
The general problem is that conflicting names cannot be in /usr/bin in
order
to avoid problems that cannot be solved by changing PATH. Please do not try
to
divert from this general problem.
I'm with you there. I don't remember the ARC case # (I think it was the
creation of /usr/gnu), but I actually argued the same thing on the
conference call. I think the only difference is that When I hung up from
the conf. call, I understood that while my argument was heard and
understood, it wasn't deemed to be enough to change things, and I knew
they decided to go ahead anyway. Ao I wasn't surprised when the gnu
binaries appeared in /usr/bin.
Well, then we seem to have very similar ideas.
A big question still remains: what is GNU software and should non-gnu
software go to /usr/gnu?
That (If I recall correctly) was one of the questions raised on the
conference call and email thread. I was never clear why that was a good
reason not to do it but it was a variable some didn't appear to like.
Personally I'd only put in the FSF stuff - but that left another
questions, that I think some didn't want hanging out there, to answer:
Where does the other stuff go? How big does a collection have to be to
get it's own /usr/gnu equivalent? is there a /usr/misc that collects all
the things that don't qualify? Should all these collections be collected
in another directory (/usr/some/path/{gnu,schilly,misc,...})? Should the
gnu equivalents of things already in /usr/bin, /usr/ucb, /usr/xpg*, be
left in /usr/gnu since they could be considered 'UNIX types', but things
not traditionally in UNIX (gcc, ghostscript, xemacs, etc.) put in
/usr/some/path/somename?
I don't know the answers to all therse questions. I beleive they are
answerable, but I know Sun had a timetable, and probably didn't want to
hold up that one ARC case to hashing out this bigger problem.
Looking at it now, the answers to those questions probably seemed to
lead right back to something too close to /usr/sfw... I know there are
opinions out there that /usr/sfw was a mistake. I'm not totally clear on
what they didn't like about it technically, but I think I might try to
look it up if I get the chance.
The important conclusion from the current name clash problem should be:
- Only a small selected number of binaries are allowed to live (also) in
/usr/gnu. This would include gtar, cc and gcc but it may be that we even
need to discuss whether tar, pax and similar should be there.
I think the /usr/gnu case decided only things that were GNU (FSF I
bleieve) that *conflicted* with things already in /usr/bin were to be
put in /usr/gnu. This means that you might find GNU tar under the name
tar in /usr/gnu, and again under the name gtar in /usr/bin, but you
wouldn't find gtar in /usr/gnu. GCC would be found in /usr/bin I assume
ince I know of no conflict.
- As long as even in a multi-user environment users cannot customize
their
private view to /usr/bin, /usr/bin needs to be treated very carefully.
The idea was to leave /usr/bin as the default catchall. And allow people
to stick things in front of it in their PATH to bring conflicting thins
from GNU, UCB, XPG etc. to the front for themselves, and let the PATH
'fall through' to pick up everything else by default.
- Instead of putting everything into /usr/bin, it is better to have a
longer PATH by default that defines the default behavior of the
installation (e.g. from /etc/default/login)
There are hard and fast rules inside of Sun, from experiences with
customers (from what I remember) complaining when the default PATH had
been changed in the past. No one was willing to discuss changing the
default PATH in /etc/default/login.
- It may be even wise to create something like /usr/sun/bin or
/usr/sol/bin
to really allow to customize the userland behavior of OpenSolaris.
I think that might also be a good idea. If /usr/bin is to be a catchall,
then like UCB, and XPG, I think breaking out the SVR4 variants of the
'basic UNIX' commands (getting everyone to agree on a definition of that
list might be tough) might be useful too. Even if it's only to Put all
'environment flavors' on equal footing. But I think that would involve
touching the default PATH, and that was described as a 'non-starter'.
- The current state
Re: [osol-discuss] Nameclash on svn_77 because Sun is ignoring PSARC discussions
James Carlson wrote: Kyle McDonald writes: I don't know the answers to all therse questions. I beleive they are answerable, but I know Sun had a timetable, and probably didn't want to hold up that one ARC case to hashing out this bigger problem. Untrue. We held that exact discussion. It was discussed, but I got the (perhaps wrong?) impression that final path chosen dended up not needing answers to those questions, and so I was never sure how set in stone the possible answers to those questions really were at the end of that discussion. I thought one of the reasons for going the route chosen was that it avoided many if not all of those quesitons. I think the /usr/gnu case decided only things that were GNU (FSF I bleieve) that *conflicted* with things already in /usr/bin were to be put in /usr/gnu. This means that you might find GNU tar under the name tar in /usr/gnu, and again under the name gtar in /usr/bin, but you wouldn't find gtar in /usr/gnu. Correct. GCC would be found in /usr/bin I assume ince I know of no conflict. It'd be reasonable to have GCC as /usr/gnu/bin/cc, if someone wanted it. True if it is called 'cc'. I was thinking of a binary called 'gcc' and trying to use that as an example to show Joerg what i was talking about. There are hard and fast rules inside of Sun, from experiences with customers (from what I remember) complaining when the default PATH had been changed in the past. No one was willing to discuss changing the default PATH in /etc/default/login. This ground, as well as the long term effects of putting random open source stuff in /usr/bin, has been trampled extensively. I'm somewhat sympathetic to the complaints that we're treating /usr/bin as a dumping ground. I _wasn't_ in favor of the plan. To a large extent, it's driven by earlier decisions -- most notably the decision to use GNOME as a desktop. However, it's long since been decided, and the discussion issues that you've raised here -- repeatedly -- are really pointless. They don't result in any useful changes or shine any light on the problem. Aggreed. Case closed. I wasn't looking to discuss them again. Just pointing them out to Joerg in case it wasn't clear. I thought maybe my interpretation could clear it up. If you're really interested in changing this, rather than just contributing to the debating society, then I urge you to put together a project proposal. Propose something concrete that will alter or abolish these decisions, and put something more to your liking in place: PSARC 1999/555 Getting with the Freeware Program PSARC 2005/185 Enabling serendipitous discovery PSARC 2007/047 /usr/gnu I might. If I had what I beleived were good answers to all the other questions I listed above. I think good answers exist, but I haven't found them yet. That's exactly what I was trying to say. I haven't avoided dicussing it since I'm hoping that good ideas might come to someone else on these lists even though I haven't found them myself. Otherwise, given the previous clear decisions, our choices on these new cases become quite clear. You might not like ImageMagick in /usr/bin, but given our current direction, it's an entirely proper and consistent decision. Aggreed. I'm not trying to say anything otherwise. In fact I thought I said that to Joerg. I was trying to say that while he and I may have some visions of how it would be 'ideally' that are nearly parallel, our take on how it is is totally opposite. I feel that liek you have said when it came down to the case of 'compare' wether you look at the 'First to Integrate' rule, or the 'more popular, more useful' rule, Imagemagik wins. I'd take ImageMagik in a heartbeat over his compare. For what it's worth, I've made my peace with those decisions. There are aspects I don't like, but there's more that I *do* like, so even if someone complains that having everything easily accessible is too much like Linux, I'm not picking up that fight. I don't like them either, but for the time being I'm made my peace too, and I'm learning to live with it until I come up with something else that I feel is worth proposing. The 'Been there. Discussed that. Don't want to revisit it.' attitude makes it hard for people like me to even consider proposeing something unless we feel it will address (nearly?) every concern everyone who will need to approve it will have. And coming up with that checklist to verify against before proposing it is tough. Though I'm sure the case materials contain a good start. There's just this aurora of we don't want to waste time on this again no matter how good an idea you have about this subject. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nameclash on svn_77 because Sun is ignoring PSARC discussions
James Carlson wrote: UNIX admin writes: If you want to rename compare you will need to take this up with the ImageMagick folks. That is not the approach that was taken when GNU tar was integrated as `gtar`, was it? No, because 'gtar' is a well-known disambiguator (even the GNU tar sources search for tar as 'gnutar' and 'gtar') that predates our use, and because we have /usr/gnu/bin for those few who really want tar to live with GNU horns. Not to mention that when Gnu tar was integrated, Solaris already had a 'tar' in /usr/bin. When 'compare' was integrated (by the first one to request it,) Solaris had nothing in /usr/bin/ named 'compare'. -Kyle There's no such variation of the ImageMagick components that will work or that will be compatible with other platforms. And whoever integrated it didn't get the developers/maintainers of GNU tar to rename him (the GNU tape archiver), did they? That's true; that wasn't done because there already was a well-known solution so no special concerns were raised. I don't see why we should rename something because of a conflict with something we do not ship. You probably (I hope) didn't mean this the way you wrote it, because it comes off as: if we don't ship it, it doesn't exist and, just because (Open)Solaris isn't shipping something today, that does not mean it won't be shipping that something tomorrow, which is why I believe you probably didn't mean it that way; the way you put it is unfortunate. To an approximation, if it's not something that has been ARC reviewed and integrated, then it's not a conflict. We can't solve all the world's conflicts; we have to worry about ours. Obviously, if someone wanted to ship his own version of some well- known program that we don't currently ship, or otherwise pick a famous name, we'd likely have some sharp questions to ask, but in terms of having a conflict requiring that utility to be placed in /usr/gnu/bin (or some such), I think we'd be in less obvious territory. In this case, though, LSARC discussed something that was already reviewed and already integrated into the /usr/sfw/bin ghetto, something that is commonly known and used on many other platforms, and the project team wanted to move it over to /usr/bin. Per the rules we came up with in PSARC 2005/185 (Enabling serendipitous discovery) and 2007/047 (/usr/gnu), they were doing something that was fairly obvious and good, and the LSARC members agreed with them. I happen to agree with LSARC. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nameclash on svn_77 because Sun is ignoring PSARC discussions
Joerg Schilling wrote: Kyle McDonald [EMAIL PROTECTED] wrote: Not to mention that when Gnu tar was integrated, Solaris already had a 'tar' in /usr/bin. When 'compare' was integrated (by the first one to request it,) Solaris had nothing in /usr/bin/ named 'compare'. Could you please explain why some people including you try to convert a general problem (that I mentioned some time ago) into a personal problem? I'm not making it personal. I don't see how you read that into what I wrote. I was just applying what I understand (now) the process to be to the example someone else asked about. It seems that this is just to pretend it is less important than it really is. The general problem is that conflicting names cannot be in /usr/bin in order to avoid problems that cannot be solved by changing PATH. Please do not try to divert from this general problem. I'm with you there. I don't remember the ARC case # (I think it was the creation of /usr/gnu), but I actually argued the same thing on the conference call. I think the only difference is that When I hung up from the conf. call, I understood that while my argument was heard and understood, it wasn't deemed to be enough to change things, and I knew they decided to go ahead anyway. Ao I wasn't surprised when the gnu binaries appeared in /usr/bin. I pushed for all gnu software to be installed in /usr/gnu, with an second (optional - but installed by default) package of soft links from /usr/gnu/to /usr/bin for the programs everyone wanted to put in /usr/bin. That way if I elected, I could use PATH for my users to allow them total flexibility, without changing the default for other installations who just expect everything to be there. I suppose a /usr/some/path/imagemagik/ could have been created where all the binaries are installed, and a imagmagik links pkg (again installed by default) could have been added also to make them appear in /usr/bin, but leave the admin installing the machine the option to remove them. I would think even that might have been good enough for you: a /usr/some/path/schilly/... instalation location for your stuff, with a second 'links' pkg (not installed by default, I would assume given Sun's view that Imagemagik.is more widely used.) but available for those who wanted to put your programs in /usr/bin. I imagine that Sun either didn't want to start a precendent for this, nor have to set criteria for what can and can't be have it's own /usr/some/path/SomeCollection directory. Still in my mind it's the only method that retains flexibility and scales(mostly.) This allows the admin to customize the machine defaults, without denying the users the ability to override the admins choices. And it still lets Sun keep it's 'serendipitous discovery' (is the right name?) policy alive. Seemed like it should have been win win, and covered all the requirements for everyone at the time, and I never felt that I heard a good reason not to do it. The focus of my argument was that I maintain a network of machines, where I need to build and install GNU and other tools myself, for various reasons the ones included in Solaris will never be good enough. I keep these apps on an NFS share, and therefore I don't want to put them in front of /usr/bin in PATH, but with these GNU (and other tools) integrated into /usr/bin, I'm forced to either prepend them to the PATH, or not install the corresponding Solaris packages. So far I've elected to not install the packages whenever possible, and that has worked for me so far. However I see the day coming when (because it's in Solaris now,) someone codes some other part of Solaris to depend on these programs, and not installing these packages won't be an option. I suppose I'll revisit the argument then. -Kyle Jörg ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nameclash on svn_77 because Sun is ignoring PSARC discussions
Joerg Schilling wrote: [EMAIL PROTECTED] wrote: PSARC discussions happen ONLY in the context of the product/release under for which the product is ARC'ed. Your compare is NOT part of that product; nor is there even an ARC case proposing it. Your compare does not exist in the context of the product Solaris. It is therefor *completely* irrelevant to a PSARC discussion. Collaboration happens in the community. If you are a member of the OpenSolaris community, you should try to collaborate. This is a case to see whether there is collaboration or domination! But Solaris != OpenSolaris. Right? Or am I missing something. Just because something is one way in Solaris doesn't mean it has to be that way in (any particular distribution of) OpenSolaris. Solaris is one distribution. It's Sun's Distribution. I don't think it's correct to call them applying their rules (rules which it sounds like have been used since Solaris was started) to how they manage it. The community will have it's say in the other distributions that are created from OpenSolaris. If one or more of those distributions wants to do what you're suggesting, then it can. And (while I haven't read the gonverning documents, I'm pretty sure) Sun can't do anything to stop that. I'm not surprised there are disagreements like this appearing in this community. It has to be expected that this many people are not going to agree on everything. I think that's why it was smart to plan for multiple distributions. It leaves rooms for groups of like minded people to do things differently. I think we have to expect more things like this in the future. And if Sun does what it thinks needs to be done in Solaris, I don't see it as being heavy handed.They're just one sub-community (with their own way of working out these disagreements internally to their group) within the larger community. -Kyle -Kyle Jörg ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Equivalent of OBP 'probe-scsi-all' from inside
Chandan Maddanna wrote: Dear Kyle, The number of cable connected has nothing to do with the controllers that is visible. Not really. It's my understanding that each port a cable could connect to is seen as a seperate controller. Also Controllers with no devices attached are not visible (in /dev/dsk/c*t*d*, etc.) Even if you are connected through just one cable, the number of controllers visible will be the same. When I say 'controllers' I'm talking about FC interface cards in the Server. Maybe I'm using the wrong term? What do you mean by controller? But it seems like what you are asking for is lun masking. That is seeing just some luns and not seeing some. No. I want to know what luns or devices are reachable on the other end of the cable I've plugged into the board in the server. So if this is what you want to do, than in normal entry level storage arrays we will have to implement it on the client side ( solaris box connected to the array ). This isn't connected to an entry level box. The box on the other end is an EMC Symetrix Array. Hope this helps. It's a start. More info; I started with 2 pairs of servers. Each pair of servers had 4 links (2 for each server in the pair) to the same pool of disks (or luns.) So each server in the pair had redundant links to it's set of disks which it shared with the other server in the pair. I want to reduce this to only 1 server (for now,) and give it the right combination of cables from these 2 pairs of servers, so that it will be able to see all the disks from both pools. So I want to plug in each of the 8 cables, and try to determine which of the disks are visible on the other end. If this was scsi, and sparc, I'd use 'probe-scsi-all' from OBP, to see which disks show up on which cables/ports/controllers. What can I use for FC? I discovered 'cfgadm'. And I manged to get it to list the 4 controllers, and 1 disk on each. However the ID of that one disk doesn't look anything like the WWN of the targets I see in /dev/dsk. On top of that why is there is only one disk? I see 18 targets in /dev/dsk, shouldn't I see 18 disks listed mong the 4 controllers? -Kyle -- Chandan Maddanna This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Does Solaris has similar Linux command mount -o
[EMAIL PROTECTED] wrote:
#!/usr/bin/bash
mkdir $2
lofiadm -a $1 /dev/lofi/1
mount -F hsfs -o ro /dev/lofi/1 $2 echo -e \n\t I have mounted $1 under the
folder $2\n\n
You should realize that lofiadm actually outputs the device used, so
the script can be written so as not to require only /dev/lofi/1
I've attached my scripts which I use for mounting/unmounting lofi volumes.
It detects pcfs, ufs and hsfs filesystem and mounts them; it remembers
the mount and a single lofiumount without arguments will unmount all
you mounted.
I've written these a long time ago, shortly after lofiadm was added,
I think.
Usage is simple:
lofimount file.iso /mnt
lofiumount /mnt
lofimount file.ufs /mnt
etc.
That's cool Casper.
I know it needs polishing, but I've attached a script I wrote and placed
in /usr/lib/fs/lofi/mount, so that I could put entries like this in
/etc/vfstab:
/export/Solaris/ISOs/sol-nv-b74-x86-dvd.iso - /export/Solaris/sNV/b74_x
lofi - yes fstype=hsfs
Maybe I can extend it to detect the fstype automatically from your script.
-Kyle
#/bin/ksh
#
#
if [ $1 = -o ]; then
OPTS=$2
shift 2
fi
FILE=$1
MTPT=$2
if [ ${OPTS} != ]; then
SAVE_IFS=${IFS}
IFS=,
set - ${OPTS}
IFS=${SAVE_IFS}
OPTS=
while [ ${1}x != x ]; do
case $1 in
fstype=* )
# Use fancy shell pattern/regexp assignment operation.
TYPE=`echo $1 | sed s/fstype=//`;;
* )
# use new fancy assignment shell operation.
if [ ${OPTS} = ]; then
OPTS=-o $1
else
OPTS=${OPTS},$1
fi;;
esac
shift
done
fi
LOFI=
LOOP=0
if [ -r ${FILE} ]; then
while [ ${LOFI} = -a ${LOOP} -lt 10 ]; do
LOFI=`lofiadm ${FILE} 2/dev/null`
# LOFI=`lofiadm ${FILE}`
if [ ${LOFI} = ]; then
LOFI=`lofiadm -a ${FILE} 2/dev/null`
# LOFI=`lofiadm -a ${FILE}`
fi
if [ ${LOFI} = ]; then
LOOP=`echo ${LOOP} + 1 | bc`
echo Looping(${LOOP}) 12
sleep 1
fi
done
else
echo mount: open: ${FILE}: No such file or directory
fi
#echo FILE:${FILE} 12
#echo MTPT:${MTPT} 12
#echo TYPE:${TYPE} 12
#echo OPTS:${OPTS} 12
#echo LOFI:${LOFI} 12
if [ ${LOFI} = ]; then
echo Aborting! 12
exit 1
fi
echo mount -F ${TYPE} ${OPTS} ${LOFI} ${MTPT} 12
mount -F ${TYPE} ${OPTS} ${LOFI} ${MTPT}
exit $?
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
[osol-discuss] Equivalent of OBP 'probe-scsi-all' from inside solaris on x86?
Hi all, I have a server with 2 FCAL cards. Each card has 2 ports. There are 4 cables running into these 4 ports. There are 4 other cables that are currently unused. I know there's supposed to be some redundancy in how the SAN is setup,but it's out of my control, and I the person to ask isn't around right now. It's my understanding that 4 of the cables should see one set of disks, and 4 should see another set. I'd like to get 2 cables from each of the 2 sets and leave 2 cables in each set for a later date. So I'm trying to figure out which disks are seen via which cables? So far Solaris only sees 1 controller 'c0', and see's 18 disks, pretty much no matter which 4 cables I plug in. Is there an easier way to do this? If not something like 'probe-scsi-all', is there something like 'snoop' for FCAL? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How to enable XDM?
Tom Chen wrote: XDM is the facility that allows a remote client to access a full desktop on a Unix or Linux server which is very useful for me to admin remote servers. The protocol it uses is called XDMCP. However, XDM is not enabled by default in OpenSolaris. I know you can disable Solaris's DtLogin with: svcadm disable cde-login But I'm not aware of an existing service you can enable that will start XDM. If you wanted that you'd have to write your own service or script to start it up. I beleive XDM is included in X11 in Solaris though so you could do that. That said, doing what you want is even easier that enabling XDM, since Solaris's DtLogin already fully supports XDMCP. (and has for years.) I believe you only have to create the /etc/dt/config directory, and then copy /usr/dt/config/Xservers over to /etc/dt/config and edit it to allow your remote xserver to get a login screen from DtLogin. I don't beleive that the syntax for the Xservers file is all that different from the XDM config file, but the manpages should clarify any differences. Also you may need to copy and edit other files from /usr/dt/config (Xaccess maybe?) -Kyle I am using Nevada V76, I am wondering how to enable XDM? Tom This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Live Upgrade question?
I started with b74, then created an alt BE and lu'd it to b77. b77 had problems with the FC disks attached, and never booted sucessfully. Should I wipe that, clone b74 again and then upgrade to b78 over that? Or can I upgrade the b77 BE directly to b78? (on another note, anyone know for sure if any changes that went into b78 my affect (and help?) the FCAL problem?) -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Indiana review
UNIX admin wrote: This is debatable ... Can you provide pros and cons for this from your point of view? For example, I have a package that delivers /.cshrc, /.login and /.logout. If you prefer /bin/sh for root's shell, then why on earth are you installing CSH login files of all things? (Friends don't let friends use CSH! ;) ) Determining root's home directory via public interfaces is unreliable, namely because such public interfaces aren't well defined. I could look directly into /etc/passwd, but as Indiana clearly shows now, there is no guarantee whatsoever, that home directory field will be at a fixed position. I could also use `finger`, but there's no guarantee that the output won't change, thereby breaking my regex parser for it. For crying out loud, they broke the output of `uname -a`. I'm not sure, but I think getent is a stable interface. The promise of SunOS is that it would remain backward and forward compatible; that is why environments that need to be super-stable and super-reliable prefer it over any other operating system. Solars (from Sun) I beleive will always have that stability. I haven't been around here long enough to know for sure, but I'm not positive that OpenSolaris won't be more aof a playground to try new things in. That said, I too don't like the trend of doing things in any Solaris 'because that's what people coming from linux will expect'. If and when linux does something for a reason the community thinks is worthwhile, then I'm all for reviewing it and considering it. I'm not for blindly copying though. I think it should be given the engineering consideration that I feel Solaris is well known for. In the case of root's home, this might mean (note: I haven't give this much thought, it's just an example:) that if moving root's home was a good idea, we may want to default it to /export/home/root, and ship an /etc/auto_home that will lofs mount it from there to /home/root automatically. For BASH, while I use BASH personally, I am very surprised that anyone would change root's shell to it. I know it's very backwards compatible, but I've always steered clear of that because I don't knwo what assumptionsmight be made in the OS, or any other 3rd party software, and I don't want to get bit. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Indiana review
UNIX admin wrote: Funny, one of the first things I always do after installing an instance of SXCE is to edit the passwd file, change the home root directory to /root and the default shell to /bin/bash. I know think I am not alone. That's most likely because you haven't typed in `man tcsh` yet. Have you read the manual page for `tcsh`? I'd think after that, you'd never get the idea to do /bin/bash anything ever again. I'm no religious zealot, but I don't get that. You flame bash for not being bourne shell compatible enough, but then go and suggest tcsh? Whe I was a brand new unix user in college, it confused me for a short while why, everything in my environment was scripted or setup different from root, and most system scripts. I quickly figured out that there was choice in which shell you wanted to use. This was SunOS4, I don't remember if ksh existed back then, but I didn't know it if it did. I liked the features tcsh added over csh, but when I found bash and got all those features, and a syntax that was compatible with root's shell, and the system's scripts, I ditched all forms of csh forever, and promptly forgot it's script syntax too. There's too much to be done, to write things in two different languages, when one will suffice. Computer industry is very specific in one regard: we have to read. Constantly. A lot. A whole lot. And then some more. Agreed. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Indiana review
UNIX admin wrote: I'm no religious zealot, but I don't get that. You flame bash for not being bourne shell compatible enough, but then go and suggest tcsh? So let me explain: for system and package scripts, /sbin/sh. For interactive use, either tcsh or zsh. Still confused? A true sysadmin will have tried it all, i.e. distrust all claims for one true way. Will have burned himself, will have learned from that experience. Agreed. And each will end up with a different solution. I've been burned by bash - well by it not always being available - By then I knew of ksh. And I'll be honest, I was plesantly surprised how complete KSH was in terms of what I used everyday interactively. When admin I interactively, I almost always end up writing short (one-off) scripts on the command line. I couldn't live with the command line using a different scripting syntax than the script files I wrote. Hey, but that's just me! Thanks for your explanation of where you use the different shells. That helps. I'm still curious what about the csh interface you prefer for interactive use? And I'm not saying you shouldn't prefer it etiher, I'm just wondering what I'm missing? -Kyle This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] 'more' broken in b77 miniroot?
Hi all, I've been trying to figure out what changes i need to make to my begin script, and/or the miniroot, so I booted into it and I've been looking around. While trying to look at files in it, I've seen very strange behavior from 'more'. First I noticed that: # more /etc/passwd /etc/shadow Only shows me the contents of '/etc/passwd' and never '/etc/shadow'. Next found that: # more /sbin/install-discovery Only shows me the first page of the file before quiting. I made sure $TERM was set. but that didn't help realy (made the output a little longer, but still not the whole file.) Is this the way it's supposed to work? Is this due to things that are missing from the miniroot? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 'more' broken in b77 miniroot?
[EMAIL PROTECTED] wrote: Is this the way it's supposed to work? Is this due to things that are missing from the miniroot? No, more is just broken. I think it expects to be able to read from stderr (for obvious reasons :-) and exits when it cannot. Just curious, can it normally read from stderr? If so what's different about the miniroot that keeps it from reading from stderr? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 'more' broken in b77 miniroot?
[EMAIL PROTECTED] wrote: This has been discussed on the POSIX mailing list a while ago. stderr is expected to be readable in the default case where stderr is connected to the controlling tty. Where does it say so in the standard? The miniroot is *NOT* a POSIX compliant environment nor does it play one on TV, so the point is moot anyway. That is true. But the installer allows you to exit to a single-user shell to perform administration tasks. Most users I know would expect things like 'more' to work in this environment. Does anyone know of a reason, or need, for stderr to be readonly? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 'more' broken in b77 miniroot?
James Carlson wrote: Jürgen Keil writes: In snv_75a, the miniroot /sbin/sulogin shell script contains this line: exec 0 /dev/console 10 20 The miniroot /sbin/sulogin from snv_75a has SCCS ID @(#)sulogin.sh 1.5. Has that changed for snv_77? It's still the same in the gate. This might be the difference. I didn't choose 'Single User Shell' from the menu. The machine is configured to do Custom Jumpstart automatically, and to see the environment the Begin script would run in, I temporarily changed the begin script to just call 'exit 1'. This made JumpStart give up and leave me a shell prompt. Is this prompt JumpStart left me at supposed to be the same as 'sulogin'? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 'more' broken in b77 miniroot?
Juergen Keil wrote: Date: Wed, 28 Nov 2007 13:27:38 -0500 From: Kyle McDonald [EMAIL PROTECTED] To: James Carlson [EMAIL PROTECTED] CC: Jürgen Keil [EMAIL PROTECTED], opensolaris-discuss@opensolaris.org Subject: Re: [osol-discuss] 'more' broken in b77 miniroot? James Carlson wrote: Jürgen Keil writes: In snv_75a, the miniroot /sbin/sulogin shell script contains this line: exec 0 /dev/console 10 20 The miniroot /sbin/sulogin from snv_75a has SCCS ID @(#)sulogin.sh 1.5. Has that changed for snv_77? It's still the same in the gate. This might be the difference. I didn't choose 'Single User Shell' from the menu. The machine is configured to do Custom Jumpstart automatically, and to see the environment the Begin script would run in, I temporarily changed the begin script to just call 'exit 1'. This made JumpStart give up and leave me a shell prompt. Is this prompt JumpStart left me at supposed to be the same as 'sulogin'? Maybe not. Can you try ls -lR / | truss more ? What kind of error does it get (when it tries to read from stderr fd#2) ? Looks like EBADF: # ls -lR / | truss more execve(/usr/bin/more, 0x08047D20, 0x08047D28) argc = 1 resolvepath(/usr/lib/ld.so.1, /lib/ld.so.1, 1023) = 12 resolvepath(/usr/bin/more, /usr/bin/more, 1023) = 13 xstat(2, /usr/bin/more, 0x080479C8) = 0 open(/var/ld/ld.config, O_RDONLY) Err#2 ENOENT sysconfig(_CONFIG_PAGESIZE) = 4096 xstat(2, /lib/libcurses.so.1, 0x08047188) = 0 resolvepath(/lib/libcurses.so.1, /lib/libcurses.so.1, 1023) = 19 open(/lib/libcurses.so.1, O_RDONLY) = 3 mmap(0x0001, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_ALIGN, 3, 0) = 0xCEBB mmap(0x0001, 266240, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xCEB6 mmap(0xCEB6, 163034, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_TEXT, 3, 0) = 0xCEB6 mmap(0xCEB98000, 25815, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_INITDATA, 3, 163840) = 0xCEB98000 mmap(0xCEB9F000, 7832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0xCEB9F000 munmap(0xCEB88000, 65536) = 0 mmap(0x, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xCEB5 memcntl(0xCEB6, 54096, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 close(3)= 0 xstat(2, /lib/libc.so.1, 0x08047188) = 0 resolvepath(/lib/libc.so.1, /lib/libc.so.1, 1023) = 14 open(/lib/libc.so.1, O_RDONLY)= 3 mmap(0xCEBB, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xCEBB mmap(0x0001, 1372160, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xCE9F mmap(0xCE9F, 1263015, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_TEXT, 3, 0) = 0xCE9F mmap(0xCEB35000, 31022, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_INITDATA, 3, 1265664) = 0xCEB35000 mmap(0xCEB3D000, 5208, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0xCEB3D000 munmap(0xCEB25000, 65536) = 0 memcntl(0xCE9F, 205492, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 close(3)= 0 mmap(0x0001, 24576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xCE9E munmap(0xCEBB, 32768) = 0 getcontext(0x08047780) getrlimit(RLIMIT_STACK, 0x08047778) = 0 getpid()= 482 [480] lwp_private(0, 1, 0xCE9E2A00) = 0x01C3 setustack(0xCE9E2A60) sysi86(SI86FPSTART, 0xCEB3DA78, 0x133F, 0x1F80) = 0x0001 brk(0x08067468) = 0 brk(0x08069468) = 0 ioctl(1, TCGETA, 0x08047BCC)= 0 fstat64(1, 0x08047B30) = 0 ioctl(1, TCGETA, 0x080669C6)= 0 open(/usr/share/lib/terminfo//u/unknown, O_RDONLY) = 3 read(3, 1A01\b\0 %\0 !\08A0110\0.., 4096) = 928 close(3)= 0 ioctl(1, TCGETA, 0x080469AC)= 0 ioctl(1, TCGETS, 0xCEBA07DC)= 0 ioctl(1, TIOCGWINSZ, 0x08047C0C)= 0 ioctl(1, TCSETSW, 0xCEBA0800) = 0 ioctl(1, TCSETSW, 0xCEBA07DC) = 0 ioctl(0, TCGETA, 0x080669C6)Err#22 EINVAL ioctl(2, TCGETA, 0x080669C6)= 0 schedctl() = 0xCEBBE000 sigaction(SIGQUIT, 0x08047BA0, 0x08047C20) = 0 sigaction(SIGINT, 0x08047BA0, 0x08047C20) = 0 sigaction(SIGWINCH, 0x08047BA0, 0x08047C20) = 0 sigaction(SIGTSTP, 0x08047BA0, 0x08047C20) = 0 sigaction(SIGTSTP, 0x08047BA0, 0x08047C20) = 0 ioctl(2, TCGETA, 0x080669C6)= 0 ioctl(2, TCGETA, 0x080669B4)= 0 ioctl(2, TCSETAF, 0x080669B4) = 0 ioctl(0, TCGETA, 0x08047B3C
