RE: [osol-discuss] FYI: Re: Installation of OpenSolaris inlogic partition
Hi Moinak, Regarding the installatin and building Solaris Nevada Open Source, we need to perform the following basic step Change GATE to the name of the top-level directory (e.g., testws). Change CODEMGR_WS to the top-level path (e.g., /aux0/testws). Change STAFFER to your login. My top level directory is /. What should STAFFER environment variable be set to login ? Regards Deepak Bhatia -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Moinak Ghosh Sent: Wednesday, January 03, 2007 7:21 PM To: Open Solaris Subject: [osol-discuss] FYI: Re: Installation of OpenSolaris inlogic partition Hi, I have spoken to the people working on this and they will be sending the proposal for an OpenSolaris project in a couple of days. They have most of the implementation done for enabling OpenSolaris to boot off a Logical Partition. This includes changes to fdisk to allow editing logical partitions. However this project does not provide the ability to enable OpenSolaris to be put on multiple partitions. Regards, Moinak. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] FYI: Re: Installation of OpenSolaris inlogic partition
Deepak Bhatia wrote: Hi Moinak, Regarding the installatin and building Solaris Nevada Open Source, we need to perform the following basic step Change GATE to the name of the top-level directory (e.g., testws). Change CODEMGR_WS to the top-level path (e.g., /aux0/testws). Change STAFFER to your login. My top level directory is /. What should STAFFER environment variable be set to login ? Your login name, ie $LOGNAME. -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] FYI: Re: Installation of OpenSolaris inlogic partition
Darren J Moffat writes: > > What should STAFFER environment variable be set to login ? > > Your login name, ie $LOGNAME. Or just leave it blank, and the nightly script will figure it out. Don't over-configure. Most of these things have sane defaults, by design. -- 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] FYI: Re: Installation of OpenSolaris inlogic partition
James Carlson wrote: Darren J Moffat writes: What should STAFFER environment variable be set to login ? Your login name, ie $LOGNAME. Or just leave it blank, and the nightly script will figure it out. Don't over-configure. Most of these things have sane defaults, by design. This one doesn't though because STAFFER is set to 'nobody' and MAILTO is set to $STAFFER. That means that by default you won't get email sent on build completion. I have a workspace with fixes for this and a couple of others to reduce the amount of configuration of the default developer.sh and opensolaris.sh environment files. BTW opensolaris-code or tools-discuss are probably the better aliases for this type of discussion. -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] FYI: Re: Installation of OpenSolaris inlogic partition
Darren J Moffat writes: > This one doesn't though because STAFFER is set to 'nobody' and MAILTO is > set to $STAFFER. That means that by default you won't get email sent on > build completion. Untrue. Nightly does this: # Set default value for STAFFER, if needed. if [ -z "$STAFFER" -o "$STAFFER" = "nobody" ]; then STAFFER=`/usr/xpg4/bin/id -un` export STAFFER fi I _never_ set STAFFER on any of my builds, and it works fine for me. The only things I ever set are NIGHTLY_OPTIONS, CODEMGR_WS, PARENT_WS, and CLONE_WS. -- 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] FYI: Re: Installation of OpenSolaris inlogic partition
James Carlson wrote: Darren J Moffat writes: This one doesn't though because STAFFER is set to 'nobody' and MAILTO is set to $STAFFER. That means that by default you won't get email sent on build completion. Untrue. Nightly does this: # Set default value for STAFFER, if needed. if [ -z "$STAFFER" -o "$STAFFER" = "nobody" ]; then STAFFER=`/usr/xpg4/bin/id -un` export STAFFER fi I _never_ set STAFFER on any of my builds, and it works fine for me. The only things I ever set are NIGHTLY_OPTIONS, CODEMGR_WS, PARENT_WS, and CLONE_WS I notice that you put that in there as part of a bunch of other fixes, none of which have a synopsis that indicates that it was a fix for this problem! I think it would still be helpful to have the STAFFER variable commented out in the nightly environment files, particularly since $STAFFER is really only useful for teamware when nightly was being run as root. -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] FYI: Re: Installation of OpenSolaris inlogic partition
Darren J Moffat writes: > > I _never_ set STAFFER on any of my builds, and it works fine for me. > > The only things I ever set are NIGHTLY_OPTIONS, CODEMGR_WS, PARENT_WS, > > and CLONE_WS > > I notice that you put that in there as part of a bunch of other fixes, > none of which have a synopsis that indicates that it was a fix for this > problem! It was a trivial part of CR 4739385; see the evaluation for details. > I think it would still be helpful to have the STAFFER variable commented > out in the nightly environment files, particularly since $STAFFER is > really only useful for teamware when nightly was being run as root. Actually, I'd sort of like to see the root build mechanism itself ripped out. -- 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] What's the status of virtual consoles?
Normally I'd suggest checking the vconsole-discuss list instead, but it seems to be mostly spam - much higher than other OpenSolaris lists for some reason (is it not spam filtered or set up with the same admin settings as the rest of us who have to filter spam on our lists?). I do know the team has been working on it a lot, but certainly needs to get more of that work out in the open. There's been a lot of design discussions and discussions on interactions with components such as X, gdm, etc. they've held internally that should be held in the open to be a true part of OpenSolaris. -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering Dev Mazumdar wrote: Not a peep from anybody on Virtual consoles! This is not a good sign of open source in action for Solaris. 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] What's the status of virtual consoles?
Alan Coopersmith wrote: Normally I'd suggest checking the vconsole-discuss list instead, but it seems to be mostly spam - much higher than other OpenSolaris lists for some reason (is it not spam filtered or set up with the same admin settings as the rest of us who have to filter spam on our lists?). I do know the team has been working on it a lot, but certainly needs to get more of that work out in the open. There's been a lot of design discussions and discussions on interactions with components such as X, gdm, etc. they've held internally that should be held in the open to be a true part of OpenSolaris. They certainly should have, we don't need another devname. (http://www.opensolaris.org/os/project/devname). The only opensolaris.org project I know of that went back into Nevada without *any* content on opensolaris.org and with a single, spam, post on its list. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Recent putback of PSARC 2006/356 Reliable Datagram Sockets
Hi ! On Dec 20 the putback for PSARC 2006/356 Reliable Datagram Sockets 6433451 Solaris support for Reliable Datagram Sockets over Infiniband - RDS (2006/356) went into the ON. Among other things there were afew files carried over from OpenIB project. For example : usr/src/uts/common/io/ib/clients/rds/rdsib_buf.c 26 * Copyright (c) 2005 SilverStorm Technologies, Inc. All rights reserved. 27 * 28 * This software is available to you under a choice of one of two 29 * licenses. You may choose to be licensed under the terms of the GNU 30 * General Public License (GPL) Version 2, available from the file 31 * COPYING in the main directory of this source tree, or the 32 * OpenIB.org BSD license below: [BSD license text yanked] 57 /* 58 * Sun elects to include this software in Sun product 59 * under the OpenIB BSD license. That last sentence sounds a bit odd to me. While only Sun gets to decide what to include in Sun product, we are talking about OpenSolaris here. And it is not a Sun decision what license to choose. In this specific case I am sure the choice of license is obviously correct. In general, however, comments like that should not, IMHO, appear in the OpenSolaris code base. It is to be decided by community/CAB/OGB what license to use in OpenSolaris code base. So is it a sign of Sun isn't taking it [OpenSolaris] seriously, or a trivial ignorance of most of the Sun' developers ? -- Regards, Cyril ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Recent putback of PSARC 2006/356 Reliable Datagram Sockets
On Thu, Jan 04, 2007 at 08:27:41PM +0200, Cyril Plisko wrote: > 57 /* > 58 * Sun elects to include this software in Sun product > 59 * under the OpenIB BSD license. > > That last sentence sounds a bit odd to me. While only Sun gets > to decide what to include in Sun product, we are talking about > OpenSolaris here. And it is not a Sun decision what license to > choose. In this specific case I am sure the choice of license is > obviously correct. In general, however, comments like that should > not, IMHO, appear in the OpenSolaris code base. > It is to be decided by community/CAB/OGB what license to > use in OpenSolaris code base. > > So is it a sign of Sun isn't taking it [OpenSolaris] seriously, or > a trivial ignorance of most of the Sun' developers ? Hi Cyril, Nice catch :) I suppose this could be done one of two ways: 1) The committer makes the decision. (in this case, since the committer works for Sun and this is being done under Sun's "contributor agreement", the wording is "Sun elects to include..." as opposed to "Cyril Plisko elects to include..." if you had committed it) or 2) The OpenSolaris community/OGB/CAB makes the decision. I don't believe the OGB/CAB should make the decision, since they are governance boards - governing how the OpenSolaris community should be run, and this is a technical/legal issue, not a governance issue. The OpenSolaris community might be interesting; though it may be hard to find consensus. Possibly a smaller team (perhaps the project i-team) or something? Inevitably, some legal signoff is going to have to happen. Currently, with the sponsorship process, this is happening via the sponsor - but this is clearly going to have to be modified when we have an external open tree with external direct committers. cheers, steve -- stephen lau // [EMAIL PROTECTED] | 650.786.0845 | http://whacked.net opensolaris // solaris kernel development ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Recent putback of PSARC 2006/356 Reliable Datagram Sockets
Cyril Plisko wrote: Hi ! On Dec 20 the putback for PSARC 2006/356 Reliable Datagram Sockets 6433451 Solaris support for Reliable Datagram Sockets over Infiniband - RDS (2006/356) went into the ON. Among other things there were afew files carried over from OpenIB project. For example : usr/src/uts/common/io/ib/clients/rds/rdsib_buf.c 26 * Copyright (c) 2005 SilverStorm Technologies, Inc. All rights reserved. 27 * 28 * This software is available to you under a choice of one of two 29 * licenses. You may choose to be licensed under the terms of the GNU 30 * General Public License (GPL) Version 2, available from the file 31 * COPYING in the main directory of this source tree, or the 32 * OpenIB.org BSD license below: [BSD license text yanked] 57 /* 58 * Sun elects to include this software in Sun product 59 * under the OpenIB BSD license. That last sentence sounds a bit odd to me. While only Sun gets to decide what to include in Sun product, we are talking about OpenSolaris here. And it is not a Sun decision what license to choose. In this specific case I am sure the choice of license is obviously correct. In general, however, comments like that should not, IMHO, appear in the OpenSolaris code base. It is to be decided by community/CAB/OGB what license to use in OpenSolaris code base. So is it a sign of Sun isn't taking it [OpenSolaris] seriously, or a trivial ignorance of most of the Sun' developers ? I think this is a sign of Sun internal processes becoming transparent and of Sun developers having to serve two masters as we continue the transition to open development. When a Sun developer wants to use third-party open source, he/she must get approval to do so. That approval includes choosing a license when the third-party source is dual-licensed. That's what happened here. Third-party code was brought inside Sun and the engineering team followed the approval process. Part of that process included choosing to use it with the OpenIB license. There is a 'license.txt' file that includes the OpenIB license text; it will be putback shortly. It was inadvertently not included in the putback. And files licensed using an existing license should not have the CDDL added to them; third-party licenses pass through as-is. That will also be cleaned up. Regarding the general question of the OGB taking on decisions about license choice in similar situations, I believe there will need to be discussions about that as well as other related topics as part of fully implementing detailed development processes moving forward. Bonnie ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [EMAIL PROTECTED] project proposal __/__ WAS: Re: Re: Re: Is M
> Who else is interested? > Thoughts? > If this question were asked a year ago, I would have raised my both hands. But things have changed a lot. It took me a while to get used to not using the Moz suite, but now I don't even install Seamonkey in my Linux partitions. 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+. Third, and the most important IMO, Thunderbird/Lightening is now in the OpenOffice.org 2.0 roadmap. Unless someone can find a way to also do the same arrangement for Seamonkey, this is a temptation--though as great as it still sounds--that should be avoided. > p.s. The SUNWqemu packages are slightly delayed (due > to a spontanous > travel), but are in the works. > Literally and in this minute. > PLease expect them tomorrow evening or something. Will the accelerator be a part of the SUNWqemu packages? Thanks & Looking forward to it. > > -- > Martin Bochnig > > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Recent putback of PSARC 2006/356 Reliable Datagram Sockets
On 1/4/07, Stephen Lau <[EMAIL PROTECTED]> wrote: On Thu, Jan 04, 2007 at 08:27:41PM +0200, Cyril Plisko wrote: > 57 /* > 58 * Sun elects to include this software in Sun product > 59 * under the OpenIB BSD license. > > That last sentence sounds a bit odd to me. While only Sun gets > to decide what to include in Sun product, we are talking about > OpenSolaris here. And it is not a Sun decision what license to > choose. In this specific case I am sure the choice of license is > obviously correct. In general, however, comments like that should > not, IMHO, appear in the OpenSolaris code base. > It is to be decided by community/CAB/OGB what license to > use in OpenSolaris code base. > > So is it a sign of Sun isn't taking it [OpenSolaris] seriously, or > a trivial ignorance of most of the Sun' developers ? Hi Cyril, Nice catch :) I suppose this could be done one of two ways: 1) The committer makes the decision. (in this case, since the committer works for Sun and this is being done under Sun's "contributor agreement", the wording is "Sun elects to include..." as opposed to "Cyril Plisko elects to include..." if you had committed it) Hm, I actually was talking about the second part - the one that says "Sun product" - OpenSolaris is not a Sun product. That would be equal to "Cyril Plisko elects to include ... in his own product" wording appearing in the file. In which case I am sure that would be caught before crossing the bridge. In case some 3rd party code is licensed under two (or more) licenses, both of which are CDDL friendly, there might be potentially a conflict of interest between what is good for Sun product and what is good for OpenSolaris. -- Regards, Cyril ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [EMAIL PROTECTED] project proposal __/__ WAS: Re: Re: Re: Is M
W. Wayne Liauh wrote: >>If this question were asked a year ago, I would have raised my both hands. >>But things have changed a lot. It took me a while to get used to not using >>the Moz suite, but now I don't even install Seamonkey in my Linux partitions. >> >>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+. >> >> Aha, I didn't yet come to upgrading any box to b54. Sounds really interesting what I have heard about it so far (i.e. Studio compilers now included by default ??) However, the fact alone, that FF2.0 may indeed be a quantum leap over FF1.x (which I do appreciate) does not change much in terms of the conceptual design differences between FF(separate apps) <--> SeaMonkey(Monolithic Complete Suite). I understand, that SUNW has to decide and operate economically (in reagards of what should['nt] be included/maintained/shipped). I also see now, that www.opensolaris.org is certainly the wrong place for a total userland project such as SeaMonkey. My personal response is this: For now pkg-get CSWseamonkey. 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. >>Third, and the most important IMO, Thunderbird/Lightening is now in the >>OpenOffice.org 2.0 roadmap. Unless someone can find a way to also do the >>same arrangement for Seamonkey, this is a temptation--though as great as it >>still sounds--that should be avoided. >> >> >> >>p.s. The SUNWqemu packages are slightly delayed (due >>to a spontanous >>travel), but are in the works. >>Literally and in this minute. >>PLease expect them tomorrow evening or something. >> >> > >Will the accelerator be a part of the SUNWqemu packages? Thanks & Looking >forward to it. > > The existing kqemu wrapper module for i386 and x64 - ported and maintained by Eric Lowe - will continue to work on Nevada hosts (not properly on Solaris 10 / though I'm not sure about U3). So the answer is "yes". ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Recent putback of PSARC 2006/356 Reliable Datagram Sockets
Cyril Plisko wrote: On 1/4/07, Stephen Lau <[EMAIL PROTECTED]> wrote: On Thu, Jan 04, 2007 at 08:27:41PM +0200, Cyril Plisko wrote: > 57 /* > 58 * Sun elects to include this software in Sun product > 59 * under the OpenIB BSD license. > > That last sentence sounds a bit odd to me. While only Sun gets > to decide what to include in Sun product, we are talking about > OpenSolaris here. And it is not a Sun decision what license to > choose. In this specific case I am sure the choice of license is > obviously correct. In general, however, comments like that should > not, IMHO, appear in the OpenSolaris code base. > It is to be decided by community/CAB/OGB what license to > use in OpenSolaris code base. > > So is it a sign of Sun isn't taking it [OpenSolaris] seriously, or > a trivial ignorance of most of the Sun' developers ? Hi Cyril, Nice catch :) I suppose this could be done one of two ways: 1) The committer makes the decision. (in this case, since the committer works for Sun and this is being done under Sun's "contributor agreement", the wording is "Sun elects to include..." as opposed to "Cyril Plisko elects to include..." if you had committed it) Hm, I actually was talking about the second part - the one that says "Sun product" - OpenSolaris is not a Sun product. True, but I'd expect that to be a 'form letter' kind of statement. Or from another point of view, this is a good thing, since *Sun* may have chosen that, but you, Cyril, can opt otherwise. (If it'd said "OpenSolaris", I'd have been annoyed in the same way Steve read your initial mail, since that'd be, from my point of view, overstepping things). That would be equal to "Cyril Plisko elects to include ... in his own product" wording appearing in the file. In which case I am sure that would be caught before crossing the bridge. In general, I don't think it's particularly necessary to comment it in the source at all, but I ignore legal matters in the hope they ignore me, so... -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [EMAIL PROTECTED] project proposal __/__ WAS: Re: Re: Re: Is M
Martin Bochnig wrote: >W. Wayne Liauh wrote: > > > >>> >>>p.s. The SUNWqemu packages are slightly delayed (due >>>to a spontanous >>>travel), but are in the works. >>>Literally and in this minute. >>>PLease expect them tomorrow evening or something. >>> >>> >>> >>> >>Will the accelerator be a part of the SUNWqemu packages? Thanks & Looking >>forward to it. >> >> >> >> > >The existing kqemu wrapper module for i386 and x64 - ported and >maintained by Eric Lowe - will continue to work on Nevada hosts (not >properly on Solaris 10 / though I'm not sure about U3). >So the answer is "yes". > > The kqemu module itself is IP of Fabrice Bellard. Not sure if I can integrate it into the pkgs, probably NOT. The wrapper module will continue to be available on http://opensolaris.org/os/project/qemu/downloads/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Recent putback of PSARC 2006/356 Reliable Datagram Sockets
Given a limited menu of just those two choices, and the use of the CDDL for the rest of OpenSolaris, the choice was obvious: BSD is compatible with CDDL, GPLv2 isn't. Under those conditions, who made the decision seems to me to be little more than PR. I don't know the history of the porting work for this particular putback. But if it was something that Sun did internally and then "threw over the wall", then I don't see why it shouldn't be their choice (and perhaps even would have to be their responsibility) rather than that of some OpenSolaris related body (esp. since the latter may not have a bunch of its own lawyers, and may or may not even be presently equipped or allowed to make that sort of decision, let alone reasonably quickly). The added copyright notice (presumably for what was unique to the [Open]Solaris port) was Sun's, not that of Joe (or Jill) Contributor. To my way of thinking, that's yet another reason why it was legitimate for it to be Sun's decision which license to use. Had the work been done by an outside contributor, it would have been their decision (rather than the CAB/OGB/whatever). As far as I can see, only if the copyright was assigned to some OpenSolaris related entity (not unlike how the FSF likes to have copyright assigned to it for GPL code meant to be regarded as part of the GNU project) would such choices be up to that entity. The FSF is a non-profit corporation; AFAIK, neither the OGB nor anything else with a uniquely OpenSolaris but not Sun identity is an actual legal entity, able to hold copyrights (and thus choose licenses). Further, the OpenSolaris charter (http://www.opensolaris.org/os/community/cab/charter.pdf) (which is _not_ superceded by the upcoming OpenSolaris Constitution) says in part: However, nothing in this charter shall be construed so as to confer to the OGB: (a) any title or right under copyright, patent, trademark, or other intellectual property law; (b) control of or interest in any asset, tangible or intangible, of Sun Microsystems, Inc. or any of its subsidiaries; (c) control of or interest in Sun Microsystems, Inc. or any of its subsidiaries. So while I recognize the sensitivities you're alluding to, I don't see that there's any way that anything other than what was done could have been done. IANAL, of course. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Recent putback of PSARC 2006/356 Reliable Datagram Sockets
On 1/4/07, Richard L. Hamilton <[EMAIL PROTECTED]> wrote: IANAL, of course. So am I, and since the discussion rapidly shifts to law sphere (I should saw it coming before I started !) I'd better stop here. -- Regards, Cyril ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] bug or change of semantics?
Hi, I observed the following behavior concerning the readability of directory content that I don't understand. This occurred on both Solaris releases with UFS filesystems. [EMAIL PROTECTED]:/var/a$ uname -a SunOS azalin 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Blade-2500 [EMAIL PROTECTED]:/var/a$ id uid=1000(thomas) gid=1000(thomas) [EMAIL PROTECTED]:/var/a$ ls -ld chris drwx--2 chrischris 512 Jan 4 21:04 chris/ [EMAIL PROTECTED]:/var/a$ ls -l chris ls: chris/a: Permission denied total 0 [EMAIL PROTECTED]:/var/tmp$ uname -a SunOS grima 5.8 Generic_117350-43 sun4u sparc SUNW,Ultra-60 [EMAIL PROTECTED]:/var/tmp$ id uid=1000(thomas) gid=1000(thomas) [EMAIL PROTECTED]:/var/tmp$ ls -ld chris drwx--2 chrischris 512 Jan 4 20:51 chris/ [EMAIL PROTECTED]:/var/tmp$ ls -l chris ls: chris: Permission denied As you can see, ls lists the name of files within the directory which is neither readable nor executable by the user calling ls... Can anybody explain this change in behavior? TIA, Tom This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] bug or change of semantics?
>Hi, > >I observed the following behavior concerning the readability of directory >content that I don't und erstand. This occurred on both Solaris releases with UFS filesystems. > >[EMAIL PROTECTED]:/var/a$ uname -a >SunOS azalin 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Blade-2500 >[EMAIL PROTECTED]:/var/a$ id >uid=1000(thomas) gid=1000(thomas) >[EMAIL PROTECTED]:/var/a$ ls -ld chris >drwx--2 chrischris 512 Jan 4 21:04 chris/ >[EMAIL PROTECTED]:/var/a$ ls -l chris >ls: chris/a: Permission denied >total 0 > >[EMAIL PROTECTED]:/var/tmp$ uname -a >SunOS grima 5.8 Generic_117350-43 sun4u sparc SUNW,Ultra-60 >[EMAIL PROTECTED]:/var/tmp$ id >uid=1000(thomas) gid=1000(thomas) >[EMAIL PROTECTED]:/var/tmp$ ls -ld chris >drwx--2 chrischris 512 Jan 4 20:51 chris/ >[EMAIL PROTECTED]:/var/tmp$ ls -l chris >ls: chris: Permission denied > >As you can see, ls lists the name of files within the directory which is >neither readable nor exec utable by the user calling ls... > >Can anybody explain this change in behavior? There is no such change in behaviour (none that I can reproduce). What does "ppriv $$" say in the first case? Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Recent putback of PSARC 2006/356 Reliable DatagramSockets
Cyril Plisko wrote: [snip] > 26 * Copyright (c) 2005 SilverStorm Technologies, Inc. All rights reserved. > 27 * > 28 * This software is available to you under a choice of one of two > 29 * licenses. You may choose to be licensed under the terms of the GNU > 30 * General Public License (GPL) Version 2, available from the file > 31 * COPYING in the main directory of this source tree, or the > 32 * OpenIB.org BSD license below: > > [BSD license text yanked] > > 57 /* > 58 * Sun elects to include this software in Sun product > 59 * under the OpenIB BSD license. [snip] > So is it a sign of Sun isn't taking it [OpenSolaris] seriously, or > a trivial ignorance of most of the Sun' developers ? I guess the project and/or this choice predates OpenSolaris.org or the engineers were not aware that someone may want to see their head(s) on a stick in front of the building for this choice... :-) Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
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 ? Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] bug or change of semantics?
[EMAIL PROTECTED] wrote: >> Hi, >> >> I observed the following behavior concerning the readability of directory >> content that I don't und > erstand. This occurred on both Solaris releases with UFS filesystems. >> [EMAIL PROTECTED]:/var/a$ uname -a >> SunOS azalin 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Blade-2500 >> [EMAIL PROTECTED]:/var/a$ id >> uid=1000(thomas) gid=1000(thomas) >> [EMAIL PROTECTED]:/var/a$ ls -ld chris >> drwx--2 chrischris 512 Jan 4 21:04 chris/ >> [EMAIL PROTECTED]:/var/a$ ls -l chris >> ls: chris/a: Permission denied >> total 0 >> >> [EMAIL PROTECTED]:/var/tmp$ uname -a >> SunOS grima 5.8 Generic_117350-43 sun4u sparc SUNW,Ultra-60 >> [EMAIL PROTECTED]:/var/tmp$ id >> uid=1000(thomas) gid=1000(thomas) >> [EMAIL PROTECTED]:/var/tmp$ ls -ld chris >> drwx--2 chrischris 512 Jan 4 20:51 chris/ >> [EMAIL PROTECTED]:/var/tmp$ ls -l chris >> ls: chris: Permission denied >> >> As you can see, ls lists the name of files within the directory which is >> neither readable nor exec > utable by the user calling ls... >> Can anybody explain this change in behavior? > > There is no such change in behaviour (none that I can reproduce). > > What does "ppriv $$" say in the first case? > > Casper > You got it. I totally forgot about /etc/user_attr and file_dac_read... Thanks. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Obtaining nameservice-independent "user_attr" and "publickey" data from a shell script ?
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") ? Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix 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" 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") ? > > Maybe getuserattr() or getauthattr() ? nameservice-independence is probably done via nsswitch.conf, but not sure through which entry. 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: >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") ? >> >> >> >> > >Maybe getuserattr() or getauthattr() ? > >nameservice-independence is probably done via nsswitch.conf, but not >sure through which entry. > > Ignore the latter, time to go sleep. ___ 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: >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") ? >> >> >> >> > >Maybe getuserattr() or getauthattr() ? > > Plus getpublickey() Or don't those work with "files" as NS ?? *shrug* ___ 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: > Martin Bochnig 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") ? > > > >Maybe getuserattr() or getauthattr() ? > > Plus getpublickey() > > Or don't those work with "files" as NS ?? The problem is to make these items accessible to the shell (and not binary code). The "publickey" was very annoying since it forced me to create horrible stunts in our script which switches the X11 authentification from MIT-MAGIC-COOKIE-1 to SUN-DES-1 (the hacks will case blindness at the moment you're looking at them). Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix 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" and "publickey" data from a shell script ?
Martin Bochnig wrote: >Martin Bochnig wrote: > > >>>Maybe getuserattr() or getauthattr() ? >>> >>> >>> >>> > >Plus getpublickey() > >Or don't those work with "files" as NS ?? > >*shrug* > Exclusively from a shell script, no C? Can't you analyse the files in /etc directly then? Which other tools can be expected to be present Under which user or role will the script run (root) ? ___ 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: > Martin Bochnig wrote: > >Martin Bochnig wrote: > >>>Maybe getuserattr() or getauthattr() ? > > > >Plus getpublickey() > > > >Or don't those work with "files" as NS ?? > > > >*shrug* > > Exclusively from a shell script, no C? Yes... > Can't you analyse the files in /etc directly then? No, because in the case that the matching entries in /etc/nsswitch.conf contain more than "files" you need nameservice-specific calls, one for YP, one for NIS, one for NIS+, one for LDAP etc. - and you would have to care about the lookup order and fallback behaviour if a nameservice is down etc. etc. ... ... that's why I was thinking to extend /usr/bin/getent to include these items if they are not available via other ways. > Which other tools can be expected to be present Just the shell... > Under which user or role will the script run (root) ? It should work with any user... Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Community leads: final reminder on contributors/core contributors
If you're a community lead, and you (or your fellow leads) have not replied to my inquiries regarding a list of contributors and core contributors, please take this last chance to read my messages sent in November 2005 and June 2005 and submit an initial list. Interim lists were published in June 2005 http://www.opensolaris.org/jive/thread.jspa?threadID=10448&tstart=0 and just today http://www.opensolaris.org/jive/thread.jspa?threadID=21272&tstart=0 Thanks Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ 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: > >>Exclusively from a shell script, no C? >> >> > >Yes... > > > >>Can't you analyse the files in /etc directly then? >> >> > >No, because in the case that the matching entries in /etc/nsswitch.conf >contain more than "files" you need nameservice-specific calls, one for > > I finally get your question. >YP, one for NIS, > I thought YP (yellow pages) and NIS were the same (or that NIS was derived from YP) ? > one for NIS+, one for LDAP etc. - and you would have to > > ok ok, clear now. >care about the lookup order and fallback behaviour if a nameservice is >down etc. etc. ... > > yes, I begin to remember my exam prep 2 years ago ... (Network and Security Exams) >... that's why I was thinking to extend /usr/bin/getent > I just reread the man page. >to include these >items if they are not available via other ways. > > > >>Which other tools can be expected to be present >> >> > >Just the shell... > > Weren't there commands (specific for each NS) returning those values? > > >>Under which user or role will the script run (root) ? >> >> > >It should work with any user... > > "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? -Martin ___ 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: >No, because in the case that the matching entries in /etc/nsswitch.conf >contain more than "files" you need nameservice-specific calls, one for >YP, one for NIS, one for NIS+, one for LDAP etc. - and you would have to >care about the lookup order and fallback behaviour if a nameservice is >down etc. etc. ... >... that's why I was thinking to extend /usr/bin/getent to include these >items if they are not available via other ways. > > I still don't understand your original question: >> Is there a nameservice-independent way to obtain the values for >> "user_attr" and "publickey" from a shell script > I got - and still get - confused by what you mean with "nameservice-independent way". You agreed (above), that nsswitch.conf is parsed and processed (in the well defined order, from left to right). 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 ;-) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: What's the status of virtual consoles?
One more thing that should be discussed is mouse support ala Linux/BSD's gpm Now one thing that would totally rock is the ability to cut from a VC and paste in an Xterm - Linux/BSD don't support this functionality. best regards Dev Mazumdar This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Debug the Dynamic Linker
I am working with Dynamic Linker of Solaris (rtld forlder). I have made some changes in the Dynamic linker and build with debug option. Now I want to debug my dynamic linker. Can anyone please suggest how to proceed ? How do I tell the OS to invoke my dynamic linker instead of the original one. Thanks Deepak Bhatia This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[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. It there any patch available for the same ? Thanks Deepak Bhatia This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
