[osol-discuss] Re: Re: [EMAIL PROTECTED] project proposal __/__ WAS: Re: Re: Re:
The kqemu module itself is IP of Fabrice Bellard. Not sure if I can integrate it into the pkgs, probably NOT. Thanks for the clarification. I understand the IP situation and won't have any problem downloading kqemu as a separate package. The wrapper module will continue to be available on http://opensolaris.org/os/project/qemu/downloads/ The part that I am having problems with regards libSDL. Is it still true that it must be compiled under gcc 3.x? If so, is there a more detailed HOWTO (i.e., starting from pkg-get gcc, etc., etc.)? Thanks again. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Shipping lsof with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up
Peter Tribble wrote: On 1/1/07, wb [EMAIL PROTECTED] wrote: I have a /tmp FS for swap, and a really big file crout* inside. The /tmp was 95% up. I decided to remove the crout file. The problem, is the /tmp is not decreasing, but still growing. How could I make it decrease? Find and kill the process that's writing to that file. Somehow I am wondering why Solaris doesn't ship lsof in /usr/sbin/ ... is this just noone had time yet or something else ? No; it's something that we won't ship, ever because of the nature how lsof trawls for its events. While we've hardened the system against panics induced by lsof and other kernel browsers, a piece of code which reads data structures without respect for locking and follows pointers which may no longer be there can report bogus data as well as reveal information that should not be reported. That's why we've elected, in the past, to mimic some of lsof's functionality in other tools, notably pfiles. I understand some of the information is still wanting so perhaps we should improve there. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Problem using acctcom...
when i try using acctcom in my solaris 10 machine, it gives out the foll error essage : acctcom: cannot open /var/adm/pacct Am kind of new to the environment so am not able to trace out the problem... Can anyone help me out with this??? thanks and Regards, Arun DK This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] libc_pic.a not found
Hi, While building the dynamic linker using dmake all, the build process failed because of libc_pic.a library not found in /usr/lib/pics. Build the full workspace, then build the dynamic linker updates. There are some parts in the ON workspace which depend on other bits being build first. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Shipping lsof with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up
Roland Mainz [EMAIL PROTECTED] wrote: Somehow I am wondering why Solaris doesn't ship lsof in /usr/sbin/ ... is this just noone had time yet or something else ? Wasn't there a blog where someone explained why lsof is a perfornance pig and should be avoided in favor of other tools? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Obtaining nameservice-independent user_attrand publickey data from a shell script ?
Peter C. Norton wrote: On Fri, Jan 05, 2007 at 02:59:55AM +0100, Martin Bochnig wrote: So how would you be able to bypass any nameservice defined in nsswitch.conf, getting those user_attr attributes in a nameservice-independent way? I mean, either you get it locally (files), or you may get it via one of the nameservices (its commands). What do you mean? Do you intend to intrude somewhere ;-) How does nisinit get names from dns even if your system is set to resolve via NIS+? -Peter Is this a nameservice-independent way?? -- No, as far as I would define it. It just uses a specific NS's (here NIS+'s) cmd, just as I suggested earlier in the discussion. Okay, true: That command is not directly associated to whatever nameservice(s) determined by processing the lookup order defined in nsswitch.conf. Yes, maybe this is what Roland means?? Makes sense. But if so, then it was not a nameservice-independent way, but instead rather a way independant from whatever nameservice(s) are currently to be used Further: NIS+ server needs to be set-up, configured and running for /usr/sbin/nisinit to return any configuration details. It clearly is not a nameservice-independent way because of that. Further__#2: You need to have root (or equivalent role's) permissions to run it, which contradicts what Roland has stated he was looking for: $ /usr/sbin/nisinit This program must be run as superuser. $ I'm still in the dark. -Martin ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Obtaining nameservice-independent user_attrand publickey data from a shell script ?
Martin Bochnig wrote: Peter C. Norton wrote: On Fri, Jan 05, 2007 at 02:59:55AM +0100, Martin Bochnig wrote: So how would you be able to bypass any nameservice defined in nsswitch.conf, getting those user_attr attributes in a nameservice-independent way? I mean, either you get it locally (files), or you may get it via one of the nameservices (its commands). What do you mean? Do you intend to intrude somewhere ;-) How does nisinit get names from dns even if your system is set to resolve via NIS+? -Peter Maybe you mean, Roland would want to clone the methods in which /usr/sbin/nisinit accesses those data? But we are talking about C-functions then, not a pure shell script. Anyways ... -Martin ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Obtaining nameservice-independent user_attr and publickey data from a shell script ?
Martin Bochnig wrote: Maybe getuserattr() or getauthattr() ? Plus getpublickey() Or don't those work with files as NS ?? /etc/publickey works just fine with files. -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Obtaining nameservice-independent user_attr and publickey data from a shell script ?
Roland Mainz wrote: Hi! Is there a nameservice-independent way to obtain the values for user_attr and publickey from a shell script (if not I would propose to add a extension to getent) ? publickey no there isn't. For user_attr it depends which values you want. user_attr is a little problematic because in some cases it isn't just user_attr you need to look at but you might then need to look at prof_attr, auth_attr and exec_attr as well as policy.conf. There are a couple of shell tools for some of the user_attr data. auths(1) will tell you all the authorisations a user has from user_attr, all included profiles and defaults from policy.conf. profiles(1) will tell you all the profiles a user has assigned to them from user_attr, and policy.conf and any profiles included in a profile. roles(1) will tell you the roles a user has - currently you can only assign a role directly in user_attr(4) but we want to change that so you can do it as part of a profile in prof_attr(4) as well. That still leaves: project, defaultpriv, limitpriv, lock_after_retries, idletime, idlecmd, labelview, clearance, min_label, type. For the user_attr(4) database what exactly is it you are trying to do from shell script ? I think having a getent for each of the nsswitch databases is a good idea but I want to be sure you are actually using the data in an appropriate way for user_attr(4). -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Shipping lsof with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up
Joerg Schilling wrote: Roland Mainz [EMAIL PROTECTED] wrote: Somehow I am wondering why Solaris doesn't ship lsof in /usr/sbin/ ... is this just noone had time yet or something else ? Wasn't there a blog where someone explained why lsof is a perfornance pig and should be avoided in favor of other tools? Jörg I don't know of a performance problem. What I had seen is, that you apparently have to rebuild it for Solaris10 06/06, versions built for older releases don't work correctly under 06/06 anymore. But that's certainly not a reason, why SUNW couldn't ship it. Martin ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Shipping lsof with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up
On Fri, 5 Jan 2007, Martin Bochnig wrote: [ ... ] What I had seen is, that you apparently have to rebuild it for Solaris10 06/06, versions built for older releases don't work correctly under 06/06 anymore. But that's certainly not a reason, why SUNW couldn't ship it. Well, so what exactly does lsof give that for example something like: #!/bin/sh cd /proc for i in *; do pfiles $i done doesn't do as well ? On the other hand, the request for lsof in Solaris is anything but new, and the reference to pfiles, the mentioning that lsof does nasty digging in the kernel's intestines as a reply is neither, and the arguments that the output format is different, the system load of pfiles is higher, lsof is common operator knowledge, ... - all that isn't new either ... See: 4286979 Solaris should include a utility like lsof lsof isn't perfect, and it doesn't claim to be. It's just neat and helpful. I think Sun has to overcome both not invented here and the instinctive reject via not perfect, therefore not 'good enough' no matter what the users say, before lsof goes into mainstream Solaris. Just my personal opinion there. FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Shipping lsof with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up
On Fri, Jan 05, 2007 at 11:59:27AM +, Frank Hofmann wrote: On the other hand, the request for lsof in Solaris is anything but new, and the reference to pfiles, the mentioning that lsof does nasty digging in the kernel's intestines as a reply is neither, and the arguments that the output format is different, the system load of pfiles is higher, lsof is common operator knowledge, ... - all that isn't new either ... Note that lsof doesn't have to do kmem craling. For example on Linux it only uses proper procfs interfaces. As such proper interfaces seem to exist on Solaris as well for use with pfiles it shouldn't be a problem for people knowledgeable in this area to adjust lsof to do the right thin on Solaris aswell. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Shipping lsof with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up
On Fri, 5 Jan 2007, Christoph Hellwig wrote: On Fri, Jan 05, 2007 at 11:59:27AM +, Frank Hofmann wrote: On the other hand, the request for lsof in Solaris is anything but new, and the reference to pfiles, the mentioning that lsof does nasty digging in the kernel's intestines as a reply is neither, and the arguments that the output format is different, the system load of pfiles is higher, lsof is common operator knowledge, ... - all that isn't new either ... Note that lsof doesn't have to do kmem craling. For example on Linux it only uses proper procfs interfaces. As such proper interfaces seem to exist on Solaris as well for use with pfiles it shouldn't be a problem for people knowledgeable in this area to adjust lsof to do the right thin on Solaris aswell. I know. That's all in the RFE I've referred to anyway. Just noone has done it yet. Maybe because Solaris developers know the Solaristics and don't miss lsof overly much. Again, personally, I can get what I want with pfiles and a bit of scripting; but thinking about e.g. having to write such a script portable between Solaris and Linux, admittedly, that'd be a pain, and that's where the usefulness of lsof comes in. FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: [EMAIL PROTECTED] project proposal __/__ WAS: Re: Re: Re:
W. Wayne Liauh wrote: The kqemu module itself is IP of Fabrice Bellard. Not sure if I can integrate it into the pkgs, probably NOT. Thanks for the clarification. I understand the IP situation and won't have any problem downloading kqemu as a separate package. The wrapper module will continue to be available on http://opensolaris.org/os/project/qemu/downloads/ The part that I am having problems with regards libSDL. Is it still true that it must be compiled under gcc 3.x? If so, is there a more detailed HOWTO (i.e., starting from pkg-get gcc, etc., etc.)? Thanks again. A prebuilt libSDL is - as always - embedded into SUNWqemu. SUNWqemu is though to be ready2run. Building it yourself: For general documentation you should go to http://www.qemu.com/user-doc.html gcc 3.4.x works best. gcc2.95 does not work properly anymore, gcc 4.x does not work yet (though there is a patch for Linux hosts that will probably also work on Solaris). ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: New SUNWqemu cvs20070102tue in the works .... rgds. -Martin
Martin Bochnig wrote: soon (Sorry for cross-posting, but too many people are waiting for one or another thing.) Merging several small and bigger diffs into the CVS was not so much of a problem. But they at qemu (i.e. Thiemo Seufer) have professionally reimplemented DMA support into hw/ide.c and hw/dma.c , rather than just using the working solution Juergen Keil has written. Using the default dma.c and ide.c breaks DMA support for Solaris guests once again. One gets the best results for Solaris-guest dma-support, when simpliy using the old Solaris-patched ide.c and dma.c from http://www.martux.org/qemu/RELEASES/sparc/qemu-0.8.2__default_FabriceB__versus__qemu-0.8.2-solaris__20061013fri__MB.gdiff or http://opensolaris.org/os/project/qemu/downloads/qemu-0.8.2-solaris_src_20061013fri.tar.bz2 However: cdrom support is currently completely broken for Win9x guests, no matter whether I use Oct14's patched ide.c/dma.c, unpatched cvs20070102tue ones, or patched cvs20070102tue ones with the old JuergenKeil-written code merged into as best as now possible. Unfortunately doesn't it core dump - it just doesn't work. Ben Taylor is also unimpressed by the current cvs. Problem: I cannot exclusively offer something that broken as SUNWqemu packages. I will therefore have to offer experimental cvs20070102tue packages for sparc and x86/x64 *plus* mature and 99% stable updated (i.e. Juergen Keil's Info patch, Sittichai's Tunnel patches etc. etc.) packages built from the old cvs20061014. Damn, next homework is due Wednesday and still no Xorg patch created. That homework is a biggie and I should already have started. Martin ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Current SUNWqemu status ... : qemu_cvs20070102tue__solaris__MB.gdiff.bz2
qemu_cvs20070102tue__solaris__MB.gdiff.bz2 Description: application/bzip ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Shipping lsof with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up
[EMAIL PROTECTED] writes: No; it's something that we won't ship, ever because of the nature how lsof trawls for its events. That's not true. Though there are folks around who have expressed the never opinion, that does not represent the opinion of all of Solaris development. Our group has discussed integrating lsof off and on many times. We *want* to have it in Solaris, but doing it *right* is substantially difficult. That's why we've elected, in the past, to mimic some of lsof's functionality in other tools, notably pfiles. I understand some of the information is still wanting so perhaps we should improve there. Having utilities with command line interfaces that work sort of like lsof but not quite would be foolish in my opinion. It represents a completely needless barrier to entry for folks new to Solaris, and the sorts of basic questions that lsof answers (who is writing to this file right now? and why is this port open?) are the ones that real administrators frequently need to answer. Pfiles, unfortunately, answers the wrong questions for those users (what things does this process have open?). The right answer, I think, is to introduce proper kernel interfaces that provide the basic information that lsof needs (where those interfaces might be missing), and then rewrite lsof so that it uses only proper interfaces rather than groveling about in internal data structures. Designing those new interfaces and figuring out how to rewrite lsof, though, is not a simple matter, and that's been part of the problem here. We're caught between the seductive simplicity of just integrating the already working lsof (which we can't really do) and rewriting it to conform to expected quality standards (which we don't have the time to do). +1 for a project to integrate the lsof command line interface. Design and implementation to be determined. ;-} -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Shipping lsof with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up
[EMAIL PROTECTED] writes: No; it's something that we won't ship, ever because of the nature how lsof trawls for its events. That's not true. +1 for a project to integrate the lsof command line interface. Design and implementation to be determined. ;-} Strange as it may seem, this is pretty much the same answer as I gave. (Never in its current form) Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [EMAIL PROTECTED] project proposal __/__ WAS: Re: Re: Re: Is M
Second, when we criticize Firefox, we should perhaps also mention the version number. The 1.5s are dogs. Firefox 2.0 is now included in 54+. If snv_54 is the one that integrated Vermillion, then that's the Firefox I've in the meantime learned to *love to hate*. It's a really crappy cobbled-together web browser, especially when compared to Mozilla. The fact that everything feels so cumbersome to a Mozilla user, and that, although the engine is the same, the UI is quite different don't help Firefox's case either. I guess backward compatibility wasn't a consideration. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: [EMAIL PROTECTED] project proposal __/__ WAS: Re: Re: Re: Is M
Later this year (Q2/Q3 2007) anyone (users of Solaris 10++ [sparc and x86/64]) will additionally have the alternative to use the then available MRTX packages, including MRTXseamonkey. Do you plan to deliver MRTXseamonkey in /opt/mrtx resp. /etc/opt/mrtx and /var/opt/mrtx (for config and data)? My biggest gripe with Blastwave is that they are not System V compliant. Dennis says this is because they wanted everything in one place. I fail to see how NFS-mounting /etc/opt/csw from another server would have been a problem, but OK. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: [EMAIL PROTECTED] project proposal __/__ WAS: Re: Re: Re: Is M
The MRTX pkgs will. However, marTux itself will be rpm based while offering pkgadd compatibility at the same time. I believe that your time reengineering / repackaging software in RPM would be better spent formally extending `pkgadd` and friends with features that `rpm` has and `pkgadd` tools don't. Otherwise, you run the risk of never being a suitable candidate for production environments, like banks, insurance companies, industrial corporations, the military, government, etcetera: you simply won't have enough compatibility with stock Solaris and will diverge too far from it. It's basically going down the same route Nexenta and BeleniX have taken. Are you sure that that's the future you want for your distribution? Okay, he is partially right: First you have more mount points when staying SVR4 compliant with config dirs here and there. Second, the nfs client may not have /etc/opt/csw or /etc/opt/mrtx yet, and you need to mkdir them before you can mount. No, you do not. That's solved via a foundation package. And in this foundation package, if you are careful and think things through, you could use the AutoMounter facility to do the NFS mounting for you, if need be. Ironically enough, Blastwave has such a thing, CSWcommon, but they haven't used it to solve that problem; they don't even *enforce* a standard set of permissions on the directory structure that CSWcommon delivers, or their packaging guidelines aren't stringent enough, because there were quite a few packages from Blastwave that wanted to change permissions. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: [EMAIL PROTECTED] project proposal __/__ WAS: Re: Re: Re: Is M
Huh ? Thats that the automounter is for! Exactly. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: [EMAIL PROTECTED] project proposal __/__ WAS: Re: Re: Re: Is M
UNIX admin wrote: Otherwise, you run the risk of never being a suitable candidate for production environments, like banks, insurance companies, industrial corporations, the military, government, etcetera: you simply won't have enough compatibility with stock Solaris and will diverge too far from it. Those high security institutions will never trust non-SUNW compiled code either way. It's basically going down the same route Nexenta and BeleniX have taken. Are you sure that that's the future you want for your distribution? ??? Nextenda and Belenix are two completely different things. Plus I don't see any of them going down. Nextenda uses .deb packaging. Belenix on the other hand does use pkgadd. No, you do not. That's solved via a foundation package. And in this foundation package, if you are careful and think things through, you could use the AutoMounter facility to do the NFS mounting for you, if need be. ok Ironically enough, Blastwave has such a thing, CSWcommon, I know. but they haven't used it to solve that problem; they don't even *enforce* a standard set of permissions on the directory structure that CSWcommon delivers, or their packaging guidelines aren't stringent enough, because there were quite a few packages from Blastwave that wanted to change permissions. I once posted something to the csw list. But didn't get too friednly, nor very much, responsed. I'm btw no longer on that list. Thanks for your input, UNIXadmin. I will need more of it! Regards, Martin ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] rpm vs pkgadd (again!)
UNIX admin wrote: The MRTX pkgs will. However, marTux itself will be rpm based while offering pkgadd compatibility at the same time. I believe that your time reengineering / repackaging software in RPM would be better spent formally extending `pkgadd` and friends with features that `rpm` has and `pkgadd` tools don't. exactly which needed features are those that rpm has that pkgadd does not ? -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: [EMAIL PROTECTED] project proposal __/__ WAS: Re: Re: Re: Is M
Martin Bochnig wrote: Darren J Moffat wrote: Martin Bochnig wrote: Okay, he is partially right: First you have more mount points when staying SVR4 compliant with config dirs here and there. Second, the nfs client may not have /etc/opt/csw or /etc/opt/mrtx yet, and you need to mkdir them before you can mount. Huh ? Thats that the automounter is for! Huhh, really ?? Still: 3 1. Will you deny that?? Okay so you have 3 mounts instead of 1. That is 3 lines in one automount map in the nameservice - big deal. Solaris unlike some other systems really doesn't have a problem scaling to thousands of client side mounts - personally I've see a system with at least 5000 client side mounts and that was 7 years ago! -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Shipping lsof with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up
On 1/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Peter Tribble wrote: On 1/1/07, wb [EMAIL PROTECTED] wrote: I have a /tmp FS for swap, and a really big file crout* inside. The /tmp was 95% up. I decided to remove the crout file. The problem, is the /tmp is not decreasing, but still growing. How could I make it decrease? Find and kill the process that's writing to that file. Somehow I am wondering why Solaris doesn't ship lsof in /usr/sbin/ ... is this just noone had time yet or something else ? No; it's something that we won't ship, ever because of the nature how lsof trawls for its events. You could send patches to fix lsfo if you do not like it's implementation :) Josh ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Shipping lsof with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up
On 1/5/07, Frank Hofmann [EMAIL PROTECTED] wrote: On Fri, 5 Jan 2007, Martin Bochnig wrote: I think Sun has to overcome both not invented here and the instinctive reject via not perfect, therefore not 'good enough' no matter what the users say, before lsof goes into mainstream Solaris. If Opensolaris rejects software which is not prefect or troublesome it may be time to kill the /bin/sh-rubbish with a less crappy version (hey, ksh93 would be a cool candidate) Josh ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Booting Solaris into trusted mode?
On 12/30/06, Boyd Adamson [EMAIL PROTECTED] wrote: On 30/12/2006, at 5:08 AM, Josh Hurst wrote: How can I boot (Open)Solaris into the Trusted Solaris mode? Josh It's not as simple as booting into Trusted Solaris mode. You need to install and configure the Trusted Extensions. There is ample documentation here: http://docs.sun.com/app/docs/coll/ 175.9 Why are the Trusted Extension packages not installed by default? I selected 'Full Install' during installation and the installer did not install these packages Josh ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Shipping lsof with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up
On 1/5/07, Rich Teer [EMAIL PROTECTED] wrote: On Fri, 5 Jan 2007, Christoph Hellwig wrote: Note that lsof doesn't have to do kmem craling. For example on Linux it only uses proper procfs interfaces. As such proper interfaces seem to exist on Solaris as well for use with pfiles it shouldn't be a problem for people knowledgeable in this area to adjust lsof to do the right thin on Solaris aswell. Have we invited Vic Abel Vic's name is spelled 'Abell', two e- (lsof's author) to join the OpenSolaris community? With the right support framework in place, he'd probably be the best person to make the required changes (in lsof anyway). Better: Sun could hire him! Josh ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Shipping lsof with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up
Josh Hurst wrote: On 1/5/07, Frank Hofmann [EMAIL PROTECTED] wrote: On Fri, 5 Jan 2007, Martin Bochnig wrote: I think Sun has to overcome both not invented here and the instinctive reject via not perfect, therefore not 'good enough' no matter what the users say, before lsof goes into mainstream Solaris. If Opensolaris rejects software which is not prefect or troublesome it may be time to kill the /bin/sh-rubbish with a less crappy version (hey, ksh93 would be a cool candidate) The problem with lsof is an architectural one, I don't think this is a fair comparison with /bin/sh which isn't architecturally flawed just not to some peoples liking. In the current implementation for Solaris it pokes around in kernel memory and it has no business doing so, it can and will break. An implementation of lsof that used documented and Committed interfaces (heck even ones marked Volatile rather than some form of Private) would be much more likely to be accepted. Just because /bin/sh isn't your shell of choice doesn't make it crappy. Now I'm not saying that /bin/sh shouldn't be replaced, IMO a POSIX compliant /bin/sh would be very nice - however that happens to get implemented be it ksh93 or something else. -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] rpm vs pkgadd (again!)
On 1/5/07, Darren J Moffat [EMAIL PROTECTED] wrote: UNIX admin wrote: The MRTX pkgs will. However, marTux itself will be rpm based while offering pkgadd compatibility at the same time. I believe that your time reengineering / repackaging software in RPM would be better spent formally extending `pkgadd` and friends with features that `rpm` has and `pkgadd` tools don't. exactly which needed features are those that rpm has that pkgadd does not ? if youre taking RFE orders... :) i dont know about rpm, but i would like to see some of the urmi features integrated, urpmi is a tool from mandriva ( a redhat derivative) that can be configured to automatically download packages from the web or the mandrake cd, it behaves much like apt does nacho ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Shipping lsof with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up
Josh Hurst writes: On 1/5/07, Frank Hofmann [EMAIL PROTECTED] wrote: On Fri, 5 Jan 2007, Martin Bochnig wrote: I think Sun has to overcome both not invented here and the instinctive reject via not perfect, therefore not 'good enough' no matter what the users say, before lsof goes into mainstream Solaris. If Opensolaris rejects software which is not prefect or troublesome it may be time to kill the /bin/sh-rubbish with a less crappy version (hey, ksh93 would be a cool candidate) There might be a difference between rejecting the integration of _new_ things that don't match current quality (or other) standards, and removing or replacing existing things that retroactively fail to live up to expectations. No? -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Booting Solaris into trusted mode?
Josh Hurst writes: On 12/30/06, Boyd Adamson [EMAIL PROTECTED] wrote: There is ample documentation here: http://docs.sun.com/app/docs/coll/ 175.9 Why are the Trusted Extension packages not installed by default? I selected 'Full Install' during installation and the installer did not install these packages I would suggest checking the documentation. The Trusted Extensions packages substantially change the behavior of the system -- a trusted system is _not_ the same as a plain Solaris system. Thus, installation of them has to be a choice. For example, when a system is trusted, Zones are used to represent security labels. The user sees a single system, even though each label is implemented with a separate zone. This implies that you _cannot_ set up ordinary zones on a trusted system; they're all part of the collective. May other things change as well, such as the operation of TCP/IP. (Yes, it might have been possible to make the trusted mode on/off switch a run-time variable that's separate from the package installation, but that's not how it was designed.) security-discuss might be a better list for these questions, as they're not really related to install itself or the development of Open Solaris. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Shipping lsof with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up
On Fri, 5 Jan 2007, Josh Hurst wrote: Vic's name is spelled 'Abell', two e- Whoops, my bad! Sorry Vic (I thought something didn't look quite right when I wrote that post)... -- Rich Teer, SCNA, SCSA, SCSECA, OpenSolaris CAB member . * * . * .* . . * . .* President, * . . /\ ( . . * Rite Online Inc. . . / .\ . * . .*. / * \ . . . /* o \ . Voice: +1 (250) 979-1638* '''||''' . URL: http://www.rite-group.com/rich ** ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] rpm vs pkgadd (again!)
Ignacio Marambio Catán wrote: On 1/5/07, Darren J Moffat [EMAIL PROTECTED] wrote: UNIX admin wrote: The MRTX pkgs will. However, marTux itself will be rpm based while offering pkgadd compatibility at the same time. I believe that your time reengineering / repackaging software in RPM would be better spent formally extending `pkgadd` and friends with features that `rpm` has and `pkgadd` tools don't. exactly which needed features are those that rpm has that pkgadd does not ? if youre taking RFE orders... :) i dont know about rpm, but i would like to see some of the urmi features integrated, urpmi is a tool from mandriva ( a redhat derivative) that can be configured to automatically download packages from the web or the mandrake cd, it behaves much like apt does pkgadd http://example.com/stuff/foobar.pkg pkgadd https://example.com/goodstuff/barfoo.pkg Both already work in pkgadd. -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: [EMAIL PROTECTED] project proposal __/__ WAS: Re: Re: Re: Is M
Darren J Moffat wrote: Martin Bochnig wrote: Darren J Moffat wrote: Okay so you have 3 mounts instead of 1. That is 3 lines in one automount map in the nameservice - big deal. Solaris unlike some other systems really doesn't have a problem scaling to thousands of client side mounts - personally I've see a system with at least 5000 client side mounts and that was 7 years ago! Okay, sure. I agree. Tell this others, not MRTX. I already sayd that I strive to stay SVR4 compliant, that's what approved good standards are for. away now, bye ... -- Martin Bochnig ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [EMAIL PROTECTED] project proposal __/__ WAS: Re: Re: Re: Is M
the UI is quite different don't help Firefox's case either. You need to go into about:config to change the UIs to suit your taste (e.g., the way tabs are closed, etc.) This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Obtaining nameservice-independent user_attrand publickey data from a shell script ?
On Fri, Jan 05, 2007 at 02:59:55AM +0100, Martin Bochnig wrote: So how would you be able to bypass any nameservice defined in nsswitch.conf, getting those user_attr attributes in a nameservice-independent way? I mean, either you get it locally (files), or you may get it via one of the nameservices (its commands). What do you mean? Do you intend to intrude somewhere ;-) How does nisinit get names from dns even if your system is set to resolve via NIS+? -Peter -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Obtaining nameservice-independent user_attrand publickey data from a shell script ?
On Fri, Jan 05, 2007 at 12:25:30PM +0100, Martin Bochnig wrote: Martin Bochnig wrote: Peter C. Norton wrote: On Fri, Jan 05, 2007 at 02:59:55AM +0100, Martin Bochnig wrote: So how would you be able to bypass any nameservice defined in nsswitch.conf, getting those user_attr attributes in a nameservice-independent way? I mean, either you get it locally (files), or you may get it via one of the nameservices (its commands). What do you mean? Do you intend to intrude somewhere ;-) How does nisinit get names from dns even if your system is set to resolve via NIS+? -Peter Maybe you mean, Roland would want to clone the methods in which /usr/sbin/nisinit accesses those data? But we are talking about C-functions then, not a pure shell script. Anyways ... I think he wants to be able to add a flag, i.e. -nssvc nis, -nssvc dns, -nssvc 'ldap', etc. to getent that will dlopen the appropriate nss_blah library instead of following the lookup in nsswitch.conf so that the lookup to a particular database can be scripted. -Peter -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Booting Solaris into trusted mode?
Josh Hurst wrote: On 12/30/06, Boyd Adamson [EMAIL PROTECTED] wrote: On 30/12/2006, at 5:08 AM, Josh Hurst wrote: How can I boot (Open)Solaris into the Trusted Solaris mode? Josh It's not as simple as booting into Trusted Solaris mode. You need to install and configure the Trusted Extensions. There is ample documentation here: http://docs.sun.com/app/docs/coll/ 175.9 Why are the Trusted Extension packages not installed by default? I selected 'Full Install' during installation and the installer did not install these packages [EMAIL PROTECTED] is probably a better alias to ask this on since that where most of the TX developers listen. I've cc'd that alias and set Reply-To there, the original aliases are Bcc'd. When the packages are installed they automatically enable labeling, and as such disables branded zones. This is because they were originally designed to be able to be shipped separately from Solaris as a layered product, the plan changed but the implementation has not yet. I believe the plan for the future is that they will be installed by default but that requires some changes in how we determine if we should be running label aware or not. -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Booting Solaris into trusted mode?
Josh Hurst wrote: On 12/30/06, Boyd Adamson [EMAIL PROTECTED] wrote: On 30/12/2006, at 5:08 AM, Josh Hurst wrote: How can I boot (Open)Solaris into the Trusted Solaris mode? Josh It's not as simple as booting into Trusted Solaris mode. You need to install and configure the Trusted Extensions. There is ample documentation here: http://docs.sun.com/app/docs/coll/ 175.9 Why are the Trusted Extension packages not installed by default? I selected 'Full Install' during installation and the installer did not install these packages [EMAIL PROTECTED] is probably a better alias to ask this on since that where most of the TX developers listen. I've cc'd that alias and set Reply-To there, the original aliases are Bcc'd. When the packages are installed they automatically enable labeling, and as such disables branded zones. This is because they were originally designed to be able to be shipped separately from Solaris as a layered product, the plan changed but the implementation has not yet. I believe the plan for the future is that they will be installed by default but that requires some changes in how we determine if we should be running label aware or not. -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] rpm vs pkgadd (again!)
(cc'ing install-discuss) On Fri, 2007-01-05 at 16:15 +, Darren J Moffat wrote: exactly which needed features are those that rpm has that pkgadd does not ? One feature that's missing, and would be infinitely useful for online package repositories, is = style version checking in dependencies. E.g. if I have an xchat package that was compiled against GNOME 2.16, I'd like to say in the depend file that it needs SUNWgnome-base-libs = 2.16.0. Laca ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: [EMAIL PROTECTED] project proposal __/__ WAS: Re: Re: Re: I
My biggest gripe with Blastwave is that they are not System V compliant. Dennis says this is because they wanted everything in one place. I fail to see how NFS-mounting /etc/opt/csw from another server would have been a problem, but OK. I like the way Blastwave.org is structured as I can mount everything in a separate partition to be shared by multiple Solaris installations. The installations can be subsequently upgraded, but /opt/csw stays there. No need to re-install those packages. Coming from Linux background, this is IMNSHO probably one of the best selling points for Solaris. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] rpm vs pkgadd (again!)
On 1/5/07, Darren J Moffat [EMAIL PROTECTED] wrote: Ignacio Marambio Catán wrote: On 1/5/07, Darren J Moffat [EMAIL PROTECTED] wrote: UNIX admin wrote: The MRTX pkgs will. However, marTux itself will be rpm based while offering pkgadd compatibility at the same time. I believe that your time reengineering / repackaging software in RPM would be better spent formally extending `pkgadd` and friends with features that `rpm` has and `pkgadd` tools don't. exactly which needed features are those that rpm has that pkgadd does not ? if youre taking RFE orders... :) i dont know about rpm, but i would like to see some of the urmi features integrated, urpmi is a tool from mandriva ( a redhat derivative) that can be configured to automatically download packages from the web or the mandrake cd, it behaves much like apt does pkgadd http://example.com/stuff/foobar.pkg pkgadd https://example.com/goodstuff/barfoo.pkg Both already work in pkgadd. aparently i was not clear enough in my explanaition about urmpi, urpmi xchat installs the package xchat from either the cd or a remote package repository, it will also download and install all the necesary dependencies. think of pkg-get nacho ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] opensolaris tag on upcoming.org
I was playing around with upcoming.org today, yahoo's web 2.0 social bookmarks style global upcoming events calendar and noticed there were no events tagged opensolaris, so I entered two of them, just to see what happens: http://upcoming.org/tag/opensolaris/ It might be an interesting place to keep track of upcoming user group meetings, conferences, opensolaris geek gatherings, etc. or it might be just silliness - but how will we know if no one tries it? -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Shipping lsof with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up
No; it's something that we won't ship, ever because of the nature how lsof trawls for its events. You could send patches to fix lsfo if you do not like it's implementation :) You could check the source code and look for my name there. While I understand James' aversion against my comments, I think my comment is well-tempered by my continuous contributions and testing. (I'm generally the person inside Sun who makes sure that it compiles and runs under newer releases, in the old days long before they hit customers) I like lsof and think it is a useful tool; but the current implementation has some serious architectural shortcomings. In the past we have talked about making sufficient information available, but it is always difficult to define a proper set of interfaces and implement them such that they don't step on performance (by looking at objects in use by others). Solaris implements netstat without groping through the kernel; this makes it reliable but also caused some performance issues. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [install-discuss] Re: [osol-discuss] Booting Solaris into trusted mode?
Why are the Trusted Extension packages not installed by default? I selected 'Full Install' during installation and the installer did not install these packages Because the system then becomes a Trusted System and behaves differently (no ordinary zones, for one) Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: rpm vs pkgadd (again!)
exactly which needed features are those that rpm has that pkgadd does not ? That's really for Martin and not for me to say, since he seems to be the one preferring `rpm` to `pkgadd` and friends. But since you're asking me, I'll tell you what I plan to do to `pkgadd`. I plan to extend it such that by setting SUNW_PKG_REVCHECK=true or similar in the pkginfo will make `pkgadd` revision aware. I have to think about it some more, since I absolutely and without a doubt want my ehancement to be both backward and forward compatible with the present `pkgadd`. There are principally several major features `pkgadd` is lacking, and those are: if I need REV 1.0 or 2007.01.05.07 of some dependency, and I have REV 3.2 or 2007.04.18.23 of the said software, `pkgadd` should be able to recognize that I have satisfied the min REV required, and plough on instead of doing a string-like check and *insisting* that I need *exactly* REV 1.0 (or 2007.01.05.07, for example). That right there is one of the biggest weaknesses of the System V packaging. The second thing is how upgrades are handled; this, however, is an issue that can be addressed separately. For example, on SGI's IRIX, `inst` is smart enough to note the difference between two same subsystems of a different revision: if a newer subsystem *does not* have files that the old one does, the now unnecessary files will be automatically and transparently removed by `inst`. This is an upgrade feature of `inst` that I find simply and without any doubt phenomenal!!! Both of the aforementioned issues and scenarios is where `inst` excells. I have never worked with a UNIX/Linux software management subsystem as elegant and as intelligent as `inst`! If SGI should tank tomorrow, *one* technology I would want to preserve from IRIX at all costs (even paying for it out of my own pocket!) would be `inst`. It is simply ingenious. Message was edited by: ux-admin This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [install-discuss] Re: [osol-discuss] rpm vs pkgadd (again!)
Laszlo (Laca) Peter writes: (cc'ing install-discuss) On Fri, 2007-01-05 at 16:15 +, Darren J Moffat wrote: exactly which needed features are those that rpm has that pkgadd does not ? One feature that's missing, and would be infinitely useful for online package repositories, is = style version checking in dependencies. E.g. if I have an xchat package that was compiled against GNOME 2.16, I'd like to say in the depend file that it needs SUNWgnome-base-libs = 2.16.0. It's not missing from the underlying packaging standards -- see pkginfo(4) and depend(4). What's missing is that (a) we don't use it ourselves so you generally won't find such dependencies in Sun-produced software and (2) the tools themselves generally don't use the information. So, you can say it in the depend file if you want, but some work will be needed to make it actually _do_ something useful. Historically, we've taken a different approach here. Instead of attempting to handle these microscopic dependencies (which, at least in my experience, although obvious from the outset, quickly become quite unwieldy in practice), we rest the software stability on a set of architectural rules. Among those are: - If you rely on something special, then it's up to you to arrange for simultaneous delivery of that 'something' so that customers aren't left scrambling to figure out how to use your software. (E.g., by patch dependencies and/or by special install scripts.) - Incompatible and disruptive change occurs only in particular kinds of (relatively infrequent) releases. I think the process we've been using has a more robust and predictable result in general, but I suppose I'm willing to be proven wrong by some really snazzy inter-dependency checker. :- -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Obtaining nameservice-independent user_attrand publickey data from a shell script ?
Peter C. Norton writes: I think he wants to be able to add a flag, i.e. -nssvc nis, -nssvc dns, -nssvc 'ldap', etc. to getent that will dlopen the appropriate nss_blah library instead of following the lookup in nsswitch.conf so that the lookup to a particular database can be scripted. Better yet, being able to specify the search order explicitly from the command line would be extremely helpful in answering what if? sorts of questions. It sounds like part of a decent RFE to me. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Shipping lsof with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up
On 1/5/07, Darren J Moffat [EMAIL PROTECTED] wrote: Just because /bin/sh isn't your shell of choice doesn't make it crappy. Really? Take 1: /bin/sh /dev/urandom Illegal Instruction (core dumped) Take 2-29: cat /var/adm/messages* | grep -F core.sh | sort Dec 10 11:09:41 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[17713] core dumped: /var/coredumps/core.sh.17713 Dec 10 11:11:14 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[17730] core dumped: /var/coredumps/core.sh.17730 Dec 11 11:19:16 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[19118] core dumped: /var/coredumps/core.sh.19118 Dec 11 11:30:47 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[10798] core dumped: /var/coredumps/core.sh.10798 Dec 11 13:11:06 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[13615] core dumped: /var/coredumps/core.sh.13615 Dec 11 13:13:31 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[15465] core dumped: /var/coredumps/core.sh.15465 Dec 11 16:10:41 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[819] core dumped: /var/coredumps/core.sh.819 Dec 11 16:47:18 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[1181] core dumped: /var/coredumps/core.sh.1181 Dec 11 16:48:16 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[3961] core dumped: /var/coredumps/core.sh.3961 Dec 11 17:11:13 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[15754] core dumped: /var/coredumps/core.sh.15754 Dec 11 17:13:09 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[17434] core dumped: /var/coredumps/core.sh.17434 Dec 13 01:10:19 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[17595] core dumped: /var/coredumps/core.sh.17595 Dec 13 01:11:04 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[19439] core dumped: /var/coredumps/core.sh.19439 Dec 13 08:10:31 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[14917] core dumped: /var/coredumps/core.sh.14917 Dec 17 04:44:47 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[19766] core dumped: /var/coredumps/core.sh.19766 Dec 17 06:44:04 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[51] core dumped: /var/coredumps/core.sh.51 Dec 17 11:17:44 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[10611] core dumped: /var/coredumps/core.sh.10611 Dec 17 11:17:49 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[10637] core dumped: /var/coredumps/core.sh.10637 Dec 17 11:18:14 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[10639] core dumped: /var/coredumps/core.sh.10639 Dec 17 11:18:16 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[10641] core dumped: /var/coredumps/core.sh.10641 Dec 19 06:44:30 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[116] core dumped: /var/coredumps/core.sh.116 Dec 19 06:48:04 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[14186] core dumped: /var/coredumps/core.sh.14186 Dec 19 06:49:53 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[16316] core dumped: /var/coredumps/core.sh.16316 Dec 19 10:07:07 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[19503] core dumped: /var/coredumps/core.sh.19503 Dec 19 10:08:08 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[1131] core dumped: /var/coredumps/core.sh.1131 Dec 19 10:18:09 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[11835] core dumped: /var/coredumps/core.sh.11835 Dec 19 10:18:09 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[11836] core dumped: /var/coredumps/core.sh.11836 Dec 19 10:18:47 fido genunix: [ID 603404 kern.notice] NOTICE: core_log: sh[11841] core dumped: /var/coredumps/core.sh.11841 Popular root of the problem: Memory corruption, memory misalignment, buffer corruption This is Solaris 10 Update 2. Nice production quality, eh? /bin/sh in Solaris 11 is no better Josh ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: rpm vs pkgadd (again!)
exactly which needed features are those that rpm has that pkgadd does not ? Third thing that I find ingenious in both `inst` and `swinstall` on HP-UX is hierarchical namespaces: on both IRIX and HP-UX one is able to package software hierarchichally, for example (on IRIX:) eoe.sw.bind - execution only environment.bind - a dist eoe.sw.bind.sw - one of the subsystems eoe.sw.bind.man eoe.sw.bind.hea eoe.sw.bind.libs eoe.sw.bind.libs64 (on HP-UX:) # BIND 9.3.2-P1_REV=2006.09.27.01 BIND BIND.BIND-ENG-A-MAN 9.3.2-P1_REV=2006.09.27.01 BIND man pages BIND.BIND-PRG 9.3.2-P1_REV=2006.10.03.01 BIND development files BIND.BIND-SERVER 9.3.2-P1_REV=2006.10.03.01 named and related binaries BIND.BIND-SHLIBS 9.3.2-P1_REV=2006.10.03.01 BIND shared object libraries BIND.BIND-STARTUP 9.3.2-P1_REV=2006.10.03.01 Startup/shutdown scripts BIND.BIND-UTILS 9.3.2-P1_REV=2006.10.03.01 named client binaries This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: [EMAIL PROTECTED] project proposal __/__ WAS: Re: Re: Re: I
I like the way Blastwave.org is structured as I can mount everything in a separate partition to be shared by multiple Solaris installations. The installations can be subsequently upgraded, but /opt/csw stays there. No need to re-install those packages. Coming from Linux background, this is IMNSHO probably one of the best selling points for Solaris. Yeah, but that has nothing to do with being System V compliant. Even if Blastwave was fully system V compliant, you'd still be able to do the exact same thing. System V compliance doesn't affect the way you'd upgrade, or not upgrade, at least not in this scenario. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Shipping lsof with Solaris ? / was: Re: problem with /tmp FS still up
In the current implementation for Solaris it pokes around in kernel memory and it has no business doing so, it can and will break. Right; according to the author of `lsof` himself, `lsof` peeks into private Solaris kernel structs and is likely to crash if those are changed. This is what the author of `lsof` himself had to say on the matter -- and he seemed fully aware that he's doing something that is not correct! So my hair stands up on my head when I sit in management meetings and one of my collagues whines why we can't have `lsof` integrated in our internal build of Solaris... absolutely horrible. If that doesn't frustrate one, I don't know what would. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Shipping lsof with Solaris ? / was: Re: problem with /tmp FS still up
Really? Take 1: /bin/sh /dev/urandom Illegal Instruction (core dumped) Take 2-29: cat /var/adm/messages* | grep -F core.sh | sort You can take takes 'till the cows come home, but the day Solaris breaks backward compatibility is the day Solaris will become crap, just like some other UNIX-like kernel under the GNU label that does that kind of thing all the time. And I do not believe any self-respecting engineer at Sun will ever allow for something like that to happen. Well, perhaps they would... over their dead bodies. Luckily for the rest of us out there in the wild. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: rpm vs pkgadd (again!)
On 1/5/07, UNIX admin [EMAIL PROTECTED] wrote: exactly which needed features are those that rpm has that pkgadd does not ? ... There are principally several major features `pkgadd` is lacking, and those are: if I need REV 1.0 or 2007.01.05.07 of some dependency, and I have REV 3.2 or 2007.04.18.23 of the said software, `pkgadd` should be able to recognize that I have satisfied the min REV required, and plough on instead of doing a string-like check and *insisting* that I need *exactly* REV 1.0 (or 2007.01.05.07, for example). I can't see that working. You have no idea whatsoever whether a later version will be compatible with the minimum version, and even if one later version is compatible then subsequent later versions may not be. If you want to do something like this then surely the right place would be for REV 3.2 to declare that it also provides REV 1.0. That way when REV 4.3 that is an incompatible version of that dependency is released, you don't get shafted. For example, on SGI's IRIX, `inst` is smart enough to note the difference between two same subsystems of a different revision: if a newer subsystem *does not* have files that the old one does, the now unnecessary files will be automatically and transparently removed by `inst`. This is an upgrade feature of `inst` that I find simply and without any doubt phenomenal!!! Ermmm. In what way is this different from pkgrm of the old version followed by pkgadd of the new version? (There is room for a one-step implementation, especially as that would allow you to do this safely in the case where other packages depended on the package you want to update.) Both of the aforementioned issues and scenarios is where `inst` excells. I have never worked with a UNIX/Linux software management subsystem as elegant and as intelligent as `inst`! If there's one way in which I've been fortunate recently, it's that I no longer have to deal with the monstrosity that is inst. Anything that can get so tangled up that it cannot allow you to install some software because of irreconcilable dependencies is something I'm glad to be rid of. (Although I have seen rpm based machines go into the same abyss.) -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: rpm vs pkgadd (again!)
exactly which needed features are those that rpm has that pkgadd does not ? The one that I would like to see implemented (I need more time...) is that when I go pkgadd pkg1 pkg2 and pkg1 depends on pkg2 it is smart enough to automatically install pkg2 first followed by pkg1. Ditto pkgrm. And also for the case where you go pkgadd -d . and select all, it installs then in dependency order. I don't particularly want pkgadd to start retrieving packages from 3rd-party repositories all of its own volition - it seems to me that there should be higher level tools (as indeed there are) to do that particular task. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] WLAN on dell 1501 with NDIS and Solaris 10 06/11
Hi, following the document on Solaris NDIS Wrapper Toolkit (http://www.opensolaris.org/os/community/laptop/wireless/ndis/), I'm trying to build the driver on my DELL 1501 (equipped with an AMD Turion 64 X2 TL-56 and a mini WLAN Dual Band wireless DELL 1490) with Solaris 10 06/11, but without success. WLAN DRIVERS I installed the last avalaible driver from the DELL site (R140747.EXE), but the only .INF and .SYS files found are the following: - drwxr-xr-x 2 root root 512 Jan 3 19:19 . drwxr-xr-x 6 root root 512 Jan 3 19:18 .. -rwxr-xr-x 1 root root 640898 Jan 3 19:19 BCMWL5.INF -rwxr-xr-x 1 root root 604928 Jan 3 19:19 BCMWL5.SYS -rwxr-xr-x 1 root root 754688 Jan 3 19:19 BCMWL564.SYS - I used the iconv command to convert the UNICODE file (bcmwl5.inf.orig) to the ASCII file (bcmwl5.inf) - -rw-r--r-- 1 root root 320448 Jan 3 22:11 bcmwl5.inf -rwxr-xr-x 1 root root 640898 Jan 3 19:24 bcmwl5.inf.orig -rwxr-xr-x 1 root root 604928 Jan 3 19:25 bcmwl5.sys -rwxr-xr-x 1 root root 754688 Jan 3 21:10 bcmwl564.sys - I started to build the driver in the i386 directory, but the 'ndiscvt' step generated the error: - d1501 (/opt2/download/wireless/ndis-0.1/i386) ./ndiscvt -i bcmwl5.inf -s bcmwl5.sys -o ndis.h $Windows NT$ d1501 (/opt2/download/wireless/ndis-0.1/i386) make ndis /usr/sfw/bin/gcc -g -O2 -D_KERNEL -D__i386__ -I../include -I. -c ../if_ndis.c -o ndis.o ld -r -o ndis ndis.o ./ndiscvt -i ndis.inf -s ndis.sys -o ndis.h ndiscvt: opening .SYS file 'ndis.sys' failed: No such file or directory *** Error code 1 make: Fatal error: Command failed for target `ndis.h' - I tryed to solve the problem with two links: - d1501 (/opt2/download/wireless/ndis-0.1/i386) ln -s ./bcmwl5.inf ./ndis.inf d1501 (/opt2/download/wireless/ndis-0.1/i386) ln -s ./bcmwl5.sys ./ndis.sys - and all work's fine. Similarly, in the amd64 directory, I experimented the same problem, and the same solution: - d1501 (/opt2/download/wireless/ndis-0.1/amd64) ./ndiscvt -i bcmwl5.inf -s bcmwl564.sys -o ndis.h $Windows NT$ d1501 (/opt2/download/wireless/ndis-0.1/amd64) make ndis /usr/sfw/bin/gcc -fident -finline -fno-inline-functions -fno-builtin -fno-asm -nodefaultlibs -D__sun -O2 -gdwarf-2 -fno-strict-aliasing -fno-unit-at-a-time -fno-optimize-sibling-calls -m64 -mtune=opteron -Wall -Wno-unknown-pragmas -Wno-missing-braces -Wno-sign-compare -Wno-parentheses -Wno-uninitialized -Wno-implicit-function-declaration -Wno-unused -Wno-trigraphs -Wno-char-subscripts -Wno-switch -ffreestanding -mcmodel=kernel -mno-red-zone -D_KERNEL -D__amd64__ -D__amd64 -I../include -I. -c ../if_ndis.c -o ndis.o ld -r -o ndis ndis.o ./ndiscvt -i ndis.inf -s ndis.sys -o ndis.h ndiscvt: opening .SYS file 'ndis.sys' failed: No such file or directory *** Error code 1 make: Fatal error: Command failed for target `ndis.h' d1501 (/opt2/download/wireless/ndis-0.1/amd64) ln -s ./bcmwl564.sys ./ndis.sys d1501 (/opt2/download/wireless/ndis-0.1/amd64) ln -s ./bcmwl5.inf ./ndis.inf d1501 (/opt2/download/wireless/ndis-0.1/amd64) make ndis ./ndiscvt -i ndis.inf -s ndis.sys -o ndis.h $Windows NT$ /usr/sfw/bin/gcc -fident -finline -fno-inline-functions -fno-builtin -fno-asm -nodefaultlibs -D__sun -O2 -gdwarf-2 -fno-strict-aliasing -fno-unit-at-a-time -fno-optimize-sibling-calls -m64 -mtune=opteron -Wall -Wno-unknown-pragmas -Wno-missing-braces -Wno-sign-compare -Wno-parentheses -Wno-uninitialized -Wno-implicit-function-declaration -Wno-unused -Wno-trigraphs -Wno-char-subscripts -Wno-switch -ffreestanding -mcmodel=kernel -mno-red-zone -D_KERNEL -D__amd64__ -D__amd64 -I../include -I. -c ../if_ndis.c -o ndis.o ld -r -o ndis ndis.o - At this point, the modload command generated the following output: - d1501 (/opt2/download/wireless/ndis-0.1/amd64) modload ndisapi can't load module: No such file or directory d1501 (/opt2/download/wireless/ndis-0.1/amd64)
Re: [osol-discuss] recommended software?
On 1/5/07, Charles Hedrick [EMAIL PROTECTED] wrote: I'm an experience Solaris sysadmin, but I haven't used a current version on the desktop. I'm trying to figure out what software to use. I've tried nextenta. It works pretty well, but I really want Solaris, not Linux on a Solaris kernel. The best option seemed to be Solaris Express. However it doesn't seem to be a complete enviornment. Perhaps it would be helpful for you to list the missing pieces. I've used packages from Sun Freeware with it without problems. But a few things I want aren't there. I had hoped to use Blastwave, but when I loaded Scribus from there, it messed things up badly enough that I had to reinstall. I see that Blastwave doesn't support Solaris Express, so that looks like an unsafe source. I thought it did. But Dennis would be authoritative... (I've never had blastwave do any significant damage to a system, it does a good job of keeping its fingers to itself.) At the very least I'd like a development environment. I'm thinking of gcc (which one?) from Sunfreeware. Is that the right choice? Erm, gcc comes with Solaris these days. And there are rumours of Studio 11 integration around the corner. I just use the bundled gcc and install Studio 11 as well. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: rpm vs pkgadd (again!)
Peter Tribble writes: pkgadd pkg1 pkg2 Dependency ordering is already present for patchadd. There are many bugs on this for the pkg* tools: RFE 1105830 is the granddaddy of them and requests ordering RFE 1145132 requests pkgadd to prompt for and install dependencies RFE 1249489 is a related issue with pkgchk RFE 4795539 appears to be a dup of 1105830, as far as I can tell There may well be other duplicates here; it's an oft-reported item. I think Vassili discussed the topic on install-discuss recently. That'd be a better place to bring it up. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] recommended software?
I'm an experience Solaris sysadmin, but I haven't used a current version on the desktop. I'm trying to figure out what software to use. The best option seemed to be Solaris Express. However it doesn't seem to be a complete enviornment. I've used packages from Sun Freeware with it without problems. But a few things I want aren't there. I had hoped to use Blastwave, but when I loaded Scribus from there, it messed things up badly enough that I had to reinstall. You mean this ? : http://www.blastwave.org/articles/BLS-0039/scribus_131.jpg That's a problem child, I know. I'll look into it if you file a bug report. You did file a bug report right ? I see that Blastwave doesn't support Solaris Express, so that looks like an unsafe source. No one supports Solaris Express. Not even Sun. I think what you mean is that the software is fully expected to run just fine. It IS expected to run just fine. There, okay ? You see, it works like this. If you have a piece of software that is compiled on Solaris 8 and it runs fine on Solaris 8 then you can rest assured that it will run on Solaris 9. Thats a promise. If it runs on 9 then it will run on 10. That's a promise. If it runs on 10 then you have every reason to expect it to run on Solaris Express which is really Solaris 11 beta. The word I use is expect because Solaris Express is a moving picture. At the very least I'd like a development environment. I'm thinking of gcc (which one?) from Sunfreeware. Is that the right choice? What ? no no no .. just say no. Get Sun Studio 11 and then install a _real_ commercial grade SET of tools that far exceed GCC. In every measurable way. Look man, I don't work for Sun and I'm not just blowing smoke here. Nothing builds software better on Solaris than the Studio tools and you can get Studio 11 for free. It probably rocks on Linux also but I wouldn't know. If you really want GCC then fine .. guess what .. its built in there already and if you want a multitude of versions to choose from then look in the packages list at : http://www.blastwave.org/packages.php Are there other places I should look? Under the rug? The Companion CD has been around forever. I dunno. I'm a bit surprised not to see an FAQ on this topic. There are lots of pointers to Solaris Express on this site, but nothing on software to use with it. Well that is without a doubt one of the funniest things I have heard in a long long time. That is like someone standing in the Library of Congress saying that they can't find a book. The whole community process and everyone in it is in front of you and all you have to do is ask a question. Try that at a library and it works there too. -- Dennis Clarke ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: rpm vs pkgadd (again!)
UNIX admin wrote: if I need REV 1.0 or 2007.01.05.07 of some dependency, and I have REV 3.2 or 2007.04.18.23 of the said software, `pkgadd` should be able to recognize that I have satisfied the min REV required, and plough on instead of doing a string-like check and *insisting* that I need *exactly* REV 1.0 (or 2007.01.05.07, for example). The fallacy here is in *assuming* that rev 3.2 is exactly compatible with your 1.0 usage. As Jim said, Sun's approach to this problem has been to say what you mean, and mean what you say. That is, be explicit about your promises (the interface taxonomy) and follow up on those expectations by being honest with your version numbers (the release taxonomy). If the bits you are producing are compatible, we say that the major and minor version identifiers for your released component stay the same. And, if you make an incompatible change, you also need to change the high order version number(s). This way, anything that depended on the 1.0 interfaces could safely depend on any later 1.0.* release of the library, but could not safely depend on a 2.* version because, by definition, the 2.0 version exhibits incompatibilities with the previous 1.0 stuff. In this world view (which is by no means universal), it would be a bug to implement dependency equivalence as you suggest, because, as the quote goes, it just ain't so!. -John ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Shipping lsof with Solaris ? / was: Re: problem with /tmp FS still up
UNIX admin wrote: `lsof` peeks into private Solaris kernel structs and is likely to crash if those are changed. So my hair stands up on my head when I sit in management meetings and one of my collagues whines why we can't have `lsof` integrated in our internal build of Solaris... absolutely horrible. If you postulate that 1) lsof is tightly bound to a particular kernel build, 2) lsof behaves correctly on the kernel it was built for, and 3) lsof will be rebuilt and redelivered in concert with any and all new kernel builds then there is no architectural problem with what your colleague suggests. We tend to call such things consolidation private dependencies and gleefully (for the ARCs at least) delegate the job of keeping the producer (kernel) and consumer (lsof) working correctly to the people who are responsible for delivering the consolidation itself... Of course, if you can't guarantee #2 above, this won't work. -John ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re[2]: [osol-discuss] recommended software?
Hello Dennis, Friday, January 5, 2007, 11:25:45 PM, you wrote: I see that Blastwave doesn't support Solaris Express, so that looks like an unsafe source. DC No one supports Solaris Express. Not even Sun. I think what you mean is DC that the software is fully expected to run just fine. Actually Sun does - you can buy a support for Solaris Express from Sun (I did once). -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] recommended software?
Hello Charles, Friday, January 5, 2007, 10:12:57 PM, you wrote: Generally Blastwave should and does work on SX. There's already gcc included in Solaris (and SX) - however there's no gdb (yet). Eventually go with gcc from Blastwave - works fine. Additionally you may want to try Sun Studio 11 as Denis pointed out - it's free and with SXCR 55 (which should be publicly available really soon now I hope) Sun Studio is already included. -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: U20 nge driver not working since build 52
So has this bug been fixed yet ? Rgds Robin This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: recommended software?
The best option seemed to be Solaris Express. However it doesn't seem to be a complete enviornment. I've used packages from Sun Freeware with it without problems. But a few things I want aren't there. I had hoped to use Blastwave, but when I loaded Scribus from there, it messed things up badly enough that I had to reinstall. I see that Blastwave doesn't support Solaris Express, so that looks like an unsafe source. At the very least I'd like a development environment. I'm thinking of gcc (which one?) from Sunfreeware. Is that the right choice? I use Solaris Express as my desktop and I've got several blastwave packages installed. Since nobody mentioned it, here's the opensolaris page with information on downloading and installing the Sun Studio compilers: http://www.opensolaris.org/os/community/tools/sun_studio_tools/sun_studio_11_tools/ I used installation option 1. Just make sure to setup your $PATH correctly. Haik This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: WLAN on dell 1501 with NDIS and Solaris 10 06/11
--- with a lot of messages in the /var/adm/messages file (see below for a little extract) -- --- Jan 5 20:41:43 d1501 genunix: [ID 387338 kern.notice] symbol x86_64_wrap_end: Jan 5 20:41:43 d1501 genunix: [ID 780736 kern.notice] value 0xf417229c does not fit Jan 5 20:41:43 d1501 genunix: [ID 754994 kern.notice] relocation error: 10: Jan 5 20:41:43 d1501 genunix: [ID 397992 kern.notice] file /opt2/download/wireless/ndis-0.1/amd64/ndisapi: Jan 5 20:41:43 d1501 genunix: [ID 387338 kern.notice] symbol x86_64_wrap_call: Jan 5 20:41:43 d1501 genunix: [ID 780736 kern.notice] value 0xf4172281 does not fit Jan 5 20:41:43 d1501 genunix: [ID 399259 kern.notice] do_relocations: /opt2/download/wireless/ndis-0.1/amd64/ndisapi do_relocate failed Jan 5 20:41:43 d1501 genunix: [ID 603676 kern.notice] ndisapi error doing relocations -- --- but I didn't have no more solution or work around to continue ... Does have someone an idea where is the problem or how to continue? I don't think any of the Broadcom 64bit ndis wireless drivers worked with Solaris. Try the 32bit version. ---Bob This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Re[2]: [osol-discuss] recommended software?
Hello Dennis, Friday, January 5, 2007, 11:25:45 PM, you wrote: I see that Blastwave doesn't support Solaris Express, so that looks like an unsafe source. DC No one supports Solaris Express. Not even Sun. I think what you mean is DC that the software is fully expected to run just fine. Actually Sun does - you can buy a support for Solaris Express from Sun (I did once). yeah .. I have that. I can file a bug report and that's all it means. dc ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] recommended software?
Hello Charles, Friday, January 5, 2007, 10:12:57 PM, you wrote: Generally Blastwave should and does work on SX. There's already gcc included in Solaris (and SX) - however there's no gdb (yet). Eventually go with gcc from Blastwave - works fine. Additionally you may want to try Sun Studio 11 as Denis pointed out - it's free and with SXCR 55 (which should be publicly available really soon now I hope) Sun Studio is already included. Can you imagine how long I have waited for a _real_ compiler to delivered with UNIX? Once again ? let's all do the time warp again ... Dennis ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re[2]: [osol-discuss] recommended software?
Hello Dennis, Saturday, January 6, 2007, 2:45:32 AM, you wrote: Hello Charles, Friday, January 5, 2007, 10:12:57 PM, you wrote: Generally Blastwave should and does work on SX. There's already gcc included in Solaris (and SX) - however there's no gdb (yet). Eventually go with gcc from Blastwave - works fine. Additionally you may want to try Sun Studio 11 as Denis pointed out - it's free and with SXCR 55 (which should be publicly available really soon now I hope) Sun Studio is already included. DC Can you imagine how long I have waited for a _real_ compiler to delivered DC with UNIX? Once again ? DC let's all do the time warp again ... Yeah, I'm also glad SS will be integrated. However I wouldn't assume that it's always better than gcc - it's not. Some time ago we did some tests with our application and gcc actually produced faster binaries than SS10 (or 9) on SPARC. Yes, we even tried -fast, still slower. With other app it actually produced faster application. So at least when it comes to performance I guess it depends on application which compiler would provide faster binaries. Nevertheless SS gonna provide complete and mature developer environment OOB which is great. -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: rpm vs pkgadd (again!)
On Fri, Jan 05, 2007 at 02:34:27PM -0800, John Plocher wrote: UNIX admin wrote: if I need REV 1.0 or 2007.01.05.07 of some dependency, and I have REV 3.2 or 2007.04.18.23 of the said software, `pkgadd` should be able to recognize that I have satisfied the min REV required, and plough on instead of doing a string-like check and *insisting* that I need *exactly* REV 1.0 (or 2007.01.05.07, for example). The fallacy here is in *assuming* that rev 3.2 is exactly compatible with your 1.0 usage. As Jim said, Sun's approach to this problem has been to say what you mean, and mean what you say. That is, be explicit about your promises (the interface taxonomy) and follow up on those expectations by being honest with your version numbers (the release taxonomy). If the bits you are producing are compatible, we say that the major and minor version identifiers for your released component stay the same. And, if you make an incompatible change, you also need to change the high order version number(s). The linux packaging tools are way ahead in this respect. 1) Upon package creating, the tools automatically scan for known dependancy types. dynamic libaries are scanned for symbol names and versions (as supplied by the linker, I guess), perl, python and concievably other interpreters will be scanned for statements that indicate dependancy such as use in perl, or import in python. 2) In specifying the package, you can explicitly specify that a package is incompatible with any level of major.minor.subversion-release of any other package, and you can force lower versions of a package by using a special version information tag called an epoch that will supercede other version information. 3) You can state in the package metadata that it provides something such as another package, a specific library (in case it is non-obvious). 4) You can turn off dependancy checking on a per-file, per-library, etc. basis or provide your own because it's very possible that you know better than the packaging system. 5) Rpm is rpmbuild as well. Though you don't have to use it to build the software and the package, it's a lot easier and usually a good discipline because it automates much of the process. This way, anything that depended on the 1.0 interfaces could safely depend on any later 1.0.* release of the library, but could not safely depend on a 2.* version because, by definition, the 2.0 version exhibits incompatibilities with the previous 1.0 stuff. That's why rpmbuild usually goes for library version symbols - libraries change a lot. However shell scripts, binaries, etc. usually have more stable interfaces. However as those change, there are tags to indicate that the package is incompatible with it's older version, and taa-daa, it's now incompatible with packages that depend on the older version. In this world view (which is by no means universal), it would be a bug to implement dependency equivalence as you suggest, because, as the quote goes, it just ain't so!. In practice the solaris shops I've worked at will simply ignore dependancy information because it will prevent perfectly working combinations of software that are intedned to work together. With a better packaging system and package creation standard, most things can be accomodated easily. I don't know why this state of affairs is considered acceptable, let alone preferrable. What am I missing? -Peter -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Re[2]: [osol-discuss] recommended software?
Generally Blastwave should and does work on SX. There's already gcc included in Solaris (and SX) - however there's no gdb (yet). Eventually go with gcc from Blastwave - works fine. Additionally you may want to try Sun Studio 11 as Denis pointed out - it's free and with SXCR 55 (which should be publicly available really soon now I hope) Sun Studio is already included. DC Can you imagine how long I have waited for a _real_ compiler to delivered DC with UNIX? Once again ? DC let's all do the time warp again ... Yeah, I'm also glad SS will be integrated. However I wouldn't assume that it's always better than gcc - it's not. Some time ago we did some tests with our application and gcc actually produced faster binaries than SS10 (or 9) on SPARC. Yes, we even tried -fast, still slower. With other app it actually produced faster application. So at least when it comes to performance I guess it depends on application which compiler would provide faster binaries. Nevertheless SS gonna provide complete and mature developer environment OOB which is great. well ... I'm not going to get into a compiler holy war but let's just say that -fast is not the optimal way to go. Its just an easy way. let's just be happy that cc will be in there dc ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Obtaining nameservice-independent user_attrandpublickey data from a shell script ?
Martin Bochnig wrote: Martin Bochnig wrote: Peter C. Norton wrote: On Fri, Jan 05, 2007 at 02:59:55AM +0100, Martin Bochnig wrote: [snip] How does nisinit get names from dns even if your system is set to resolve via NIS+? Maybe you mean, Roland would want to clone the methods in which /usr/sbin/nisinit accesses those data? But we are talking about C-functions then, not a pure shell script. I was thinking about something like $ /usr/bin/getent user_attr username # to return the values of |getuserattr()| or $ /usr/bin/getent publickey username # to do the same for the publickey database, regardless how the backend looks like (e.g. files, nisplus, yp, LDAP etc.) etc., e.g. /usr/bin/getent should return the values which the matching library functions would return... Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Obtaining nameservice-independent user_attrandpublickey data from a shell script ?
Martin Bochnig wrote: Roland Mainz wrote: [snip] Normal users with limited privileges may naturally have no - or limited - access. Didn't you find any help in the man pages for NIS, NIS+ and LDAP? That was not the goal. The matching scripts should be able to operate regardless how the backend looks like... Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Obtaining nameservice-independent user_attrandpublickey data from a shell script ?
James Carlson wrote: Peter C. Norton writes: I think he wants to be able to add a flag, i.e. -nssvc nis, -nssvc dns, -nssvc 'ldap', etc. to getent that will dlopen the appropriate nss_blah library instead of following the lookup in nsswitch.conf so that the lookup to a particular database can be scripted. Better yet, being able to specify the search order explicitly from the command line would be extremely helpful in answering what if? sorts of questions. It sounds like part of a decent RFE to me. Ouch... and how would the implementation look like ? The idea was to get simple access to the data independent of the backend nameservice details, e.g. a script should not need to implement support for YP, NIS+, LDAP etc. seperately. Adding those switches would make this MUCH more painfull to implement since we could no longer use any library functions and instead have to do our own lookup code in /usr/bin/getent ... and that's AFAIK an overkill... Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Obtaining nameservice-independent user_attr andpublickey data from a shell script ?
Darren J Moffat wrote: Roland Mainz wrote: Is there a nameservice-independent way to obtain the values for user_attr and publickey from a shell script (if not I would propose to add a extension to getent) ? publickey no there isn't. For user_attr it depends which values you want. I want the raw values as returned by |getuserattr()|, |getprofattr()|, |getprofattr()| etc. ... /usr/bin/getent should just return the matching values, either for the admins, users or shell script to use. user_attr is a little problematic because in some cases it isn't just user_attr you need to look at but you might then need to look at prof_attr, auth_attr and exec_attr as well as policy.conf. There are a couple of shell tools for some of the user_attr data. auths(1) will tell you all the authorisations a user has from user_attr, all included profiles and defaults from policy.conf. profiles(1) will tell you all the profiles a user has assigned to them from user_attr, and policy.conf and any profiles included in a profile. roles(1) will tell you the roles a user has - currently you can only assign a role directly in user_attr(4) but we want to change that so you can do it as part of a profile in prof_attr(4) as well. Ok, but all these tools only return mangled versions of the data and not the raw (or better: unchanged) values as returned by the native library calls, right ? That still leaves: project, defaultpriv, limitpriv, lock_after_retries, idletime, idlecmd, labelview, clearance, min_label, type. For the user_attr(4) database what exactly is it you are trying to do from shell script ? Possible usage would be a system admin to figure out whether the system sees the changed attributes in a way he/she would expect it (e.g. change/modification verification) ... I could imagine futher usage but right now the primary problem is that there is no direct access to these data except looking at /etc/nsswitch.conf and then implement hand-crafted code for each possible backend type - and that's not really usefull... ;-( A better example would be our script which changes the X11 authentification from MIT-MAGIC-COOKIE-1 to SUN-DES-1 if the user has propper DES/DH credentials. If you have access to NIS+ it's no problem - but obtaining the data from other types of directory backends can be a serious pain for shell scripts (and if we add publickey to /usr/bin/getent IMO we should add the other items in /etc/nsswitch.conf in one step (with the limitation that the changes should be easy and obvious), too - just to avoid that someone falls in the same pit as I did long ago... ;-( ). Bye, Roland P.S.: Reply-To: set to OpenSolaris Shell discussions [EMAIL PROTECTED] -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Obtaining nameservice-independent user_attr andpublickey data from a shell script ?
I too would like to see getent extended to handle everything in nsswitch.conf for which the results would be useful, a get*() function exists, and the extension would be reasonably straightforward. I didn't see anything in SUSv3 about getent, so if there's anything that would forbid adding additional databases to it, I don't know what that would be. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
