Re: [zones-discuss] s10 brand Phase I webrev
Ed, Thanks for reviewing this again. I took most of your input. For the questions you had or the things I didn't take, I have responded below. Edward Pilatowicz wrote: - could you propegate back your common changes to the original file? I don't want to complicate this project with the additional changes to the sn1 brand and the corresponding additional testing. I filed bug: 6888642 sn1 brand cleanup so that we can track that work as a separate integration. - there is duplicated code here from the pkg(5) brand common.ksh. perhaps the common code should go in /usr/lib/brand/shared/common.ksh? fail_fatal() get_zonepath_ds() get_active_ds() get_zonepath_ds() is not common since the ipkg brand has the additional dependency on the global zone BE which does not exist for the solaris10 brand. - in create_active_ds(), newly created datasets will have different values from pre-existing datasets. new datasets will inherit the mountpoint and zoned properties while existing datasets will have these explicitly set. (if your worried about these having incorrect values for existing datasets, perhaps you should re-inherit them instead of setting them.) We don't want to inherit these, we want to set them. The values will change as the zone gets detached/attached so we always want to set the values we need. - in sysunconfig_zone(), the comment says it sleeps 10 seconds, but then it does 10 iterations of a loop with sleep 10 in it. i feel like i've made this exact same code review comment to you recently. is this code duplicated from the ipkg p2v code? No, it came from the native p2v, just as the ipkg code did. I made the fix here that I also made for the ipkg work. - in sysunconfig_zone(), if the zone never gets to single-user mode then should we return 1 instead of charging ahead and trying to run sys-unconfig? (since in that case sys-unconfig could hang.) I think its worth trying anyway since there may be something else going on and we don't know for sure if sys-unconfig will hang. -- usr/src/lib/brand/solaris10/s10_support/s10_support.c - get_image_emul_version(), doesn't this essentially duplicate the functionality provided by the /usr/lib/brand/solaris10/version file delivered via s10? in both cases we're deriving an emulation version based on the s10 bits within the zone. could you explain why this is necessary and under what conditions each versioning mechanism will be used? I changed this so that we still check for the minimum KU and we now use the optional version file from S10 to determine if we need a specific version of the emulation. - get_image_emul_version(), does an == comparison on the KU. that means whenever a new KU is release, we'll need to update this code. does that mean you forsee verification test runs for each s10 KU, and a subsequent update to this code once the tests complete? if so please add comments to the code explaning this. No, thats incorrect. A new KU will always incorporate the old KU. For example, if you were running the S10u6 KU and then installed the S10u9 KU, your system would then look like it had the u6, u7, u8 and u9 KUs installed. -- usr/src/lib/brand/solaris10/zone/attach.ksh - you have the following comment: # # Try to create a zfs dataset for the zonepath (this is automatically # done by zoneadm for the install subcommand but not for attach). # why not change zoneadm attach to be consistent with install and create these dataset when possible. (seems like that would benifit the ipkg brand as well.) I filed the following bug for that enhancement but I don't want to make that part of this project. 6888652 zoneadm attach should try to create a zfs dataset -- usr/src/lib/brand/solaris10/s10_brand/common/s10_brand.c - since the zc_name, zc_value, and zc_string are all arrays embedded within the zfs_cmd_t, there is no reason to use uucopy to access them individually. Yes, since these are embedded arrays, they must be copied, we can't simply do an assignment. I did change the uucopy to bcopy so that I didn't have to do the cast. - in s10_zone, in the ZONE_GETATTR() case, why isn't S10_TRUSS_POINT_5 used instead of S10_TRUSS_POINT_3? Because the first 3 parameters are required for a truss point. That is, S10_TRUSS_POINT_0 takes 3 parameters, S10_TRUSS_POINT_3 takes 6, which is the number of parameters we're passing. Thanks again, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
Jordan, Thanks for reviewing this again. I took most of your input. For the things I didn't take, I have responded below. Jordan Vaughan wrote: usr/src/uts/common/brand/solaris10/s10_brand.c 1260-1261,1286-1287,1313,etc.: Couldn't we make arg1 a zoneid_t, arg2 an int, arg3 a char *, and arg4 a size_t and eliminate some of the casts in s10_zone() (as well as some of the automatic variables, e.g., buf and bufsize)? Since thats not always the types of the parameters passed, I don't want to change this since it would complicate any work we might do in the future. -- usr/src/lib/brand/solaris10/s10_support/s10_support.c get_image_emul_version(): I agree with Ed that get_image_emul_version() is superfluous. Now that I've thought about it, $ZONEROOT/usr/lib/brand/solaris10/version should be sufficient for the brand to determine whether it can host the associated S10C. All we need to do is hard-code the maximum version number supported by the brand (for example, as a preprocessor constant), fetch the version number stored in $ZONEROOT/usr/lib/brand/solaris10/version (or zero if the file does not exist), check whether the latter exceeds the former, and set the brand's emulation number to that stored in $ZONEROOT/usr/lib/brand/solaris10/version. See my response to Ed on what I did here. The check for the minimal KU is not superfluous, but I did rewrite this as I explained to Ed. Thanks again, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
On Tue, Oct 06, 2009 at 09:47:40AM -0600, Jerry Jelinek wrote: > Ed, > > Thanks for reviewing this again. I took most of your > input. For the questions you had or the things I > didn't take, I have responded below. > > Edward Pilatowicz wrote: >> - could you propegate back your common changes to the original file? > > I don't want to complicate this project with the additional > changes to the sn1 brand and the corresponding additional testing. > I filed bug: > > 6888642 sn1 brand cleanup > > so that we can track that work as a separate integration. > sigh. are you commiting to this work? the sn1 brand always get's neglected (says the guy who spent too much time fixing it up to be a real brand). also, i would have though you'd commited to doing this work when you decided to fork the sn1 brand code instead of making it common. besides, aside from the elfexec changes all the changes are Makefile related, right? that's not a whole lot of extra testing. >> - there is duplicated code here from the pkg(5) brand common.ksh. perhaps >> the common code should go in /usr/lib/brand/shared/common.ksh? >> fail_fatal() >> get_zonepath_ds() >> get_active_ds() > > get_zonepath_ds() is not common since the ipkg brand has the additional > dependency on the global zone BE which does not exist for the solaris10 > brand. > ok. but if get_zonepath_ds() is not common, then why are you adding it to usr/src/lib/brand/native/zone/common.ksh? >> - in create_active_ds(), newly created datasets will have different >> values from pre-existing datasets. new datasets will inherit the >> mountpoint and zoned properties while existing datasets will have >> these explicitly set. (if your worried about these having incorrect >> values for existing datasets, perhaps you should re-inherit them >> instead of setting them.) > > We don't want to inherit these, we want to set them. The values will > change as the zone gets detached/attached so we always want to set > the values we need. > i dont' understand, currently we don't always set these values. if we do a fresh install, "mountpoint" and "zoned" are inherited: ---8<--- e...@mcescher$ zfs get -o source mountpoint,zoned export/zones/z1/ROOT/zbe SOURCE inherited from export/zones/z1/ROOT inherited from export/zones/z1/ROOT ---8<--- so why the difference for attached zones? for attached zones you "zfs set" the values above. why not just "zfs inherit" instead. (you already explicitly set them for the ROOT dataset, so they would be correct.) >> - in sysunconfig_zone(), if the zone never gets to single-user mode then >> should we return 1 instead of charging ahead and trying to run >> sys-unconfig? (since in that case sys-unconfig could hang.) > > I think its worth trying anyway since there may be something else > going on and we don't know for sure if sys-unconfig will hang. > could you add comments explaining this? >> -- >> usr/src/lib/brand/solaris10/s10_support/s10_support.c > >> - get_image_emul_version(), does an == comparison on the KU. that means >> whenever a new KU is release, we'll need to update this code. does >> that mean you forsee verification test runs for each s10 KU, and a >> subsequent update to this code once the tests complete? if so please >> add comments to the code explaning this. > > No, thats incorrect. A new KU will always incorporate the old KU. > For example, if you were running the S10u6 KU and then installed > the S10u9 KU, your system would then look like it had the u6, u7, > u8 and u9 KUs installed. > please add comments explaining this. >> -- >> usr/src/lib/brand/solaris10/s10_brand/common/s10_brand.c >> >> - in s10_zone, in the ZONE_GETATTR() case, why isn't S10_TRUSS_POINT_5 >> used instead of S10_TRUSS_POINT_3? > > Because the first 3 parameters are required for a truss point. That is, > S10_TRUSS_POINT_0 takes 3 parameters, S10_TRUSS_POINT_3 takes 6, which > is the number of parameters we're passing. > but i thought the caller passed in 4 parameters. (in addition to the cmd.) why are you not printing out "buf" and "bufsize"? ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
> also, i would have though you'd commited to doing this work when you > decided to fork the sn1 brand code instead of making it common. I was wondering about this too. Indeed, there seems be a sizeable amount of duplicated code now. Why is this the right design? -- meem ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
Ed, Edward Pilatowicz wrote: On Tue, Oct 06, 2009 at 09:47:40AM -0600, Jerry Jelinek wrote: Ed, Thanks for reviewing this again. I took most of your input. For the questions you had or the things I didn't take, I have responded below. Edward Pilatowicz wrote: - could you propegate back your common changes to the original file? I don't want to complicate this project with the additional changes to the sn1 brand and the corresponding additional testing. I filed bug: 6888642 sn1 brand cleanup so that we can track that work as a separate integration. sigh. are you commiting to this work? the sn1 brand always get's neglected (says the guy who spent too much time fixing it up to be a real brand). Sure. I just don't want these coupled together. also, i would have though you'd commited to doing this work when you decided to fork the sn1 brand code instead of making it common. besides, aside from the elfexec changes all the changes are Makefile related, right? that's not a whole lot of extra testing. - there is duplicated code here from the pkg(5) brand common.ksh. perhaps the common code should go in /usr/lib/brand/shared/common.ksh? fail_fatal() get_zonepath_ds() get_active_ds() get_zonepath_ds() is not common since the ipkg brand has the additional dependency on the global zone BE which does not exist for the solaris10 brand. ok. but if get_zonepath_ds() is not common, then why are you adding it to usr/src/lib/brand/native/zone/common.ksh? Sorry, I meant get_active_ds(), not get_zonepath_ds(). - in create_active_ds(), newly created datasets will have different values from pre-existing datasets. new datasets will inherit the mountpoint and zoned properties while existing datasets will have these explicitly set. (if your worried about these having incorrect values for existing datasets, perhaps you should re-inherit them instead of setting them.) We don't want to inherit these, we want to set them. The values will change as the zone gets detached/attached so we always want to set the values we need. i dont' understand, currently we don't always set these values. if we do a fresh install, "mountpoint" and "zoned" are inherited: ---8<--- e...@mcescher$ zfs get -o source mountpoint,zoned export/zones/z1/ROOT/zbe SOURCE inherited from export/zones/z1/ROOT inherited from export/zones/z1/ROOT ---8<--- so why the difference for attached zones? for attached zones you "zfs set" the values above. why not just "zfs inherit" instead. (you already explicitly set them for the ROOT dataset, so they would be correct.) OK, I misunderstood what you meant. I'll change this. - in sysunconfig_zone(), if the zone never gets to single-user mode then should we return 1 instead of charging ahead and trying to run sys-unconfig? (since in that case sys-unconfig could hang.) I think its worth trying anyway since there may be something else going on and we don't know for sure if sys-unconfig will hang. could you add comments explaining this? Sure. -- usr/src/lib/brand/solaris10/s10_support/s10_support.c - get_image_emul_version(), does an == comparison on the KU. that means whenever a new KU is release, we'll need to update this code. does that mean you forsee verification test runs for each s10 KU, and a subsequent update to this code once the tests complete? if so please add comments to the code explaning this. No, thats incorrect. A new KU will always incorporate the old KU. For example, if you were running the S10u6 KU and then installed the S10u9 KU, your system would then look like it had the u6, u7, u8 and u9 KUs installed. please add comments explaining this. Sure. -- usr/src/lib/brand/solaris10/s10_brand/common/s10_brand.c - in s10_zone, in the ZONE_GETATTR() case, why isn't S10_TRUSS_POINT_5 used instead of S10_TRUSS_POINT_3? Because the first 3 parameters are required for a truss point. That is, S10_TRUSS_POINT_0 takes 3 parameters, S10_TRUSS_POINT_3 takes 6, which is the number of parameters we're passing. but i thought the caller passed in 4 parameters. (in addition to the cmd.) why are you not printing out "buf" and "bufsize"? Those parameters aren't that useful for debugging. I can add them if you'd like. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
Peter Memishian wrote: > also, i would have though you'd commited to doing this work when you > decided to fork the sn1 brand code instead of making it common. I was wondering about this too. Indeed, there seems be a sizeable amount of duplicated code now. Why is this the right design? Because the sn1 brand is an internal brand for testing and is not delivered to customers. Once the solaris10 brand is integrated, the sn1 brand will no longer serve its original role and could even be removed from the source tree if we wanted to. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
On Tue, Oct 06, 2009 at 12:15:23PM -0600, Jerry Jelinek wrote: > Ed, > > Edward Pilatowicz wrote: >> On Tue, Oct 06, 2009 at 09:47:40AM -0600, Jerry Jelinek wrote: >>> Ed, >>> >>> Thanks for reviewing this again. I took most of your >>> input. For the questions you had or the things I >>> didn't take, I have responded below. >>> >>> Edward Pilatowicz wrote: - could you propegate back your common changes to the original file? >>> I don't want to complicate this project with the additional >>> changes to the sn1 brand and the corresponding additional testing. >>> I filed bug: >>> >>> 6888642 sn1 brand cleanup >>> >>> so that we can track that work as a separate integration. >>> >> >> sigh. are you commiting to this work? the sn1 brand always get's >> neglected (says the guy who spent too much time fixing it up to be a >> real brand). > > Sure. I just don't want these coupled together. > then please make sure to update the bug with a detailed list of all the differences between the two. (should be easy since i already hilighted all the differences in my code review comments.) -- usr/src/lib/brand/solaris10/s10_brand/common/s10_brand.c - in s10_zone, in the ZONE_GETATTR() case, why isn't S10_TRUSS_POINT_5 used instead of S10_TRUSS_POINT_3? >>> Because the first 3 parameters are required for a truss point. That is, >>> S10_TRUSS_POINT_0 takes 3 parameters, S10_TRUSS_POINT_3 takes 6, which >>> is the number of parameters we're passing. >>> >> >> but i thought the caller passed in 4 parameters. (in addition to the >> cmd.) why are you not printing out "buf" and "bufsize"? > > Those parameters aren't that useful for debugging. I can add them > if you'd like. > yes please. otherwise some anal retentive person who is debugging a problem will get distracted by the fact that the buf pointer and size values are invalid. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
Ed, Edward Pilatowicz wrote: On Tue, Oct 06, 2009 at 12:15:23PM -0600, Jerry Jelinek wrote: Ed, Edward Pilatowicz wrote: On Tue, Oct 06, 2009 at 09:47:40AM -0600, Jerry Jelinek wrote: Ed, Thanks for reviewing this again. I took most of your input. For the questions you had or the things I didn't take, I have responded below. Edward Pilatowicz wrote: - could you propegate back your common changes to the original file? I don't want to complicate this project with the additional changes to the sn1 brand and the corresponding additional testing. I filed bug: 6888642 sn1 brand cleanup so that we can track that work as a separate integration. sigh. are you commiting to this work? the sn1 brand always get's neglected (says the guy who spent too much time fixing it up to be a real brand). Sure. I just don't want these coupled together. then please make sure to update the bug with a detailed list of all the differences between the two. (should be easy since i already hilighted all the differences in my code review comments.) Sure. I used the file list from your comments but I'll go ahead and paste all of them in. -- usr/src/lib/brand/solaris10/s10_brand/common/s10_brand.c - in s10_zone, in the ZONE_GETATTR() case, why isn't S10_TRUSS_POINT_5 used instead of S10_TRUSS_POINT_3? Because the first 3 parameters are required for a truss point. That is, S10_TRUSS_POINT_0 takes 3 parameters, S10_TRUSS_POINT_3 takes 6, which is the number of parameters we're passing. but i thought the caller passed in 4 parameters. (in addition to the cmd.) why are you not printing out "buf" and "bufsize"? Those parameters aren't that useful for debugging. I can add them if you'd like. yes please. otherwise some anal retentive person who is debugging a problem will get distracted by the fact that the buf pointer and size values are invalid. Will do. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
> > I was wondering about this too. Indeed, there seems be a sizeable amount > > of duplicated code now. Why is this the right design? > > Because the sn1 brand is an internal brand for testing > and is not delivered to customers. Once the solaris10 > brand is integrated, the sn1 brand will no longer serve > its original role and could even be removed from the source > tree if we wanted to. I don't see how that addresses the primary point, which is that Solaris brands seem to suffer from code duplication. Are you asserting that the amount of code duplication between the sn1 and solaris10 brands is unique to that situation and is not something that will occur again when we cons up the next solarisX brand? -- meem ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
On Tue, Oct 06, 2009 at 12:18:21PM -0600, Jerry Jelinek wrote: > Peter Memishian wrote: >> > also, i would have though you'd commited to doing this work when you >> > decided to fork the sn1 brand code instead of making it common. >> >> I was wondering about this too. Indeed, there seems be a sizeable amount >> of duplicated code now. Why is this the right design? > > Because the sn1 brand is an internal brand for testing > and is not delivered to customers. Once the solaris10 > brand is integrated, the sn1 brand will no longer serve > its original role and could even be removed from the source > tree if we wanted to. > really? i'd have to disagree. i was actually expecting that when nevada dies we'd have to update the sn1 brand to work on opensolaris. i always thought you forked the code because that was faster than re-factoring it to be common. the sn1 brand is still the ideal method for testing the brandz framework itself. using the s10 brand to test the brandz framework is ok, but then you're also testing the s10 emulation layer, and that emulation is far from complete. (witness all the currently unsupported s10 functionality.) as an example, take a look at todds current bug. from todds (a developers) perspective, i think it'd be much better to reproduce the problem, debug it, fix it, and test it on the sn1 brand than on the s10 brand. the sn1 brand makes brandz framework development and regression testing easier for developers. (it's actually a bug, and a dis-service to ourselves, that we never integrated it into our automated zones testing.) the fact that the sn1 code is also for the most part duplicated in the s8 and s9 brands is also lousy. hopefully no one ever makes a successfull business case for porting those to opensolaris. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
Peter Memishian wrote: > > I was wondering about this too. Indeed, there seems be a sizeable amount > > of duplicated code now. Why is this the right design? > > Because the sn1 brand is an internal brand for testing > and is not delivered to customers. Once the solaris10 > brand is integrated, the sn1 brand will no longer serve > its original role and could even be removed from the source > tree if we wanted to. I don't see how that addresses the primary point, which is that Solaris brands seem to suffer from code duplication. Are you asserting that the amount of code duplication between the sn1 and solaris10 brands is unique to that situation and is not something that will occur again when we cons up the next solarisX brand? Yes. If we were to ship another brand that was fundamentally similar to the solaris10 brand (e.g. the solaris9 brand on Solaris Next), then I think it would make sense for that project to try to make more of the code common with the then currently shipping solaris10 brand. However, I don't think that is necessary for a brand we don't ship (but I can also understand if you don't agree with me). Once the solaris10 brand is integrated, I would hope that we would focus our limited resources on the one brand we do ship across all architectures and I would anticipate that the sn1 brand will be of limited usefulness (since its main reason for existence is to test brandz on sparc). If we do anything else with sn1 after this brand integrates is outside the scope of this project and not something we've even discussed (other than my commitment to fix the sn1 brand per Ed's code review comments). Of course, its up to future brand projects to evaluate what makes the most sense for their project and I can't commit those hypothetical projects to anything. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
Ed, Edward Pilatowicz wrote: really? i'd have to disagree. i was actually expecting that when nevada dies we'd have to update the sn1 brand to work on opensolaris. i always thought you forked the code because that was faster than re-factoring it to be common. No, that wasn't my thinking, but as I said, we've never discussed the future of the sn1 brand. If we think this is an important issue, we can look at it. From looking at the webrev, I see maybe 11 source files (not counting makefiles, pkging files or configuration files) that might be candidates for commonality (i.e. files with <10% lines of difference). This doesn't seem like a burning issue to me. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
> > I don't see how that addresses the primary point, which is that Solaris > > brands seem to suffer from code duplication. Are you asserting that the > > amount of code duplication between the sn1 and solaris10 brands is unique > > to that situation and is not something that will occur again when we cons > > up the next solarisX brand? > > Yes. If we were to ship another brand that was > fundamentally similar to the solaris10 brand (e.g. the solaris9 > brand on Solaris Next), then I think it would make sense for > that project to try to make more of the code common with the > then currently shipping solaris10 brand. However, I don't think > that is necessary for a brand we don't ship (but I can also > understand if you don't agree with me). Indeed, I don't agree, for three reasons: 1. You are establishing a precedent that the way we develop new Solaris brands is via cut-and-paste in a manner that's expedient for the implementor. When the next brand comes along, this existing example will likely be used as justification for why they should not be "burdened" with the task of properly factoring the software. 2. Shipping or not, the sn1 codebase is still part of our product and needs to be maintained. By forking the source, we are doubling the cost of that maintenance and making it easy for things to get out of sync (and indeed, the tax of maintaining these parallel brands has already started to be levied before the solaris10 brand has even integrated). We've all seen this many times but yet we keep doing it. 3. It is precisely because of our limited resources that we must adhere to best practices and commonize code rather than fork it. All that said, ultimately this is an issue for you and the rest of the zones team to resolve, so I'll bow out of this, but I strongly disagree with the approach that's been taken. -- meem ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] svnserve
If it does not come with a manifest for SMF you need to write one. If
it does then use it! or just use an rc script. However using the rc
scrpt ans making a service run under SMF is not hard. Attached is what
I wrote as a demo before postgress got an SMF service by default.
Look at "demo 2" in the self running ksh script where I demo my newly
created service.
The Defiant wrote:
Hi All,
Another newbie question. I've just configured a seprate contaniner to serve as a seprate svn repository and configured svnserve as the default svn server. Everything works fine, except svnserve wont autostart after rebooting ;(
Can someone point me to adding svnserve to autostart. I guess we would be using SMF service and not the autostart.sh
Thx in advance!
www.eagle.co.nz
This email is confidential and may be legally
privileged. If received in error please destroy and immediately notify
us.
#!/usr/bin/ksh
#
#
#Note: The presentation is:-
#
#http://webhome.singapore/trevor/Standard_Pressos/Solaris10_Demos/Sol10_demo_Overview/Solaris10_demo_SMF_CONTAINERS_ZFS.odp
#
#
#
# NOTE: This one use apache22 the older version use apache2
#
#http://webhome.singapore/trevor/Standard_Pressos/Solaris10_Demos/Sol10_demo_Overview/smf_demo_self_running.ksh_apache2
#
#
#--Setup---
#
#get the two files you need:-
#
#http://webhome.singapore/trevor/Standard_Pressos/Solaris10_Demos/Sol10_demo_Overview/pgsql
#http://webhome.singapore/trevor/Standard_Pressos/Solaris10_Demos/Sol10_demo_Overview/pgsql.xml
#
#copy these to (or anywhere else you prefer):
#
#/lib/svc/method/pgsql
#/var/svc/manifest/application/pgsql.xml
#
#Setup pgsql if you have not already.
#
#NOTE: This may be already under SMF conrol in later NV builds you will need to
check when
# I wrote this it was not under SMF control. This was what I did on S10
many moons
# ago to setup postgres, it's survived many LUs
# svcs -a | grep sql
# disabled 11:08:53 svc:/application/database/postgresql:version_81
# disabled 11:08:53 svc:/application/database/postgresql_83:default_32bit
# disabled 11:08:53 svc:/application/database/postgresql:version_82_64bit
# disabled 11:08:53 svc:/application/database/postgresql:version_82
# disabled 11:08:53 svc:/application/database/postgresql_83:default_64bit
# disabled 11:08:54 svc:/application/database/mysql:version_50
#
#
#file:///usr/share/doc/pgsql/8.1.3/html/installation.html
#
#su -
#DATA=/var/lib/pgsql/data
#mkdir $DATA #This should exist it is the default
#useradd -d /home/postgres postgres
#mkdir ~postgres
#chown postgres ~postgres
#chown postgres $DATA
#
#su - postgres
#DATA=/var/lib/pgsql/data
#/bin/initdb -D $DATA
#/bin/createdb test#Optional
#/bin/psql -l
#
#su -
#svccfg delete -f pgsql
#cd /home/tp47565/Software/PostgreSQL
#cp ./pgsql.xml /var/svc/manifest/application
#cp ./pgsql /lib/svc/method
#chmod a+r /lib/svc/method/pgsql
#svccfg validate /var/svc/manifest/application/pgsql.xml
#svccfg import /var/svc/manifest/application/pgsql.xml
#svcadm enable pgsql
#svcs pgsql
#su - postgres -c "/bin/psql -l"
# Note: I've setup the postgres user to run /bin/psql -l
# and then logout
#***
## Press return to continue (so you can talk!)
#
press_return()
{
echo "\n\t--> Press RETURN to continue <--\c"
read ANS
echo ""
clear
}
## Do the commands given appending with > so they show up
#
do_command()
{
echo ""
echo "--> $*"
eval $*
}
## I should check if you have the role but I don't - too lazy!
#
UID=`/usr/xpg4/bin/id -u`
if [ ! $UID -eq 0 ]; then
echo "You must be root to run this script"
press_return
exit 1
fi
##
## DEMO START
##
#--- demo 1 simple commands
# Have a browser Running to show that apache stops and starts
# /home/tp47565/bin/browser.sh norton/~tp47565
svcadm disable apache22 #Just in case it is turned off
sleep 2
svcadm enable apache22
sleep 3
cd /tmp
clear
echo ""
echo "Is apache22 running, a simple ps to find out"
echo ""
echo ""
do_command ps -ef | grep apache | grep -v grep
echo ""
echo "I can also see it is via the Browser"
press_return
echo ""
echo " So lets send the processes a kill -9"
echo ""
do_command kill -9 `pgrep httpd `
echo ""
echo "Is apache22 running, a simple ps to find out"
echo ""
do_command sleep 5
echo ""
do_command ps -ef | grep apache | grep -v grep
echo ""
echo "I can also see it is via the Browser"
echo ""
echo "But did you Notice the PIDs have changed?"
press_return
echo ""
echo ""
echo "In Solaris 10 most things have been turned into Services"
echo "Lets look into /etc/init.d"
do_command ls /etc/init.d
echo ""
echo ""
echo "There seems to
Re: [zones-discuss] svnserve
Hi.
I'd also take into account how you plan to configure Subversion. When
I'm not needing Apache2 and mod_svn I usually configure it as an inetd
service. I blogged about it, you can start here:
http://thegreyblog.blogspot.com/search/label/subversion
Hope this helps,
Enrico
On Tue, Oct 6, 2009 at 10:23 PM, Trevor Pretty
wrote:
>
> If it does not come with a manifest for SMF you need to write one. If it
> does then use it! or just use an rc script. However using the rc scrpt ans
> making a service run under SMF is not hard. Attached is what I wrote as a
> demo before postgress got an SMF service by default.
>
> Look at "demo 2" in the self running ksh script where I demo my newly
> created service.
>
> The Defiant wrote:
>
> Hi All,
>
> Another newbie question. I've just configured a seprate contaniner to serve
> as a seprate svn repository and configured svnserve as the default svn
> server. Everything works fine, except svnserve wont autostart after
> rebooting ;(
>
> Can someone point me to adding svnserve to autostart. I guess we would be
> using SMF service and not the autostart.sh
>
> Thx in advance!
>
>
>
>
> www.eagle.co.nz
>
> This email is confidential and may be legally privileged. If received in
> error please destroy and immediately notify us.
> #!/usr/bin/ksh
> #
> #
> #Note: The presentation is:-
> #
> #http://webhome.singapore/trevor/Standard_Pressos/Solaris10_Demos/Sol10_demo_Overview/Solaris10_demo_SMF_CONTAINERS_ZFS.odp
> #
> #
> #
> # NOTE: This one use apache22 the older version use apache2
> #
> #http://webhome.singapore/trevor/Standard_Pressos/Solaris10_Demos/Sol10_demo_Overview/smf_demo_self_running.ksh_apache2
> #
> #
> #--Setup---
> #
> #get the two files you need:-
> #
> #http://webhome.singapore/trevor/Standard_Pressos/Solaris10_Demos/Sol10_demo_Overview/pgsql
> #http://webhome.singapore/trevor/Standard_Pressos/Solaris10_Demos/Sol10_demo_Overview/pgsql.xml
> #
> #copy these to (or anywhere else you prefer):
> #
> #/lib/svc/method/pgsql
> #/var/svc/manifest/application/pgsql.xml
> #
> #Setup pgsql if you have not already.
> #
> #NOTE: This may be already under SMF conrol in later NV builds you will need
> to check when
> # I wrote this it was not under SMF control. This was what I did on S10
> many moons
> # ago to setup postgres, it's survived many LUs
> # svcs -a | grep sql
> # disabled 11:08:53 svc:/application/database/postgresql:version_81
> # disabled 11:08:53
> svc:/application/database/postgresql_83:default_32bit
> # disabled 11:08:53
> svc:/application/database/postgresql:version_82_64bit
> # disabled 11:08:53 svc:/application/database/postgresql:version_82
> # disabled 11:08:53
> svc:/application/database/postgresql_83:default_64bit
> # disabled 11:08:54 svc:/application/database/mysql:version_50
> #
> #
> #file:///usr/share/doc/pgsql/8.1.3/html/installation.html
> #
> #su -
> #DATA=/var/lib/pgsql/data
> #mkdir $DATA #This should exist it is the default
> #useradd -d /home/postgres postgres
> #mkdir ~postgres
> #chown postgres ~postgres
> #chown postgres $DATA
> #
> #su - postgres
> #DATA=/var/lib/pgsql/data
> #/bin/initdb -D $DATA
> #/bin/createdb test #Optional
> #/bin/psql -l
> #
> #su -
> #svccfg delete -f pgsql
> #cd /home/tp47565/Software/PostgreSQL
> #cp ./pgsql.xml /var/svc/manifest/application
> #cp ./pgsql /lib/svc/method
> #chmod a+r /lib/svc/method/pgsql
> #svccfg validate /var/svc/manifest/application/pgsql.xml
> #svccfg import /var/svc/manifest/application/pgsql.xml
> #svcadm enable pgsql
> #svcs pgsql
> #su - postgres -c "/bin/psql -l"
> # Note: I've setup the postgres user to run /bin/psql -l
> # and then logout
> #***
>
>
> ## Press return to continue (so you can talk!)
> #
> press_return()
> {
> echo "\n\t--> Press RETURN to continue <--\c"
> read ANS
> echo ""
> clear
> }
>
> ## Do the commands given appending with > so they show up
> #
> do_command()
> {
> echo ""
> echo "--> $*"
> eval $*
> }
>
> ## I should check if you have the role but I don't - too lazy!
> #
> UID=`/usr/xpg4/bin/id -u`
> if [ ! $UID -eq 0 ]; then
> echo "You must be root to run this script"
> press_return
> exit 1
> fi
>
>
> ##
> ## DEMO START
> ##
>
> #--- demo 1 simple commands
>
> # Have a browser Running to show that apache stops and starts
> # /home/tp47565/bin/browser.sh norton/~tp47565
>
> svcadm disable apache22 #Just in case it is turned off
> sleep 2
> svcadm enable apache22
> sleep 3
> cd /tmp
> clear
> echo ""
> echo "Is apache22 running, a simple ps to find out"
> echo ""
> echo ""
> do_command ps -ef | grep apache | grep -v grep
> echo ""
> echo "I
Re: [zones-discuss] svnserve
Wow, Thanks you guys!!! Very informative.. If anyone else has a similar issue they can try this too: http://fred.nomades.info/sysadm/sol10/#svn Cheers -TheDefiant. Message was edited by: defian7 -- This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
