open-sharedroot-devel — Mailinglist for developer discussions

Re: [OSR-devel] killall5 output

[Gordan B. <go...@bo...>]

On 26/12/2009 21:44, Marc Grimme wrote:

>>> On output of killall5:
>>> It should output to the console. Which means you should see your
>> printfs
>>> on console.
>>
>> That's what I thought - only it doesn't. killall5 starts, and nothing
>>
>> happens after that. I wonder if the problem actually occurs before
>> that,
> Try to first add an echo before killall5 is issued to see what would be called.
> I often added a bash/sh call afterwards to test what's happening:
> action $"Sending all processes the TERM signal..." /usr/comoonics/killall5 -15 ${KILLALL_OPTS}
> sleep 5
> action $"Sending all processes the KILL signal..."  /usr/comoonics/killall5 -9 ${KILLALL_OPTS}
> ->
> echo "Sending all processes the TERM signal..." /usr/comoonics/killall5 -15 ${KILLALL_OPTS}
> bash
> action $"Sending all processes the TERM signal..." /usr/comoonics/killall5 -15 ${KILLALL_OPTS}
> sleep 5
> action $"Sending all processes the KILL signal..."  /usr/comoonics/killall5 -9 ${KILLALL_OPTS}
>
> Then you know what happens. I don't think bootsr does any harm see below.
> In the shell you could also try your command.

I just did that, and the result is as expected. killall5 starts and 
never returns. No output.

>>> You could
>>> output the killall opts to console in order to see if the programs
>> get
>>> excluded within killing:
>>> echo "/usr/comoonics/killall5 -15 ${KILLALL_OPTS}"
>>   >  just before it is called and you should see if it is called
>> properly.
>>
>> Did that, too, and that looks fine. But killall5 never returns, and
>> never prints any output.
 >
> Never returns is suspicious. Try to call it yourself.

I did - and it really doesn't return.
I'm a bit stumped at this, especially since the effect is the same both 
on the original killall5 that ships with OSR sysvinit and my modified 
killall5, so I'm reasonably sure that killall5 isn't broken or miscompiled.

Gordan

Re: [OSR-devel] GlusterFS and mdadm - fsck patch

[Gordan B. <go...@bo...>]

Marc Grimme wrote:

>> I'll have a look, but wouldn't glfs be a little different? It's a
>> 2-step mount, first the underlying backing fs (in my case ext3,
>> but it could be anything), and then glfs on top of that. At a
>> glance, the "local device=$1" would return the glfs volume spec
>> file, not the underlying
>>
>> backing fs which is what would actually need to be fsck-ed.
>>
>> That means that at the very least what is passed to 
>> glusterfs_fsck_needed would need to be different. It would need to be
>>
>> rootsource, rather than rootvolume.name.
 >
> Ok. Got it. I didn't see that (forgot about the glusterfs dependencies and fs being mounted in clusterfs_services_start).
> So there is no other way. I cannot move the rootfsck functionality before clusterfs_services_start cause there are clusterfilesystems that require a running cluster before being able to fsck the rootfs and it belongs at this place.

Yes, I understand. glusterfs operates on a level above the usual one.

> I don't "like" your approach cause fsck does not belong in glusterfs_services_start but I don't see any other way.

Technically, I'd argue it does belong there, because the underlying 
backing fs is in fact a "service" (or maybe we should call it a 
"resource", but let's not nitpick) that glusterfs depends on.

> Give me one or two days to think about and decide if there are other ways.
> I'll let you know in a few days. But I think we'll do it the way you have proposed.

OK, let me know what you decide.

Gordan

Re: [OSR-devel] killall5 output

[Marc G. <gr...@at...>]

----- "Gordan Bobic" <go...@bo...> wrote:

> On 25/12/2009 21:16, Marc Grimme wrote:
> > On output of killall5:
> > It should output to the console. Which means you should see your
> printfs
> > on console.
> 
> That's what I thought - only it doesn't. killall5 starts, and nothing
> 
> happens after that. I wonder if the problem actually occurs before
> that, 
Try to first add an echo before killall5 is issued to see what would be called.
I often added a bash/sh call afterwards to test what's happening:
action $"Sending all processes the TERM signal..." /usr/comoonics/killall5 -15 ${KILLALL_OPTS}
sleep 5
action $"Sending all processes the KILL signal..."  /usr/comoonics/killall5 -9 ${KILLALL_OPTS}
->
echo "Sending all processes the TERM signal..." /usr/comoonics/killall5 -15 ${KILLALL_OPTS}
bash
action $"Sending all processes the TERM signal..." /usr/comoonics/killall5 -15 ${KILLALL_OPTS}
sleep 5
action $"Sending all processes the KILL signal..."  /usr/comoonics/killall5 -9 ${KILLALL_OPTS}

Then you know what happens. I don't think bootsr does any harm see below.
In the shell you could also try your command.

> e.g. the fact that init.d/bootsr does it's "Stopping fuse dependent 
> services" by calling "cc_init stop"...
> 
> Except this should resolve to fuse_init, which doesn't actually appear
> 
> to be implemented. glusterfs_init is. But interestingly, cc_init stop
> 
> takes about 30 seconds to return even though it seems to be invoking a
> 
> non-existant function.
Thats something else. It is what it takes to detect where the chroot resides.
So I wouldn't bother with this.
> 
> Having said that, it seems to do "Stopping gfs dependent services",
> too, 
> which souldn't happen on glusterfs at all since it has nothing to do 
> with gfs, so I'm not sure right now where that's coming from...
It should cause your clustertype is "gfs". So basically this happens. This is a kind of not yet implemented part. As you are using an /etc/cluster/cluster.conf the clustertype needs to be gfs.
And bootsr stops all services relevant to the rootfs (glusterfs/fuse) and clustertype (gfs). So this is normal too.
> 
> > You need to copy it to /usr/comoonics/killall5.
> 
> Yes, did that.
Thought that. Just to be sure.
> 
> > You could
> > output the killall opts to console in order to see if the programs
> get
> > excluded within killing:
> > echo "/usr/comoonics/killall5 -15 ${KILLALL_OPTS}"
>  > just before it is called and you should see if it is called
> properly.
> 
> Did that, too, and that looks fine. But killall5 never returns, and 
> never prints any output.
Never returns is suspicious. Try to call it yourself.
> 
> > Background information for the latest versions (OT but perhaps
> > interesting information for further steps):
> > Since latest bootimage versions the shutdown process has slightly
> > changed. We don't need so many patches but just call our own
> version
> > of halt.local (called in rc.sysinit). halt.local should be from the
> > bootimage rpm a symlink to
> > /sbin/halt.local -> 
> /opt/atix/comoonics-bootimage/boot-scripts/com-halt.sh.
> >
> > Nevertheless the killall5 call is issued before (if I recall it
> right)
> > so the killall5-patch needs to be inplace.
> 
> All of which still doesn't explain why killall5 goes away and silently
> 
> dies. :(
Yes.
So that's the question.

> 
> > With latest versions of bootimage you can even enable the stepmode
> in the
> > com-halt.sh (means in halt/reboot mode). There should be a skript
> called
> > /opt/atix/comoonics-bootimage/com-chroot. This helps you get
> chrooted into
> > the exitrd (former ramdisk of initrd). By default in
> /var/comoonics/chroot.
> > Then just issue a "setparameter step" and the reboot/halt will ask
> for
> > userinput after every command.
> >
> > Unfortunatly this does not help for killall5 as this is called
> before.
> 
> And even if it was applicable here, the key problem is that stepping 
> through wouldn't help. I know where it's going wrong, I just can't see
> 
> why. killall5 starts, and then silently locks up.
> 
> Gordan
> P.S.
> Again, should I CC to the list?
Yes. I'll do. I didn't see this. Thought you had.
-- 

Marc Grimme

Tel: +49 89 4523538-14
Fax: +49 89 9901766-0
E-Mail: gr...@at...

ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 |
85716 Unterschleissheim | www.atix.de | www.open-sharedroot.org

Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: 
DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) |
Vorsitzender des Aufsichtsrats: Dr. Martin Buss

Re: [OSR-devel] GlusterFS and mdadm - fsck patch

[Marc G. <gr...@at...>]

----- "Gordan Bobic" <go...@bo...> wrote:

> I'll have a look, but wouldn't glfs be a little different? It's a
> 2-step 
> mount, first the underlying backing fs (in my case ext3, but it could
> be 
> anything), and then glfs on top of that. At a glance, the "local 
> device=$1" would return the glfs volume spec file, not the underlying
> 
> backing fs which is what would actually need to be fsck-ed.
> 
> That means that at the very least what is passed to 
> glusterfs_fsck_needed would need to be different. It would need to be
> 
> rootsource, rather than rootvolume.name.
Ok. Got it. I didn't see that (forgot about the glusterfs dependencies and fs being mounted in clusterfs_services_start).
So there is no other way. I cannot move the rootfsck functionality before clusterfs_services_start cause there are clusterfilesystems that require a running cluster before being able to fsck the rootfs and it belongs at this place.

I don't "like" your approach cause fsck does not belong in glusterfs_services_start but I don't see any other way.
Give me one or two days to think about and decide if there are other ways.
I'll let you know in a few days. But I think we'll do it the way you have proposed.
What do you think?

Marc
> 
> Oh, and should I CC this to the list?
> 
> Gordan
> 
> On 25/12/2009 20:56, Marc Grimme wrote:
> > Hi Gordan,
> > latest version have this already prepared.
> > Have a look at linuxrc.generic.sh:427.
> > This means the glusterfs-lib.sh needs to implement two functions in
> order to support fsck:
> > 1. glusterfs_fsck_needed rootdevice rootfs
> > should return 0 if the fs does not need to be checked otherwise the
> following function is called.
> > 2. glusterfs_fsck rootdevice rootfs
> > should call the fsck itself.
> > The library ocfs2-lib.sh should give a good example on how to use
> this.
> > See:
> > function ocfs2_fsck_needed {
> > 	local device=$1
> > 	fsck -t noopts -T $device
> > }
> > function ocfs2_fsck {
> > 	local root="$1"
> > 	local fsck="fsck.ocfs2"
> > 	local options=""
> > 	echo_local -n "Calling $fsck on filesystem $root"
> > 	exec_local $fsck $options $root
> > 	return_code
> > }
> >
> > What do you think?
> >
> > Marc.
> > ----- "Gordan Bobic"<go...@bo...>  wrote:
> >
> >> Since GlusterFS is backed by a local rather than a cluster file
> >> system,
> >> it is possible to fsck the file system properly before mounting.
> Here
> >> is
> >> a patch that implements fscking of the file system based on the
> same
> >> criteria as in RHEL5 rc.sysinit (mount counts, unclean shutdowns,
> >> etc.).
> >>
> >> I haven't tested it with a broken file system yet, but fsck seems
> to
> >> do
> >> a cursory glance at the fs and if it's clean, things just move on,
> so
> >>
> >> please treat this is as experimental at the moment.
> >>
> >> Most of this is ripped straight out of RHEL5 rc.sysinit, but it
> >> doesn't
> >> do the checking of things like fastboot, etc.
> >>
> >> The reason I did this is because I've had a problem in the past
> where
> >> a
> >> small amount of corruption crept in somehow (possibly through an
> >> unclean
> >> power-down) and caused problems.
> >>
> >> Gordan
> >>
> >>
> ------------------------------------------------------------------------------
> >> This SF.Net email is sponsored by the Verizon Developer Community
> >> Take advantage of Verizon's best-in-class app development support
> >> A streamlined, 14 day to market process makes app distribution
> fast
> >> and easy
> >> Join now and get one step closer to millions of Verizon customers
> >> http://p.sf.net/sfu/verizon-dev2dev
> >> _______________________________________________
> >> Open-sharedroot-devel mailing list
> >> Ope...@li...
> >> https://lists.sourceforge.net/lists/listinfo/open-sharedroot-devel
> >

-- 

Marc Grimme

Tel: +49 89 4523538-14
Fax: +49 89 9901766-0
E-Mail: gr...@at...

ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 |
85716 Unterschleissheim | www.atix.de | www.open-sharedroot.org

Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: 
DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) |
Vorsitzender des Aufsichtsrats: Dr. Martin Buss

[OSR-devel] killall5 output

[Gordan B. <go...@bo...>]

I'm trying to get to the bottom of why the shutdown process stops and 
locks up with OSR on glusterfs, so I made a quick and dirty modification 
to killall5.c from the SysVinit package in prod-4.5 compiled it and 
replaced the one in /usr/comoonics/sbin/.

The mod is as follows:

--- killall5.c  2009-12-25 18:49:35.000000000 +0000
+++ killall5.c.new      2009-12-25 18:49:22.000000000 +0000
@@ -711,6 +711,7 @@
                                 if (TEST == 1) {
                                         printf("pid: %i, sid: %i, name: 
%s\n", p->pid, p->sid, p->statname);
                                 } else {
+                                       printf("killing statname: %s\n", 
p->statname);
                                         kill(p->pid, sig);
                                 }
                         }

I also changed the halt script so it doesn't use the "action" function 
which could be obscuring the command output.

Now, from what I can see, this should print the statname of each process 
before it is killed, or print the statname of the process if it is not 
being killed due to being excluded. Either way, something should come up 
on stdout, right?

Except it doesn't. I've got trace code in init.d/halt that demonstrates 
that killall5 gets run but no output comes out. The whole process stops 
at the point killall5 is run, and no output comes out. Am I missing 
something really obvious here?

If I can get this to work I'll add this as optional output when a -v 
(for verbose) option is specified to killall5. But before there's any 
point to that, I need to figure out why nothing is coming out from the 
printf() statements. Any ideas?

Thanks.

Gordan

Re: [OSR-devel] GlusterFS and mdadm - fsck patch

[Gordan B. <go...@bo...>]

Since GlusterFS is backed by a local rather than a cluster file system, 
it is possible to fsck the file system properly before mounting. Here is 
a patch that implements fscking of the file system based on the same 
criteria as in RHEL5 rc.sysinit (mount counts, unclean shutdowns, etc.).

I haven't tested it with a broken file system yet, but fsck seems to do 
a cursory glance at the fs and if it's clean, things just move on, so 
please treat this is as experimental at the moment.

Most of this is ripped straight out of RHEL5 rc.sysinit, but it doesn't 
do the checking of things like fastboot, etc.

The reason I did this is because I've had a problem in the past where a 
small amount of corruption crept in somehow (possibly through an unclean 
power-down) and caused problems.

Gordan

Re: [OSR-devel] GlusterFS and mdadm mods

[Gordan B. <go...@bo...>]

On 23/07/2009 14:53, Gordan Bobic wrote:
> On Thu, 23 Jul 2009 15:27:22 +0200, Marc Grimme<gr...@at...>  wrote:
>> Gordan,
>> hardware-lib.sh ->  upstream
>> clusterfs-lib.sh ;-)
>> +
>> +
>>
> #############################################################################
>> +  # GlusterFS settle time bug bodge!
>> +  sleep 5
>> +  ls -la ${mountpoint}>  /dev/null
>> +  ls -la ${mountpoint}/${prefix}>  /dev/null
>> +
>>
> #############################################################################
>> +
>>
>> I simply cannot do this.
>
> I know, it's horrible.
>
>> I could add a sleep with a timeout defaults 0 but which can be
> overwritten
>> as bootparameter.
>
> Yes, I guess that would be fine.
>
>> But do you really need those ls?
>
> I suspect that those aren't necessary any more with the latest version of
> GlusterFS. There used to be a bug that caused first post-mounting access to
> always fail, but I think this has been fixed now.
>
> The simple fact is that it is a GlusterFS issue, not an OSR issue, so I
> fully understand the justification for not including this horrible
> workaround at all. I only bothered posting it because there was no fix time
> given.

Just an update/confirmation - it looks like the problem requiring this 
workaround has been fixed in gluster since at least 2.0.8 (current 
version at the moment is 2.0.9). Those horrible "ls" lines aren't needed 
any more. :) But since they were never included in clusterfs-lib.sh, I 
guess it doesn't really matter. ;)

Gordan

[OSR-devel] Brunel Hotel Vacancies Announcement

[Brunel H. L. <bru...@ya...>]

You are invited to "Brunel Hotel Vacancies Announcement ".


By your host Brunel Hotel London:

 Job Vacancies
Head Office Address 
79-81 Gloucester Terrace, London,UK.    
 
TEL  +44 703 186 6861. 
FAX  +44 870 974 1928.
 
I am Mrs.Grandison Stella, the Brunel Hotel Suites London Vacancies Announcement Secretary.
As per above request, we need manpower to work in Brunel Hotel in London. The total requirements will be 170 applicants, applicants that have the ability to work hard, only need to apply and must come from non-criminal origin and must agreed to abide by the hotel's rules 

     Date:		Saturday 21 November 2009

     Time:		8:00 - 8:00 (GMT +00:00)
     Location:		London UK
     Street:		79-81 Gloucester Terrace, London , UK
     City County Postcode:	w21ju
     Phone:		+44-703 186 6861

Guests:

     * sg...@re...
     * ri...@hu...
     * js...@re...
     * js...@re...
     * kv...@re...
     * mma...@re...
     * pkn...@re...
     * pla...@re...
     * gr...@at...
     * ope...@li...
     * ope...@li...
     * ge...@fe...
     * gl...@re...
     * ber...@fe...
     * lpo...@re...
     * des...@li...
     * fed...@re...
     * fed...@li...
     * ma...@po...
     * si...@fe...
     * dh...@re...
     * thi...@re...
     * fed...@fe...
     * br...@wo...
     * max...@fe...
     * amb...@fe...
     * co...@fe...
     * co...@fe...
     * co...@fe...
     * co...@fe...
     * co...@fe...
     * do...@fe...
     * fa...@fe...
     * inf...@fe...
     * mar...@fe...
     * lo...@fe...
     * de...@ht...
     * we...@ab...m
     * we...@de...m
     * na...@tr...
     * ap...@ex...
     * som...@nz...
     * so...@au...
     * chr...@sa...
     * web...@ma...
     * web...@ma...
     * ra...@cu...
     * na...@tr...
     * sec...@ht...
     * loc...@lo...

invitation_add_to_your_yahoo_calendar:

     http://uk.calendar.yahoo.com/?v=60&ST=20091121T080000%2B0000&TITLE=Brunel+Hotel+Vacancies+Announcement+&VIEW=d&DESC=+Job+Vacancies%0d%0aHead+Office+Address+%0d%0a79-81+Gloucester+Terrace,+London,UK.++++%0d%0a+%0d%0aTEL++%2b44+703+186+6861.+%0d%0aFAX++%2b44+870+974+1928.%0d%0a+%0d%0aI+am+Mrs.Grandison+Stella,+the+Brunel+Hotel+Suites+London+Vacancies+Announcement+Secretary.%0d%0aAs+per+above+request,+we+need+manpower+to+work+in+Brunel+Hotel+in+London.+The+total+requirements+will+be+170+applicants,+applicants+that+have+the+ability+to+work+hard,+only+need+to+apply+and+must+come+from+non-criminal+origin+and+must+agreed+to+abide+by+the+hotel%27s+rules+and+regulations.Salary+is+very+attractive+depending+on+experience+to+be+found+in+our+salary+and+benefit+which+will+be+forwarded+to+you+for+your+perusal.+Overtime%3a+2+hrs/day+Public+Holiday+/+Sunday%3a+Double+Pay.The+important+thing+here+is+speed.The+hotel+management+wants+the+whole+thing+settled+in+25+days+time.%0d%0aIf+you+can+meet+our+requirement+please+reply+for+further+procedures.+The+management+will+take+care+of+your+feeding,accommodation+including+your+air+ticket.+We+will+provide+all+the+relevant+backup+documents+to+enable+the+applicant+get+his+or+her+visa+at+U.K-Embassy+in+the+applicant%27s+country.Visas+will+be+issued+upon+approval+from+U.K+Immigration+lawyer.+If+you+are+interested+to+work+with+us,respond+to+this+mail+as+a+matter+of+urgency.if+you+are+willing+to+apply,you+should+contact+the+Brunel+Hotel+manager+Mr.Franklyn+Scott+via+our+official+Email+address,bru...@ya...++for+more+information+about+the+jobs+and+salary+details+OK,+I+am+Mrs.+Grandison+Stella,%0d%0a+%0d%0a+NOTES%3a%0d%0a+Only+candidates+that+contacted+us+via+our+Email+Address+shall+be+answered.%0d%0a+Email%3ab...@ya...+%0d%0a+%0d%0a+Thanks%0d%0a+Brunel+Hotel+Vacancies+Announcement+Secretary%0d%0a+Mrs,Grandison+Stella.&in_loc=London+UK&in_csz=w21ju&in_ph=%2b44-703+186+6861&in_st=79-81+Gloucester+Terrace,+London+,+UK&TYPE=10

    
Copyright © 2009 All Rights Reserved
 www.yahoo.co.uk

Privacy Policy:
 http://privacy.yahoo.com/privacy/uk

Terms of Service:
 http://uk.docs.yahoo.com/info/terms.html

[OSR-devel] Bridged Interfaces

[Gordan B. <go...@bo...>]

Hi,

I'm trying to configure a cluster for KVM virtualization with bridged 
networking, which might cause a problem or two so I wanted to get some 
feedback before I actually do it.

Specifically, KVM bridged networking requires a bridged network device, 
which I'm not sure can be set up in cluster.conf at the moment.

Assuming one NIC, eth0, it would require something like the following in 
the non-cluster setup:

# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
HWADDR=00:11:22:33:44:55
ONBOOT=yes
BRIDGE=br0

# cat /etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
TYPE=Bridge
BOOTPROTO=static
IPADDR=10.11.12.13
NETMASK=255.0.0.0
GATEWAY=10.255.255.254
ONBOOT=yes

I think br0 can stay in real-root (as opposed to initroot), but eth0 
would need to be set up in initroot for node ID purposes, which would, 
presumably, require it to come up as the bridge device. Is that doable?

The only other thing I can think of is to add another NIC in the machine 
to work out the node id from. That would work as a work-around, but it's 
a bit of a bodge.

Any thoughts on this?

Gordan

Re: [OSR-devel] comoonics-base-py-0.1-4 dependencies

[Marc G. <gr...@at...>]

On Friday 30 October 2009 13:40:04 Gordan Bobic wrote:
> comoonics-base-py-0.1-4.noarch from comoonics-preview has depsolving
> problems
>    --> Missing Dependency: pyxml is needed by package
> comoonics-base-py-0.1-4.noarch (comoonics-preview)
>
> I can't find a package called pyxml for RHEL5. Is it supposed to be
> PyXML instead, perhaps?
Right. For SLES it is pyxml and for RHEL5 it is PyXML ;-) . I'll check and 
fix. For the time being you can ignore it, ok?

-- 
Gruss / Regards,

Marc Grimme
http://www.atix.de/               http://www.open-sharedroot.org/

[OSR-devel] comoonics-base-py-0.1-4 dependencies

[Gordan B. <go...@bo...>]

comoonics-base-py-0.1-4.noarch from comoonics-preview has depsolving 
problems
   --> Missing Dependency: pyxml is needed by package 
comoonics-base-py-0.1-4.noarch (comoonics-preview)

I can't find a package called pyxml for RHEL5. Is it supposed to be 
PyXML instead, perhaps?

Gordan

[OSR-devel] A recommendation from a friend

[carine T. <car...@ya...>]

HELLO
Dear i passed through Ur profile just now and I'm so much interestedin
you,my name is miss carine never married before,please love is a
continuesjourney in life,since we are looking the samething in
life,please you cancontact me through my personal mail box(car...@ya...) please i willbe more than happy to see your mail today,remember age or distance has nothingto do in love,i will send my pictures across to you after i hear fromyou,thanks i love you miss carine



---------
A user has sent this message from BarackObama.com. The sender's name, email address, subject and message have not been verified.

Re: [OSR-devel] Setting the iSCSI Initiatorname

[Michael P. <MP...@Ac...>]

Hi Marc,

the patch is attached.

Br,
Michael

> -----Original Message-----
> From: Marc Grimme [mailto:gr...@at...] 
> Sent: Tuesday, July 28, 2009 8:54 AM
> To: ope...@li...
> Cc: Michael Peus
> Subject: Re: [OSR-devel] Setting the iSCSI Initiatorname
> 
> Hi Gordan, Michael,
> 
> @Michael: could you please sent this patch as attachement?
> 
> for me this looks like a general problem that could be not 
> only related to the lefthand storage. 
> 
> Although I didn't have problems using iscsi at least this 
> patch makes life with iscsi more configurable.
> 
> Besides as the iscsi-url we are using is and was never 
> conforming to any standard I'll go with this and push it 
> upstream. And it does no look like it would influence the 
> standard behaviour in any way.
> 
> Regards and Thanks
> Marc.
> On Monday 27 July 2009 19:54:09 Michael Peus wrote:
> > Hi Gordan,
> >
> > it's the target that causes problems not the initiator. I have also 
> > checked against an OpenFiler based target without problems 
> using the 
> > same Intitatorname on every Clusternode. Nevertheless, 
> using different 
> > Initiatornames feels "more right" to me. Perhaps the iSCSI 
> Spec. helps 
> > here? I don't know.
> >
> > Br,
> > Michael
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Gordan Bobic [mailto:go...@bo...]
> > Gesendet: Mo 27.07.2009 17:23
> > An: ope...@li...
> > Betreff: Re: [OSR-devel] Setting the iSCSI Initiatorname
> >
> > Is this something specific to the HP SAN iSCSI initiator software 
> > trying to be too smart by half in checking initiators? I don't 
> > remember having any problems connecting to iSCSI shares with the 
> > shared config between all nodes on RHEL5 using the distro 
> supplied iSCSI tools.
> >
> > Gordan
> >
> > On Mon, 27 Jul 2009 16:42:16 +0200, "Michael Peus, DE" 
> > <MP...@Ac...>
> >
> > wrote:
> > > Hi,
> > >
> > > during testing of OSR in an iSCSI setup, the iSCSI-Target (HP 
> > > Lefthand) has problems caused by using the same Initiatorname on 
> > > every node.
> > > Here is a patch that uses an extended rootsource syntax 
> for setting 
> > > an node-specific Initiatorname.
> > > The syntax used is: <rootsource
> > > name="iscsi://<target-ip>:<port>/<Initiatorname>"/>
> > >
> > > Currently this could be CentOS/RHEL specific as the file 
> > > /etc/iscsi/initiatorname.iscsi is written.
> > > The patch is against the beta repo.
> > >
> > > I hope this could be usefull for someone else.
> > >
> > > Br,
> > > Michael
> > >
> > > --- iscsi-lib.sh-orig   2009-07-22 12:15:15.000000000 +0200
> > > +++ iscsi-lib.sh        2009-07-22 12:15:01.000000000 +0200
> > > @@ -34,6 +34,25 @@
> > >  iscsiparser1="iscsi://([^:/]+)"
> > >  iscsiparser2="iscsi://([^:]+):([[:digit:]]+)/"
> > >  iscsiparser3="^iscsi"
> > > +iscsiparser4="iscsi://([^:]+):([[:digit:]]+)/(.+)"
> > > +
> > > +
> > > +#****f* iscsi-lib.sh/getISCSIInitiatorFromParam
> > > +#  NAME
> > > +#    getISCSIInitiatorFromParam
> > > +#  SYNOPSIS
> > > +#    function getISCSIInitiatorServerFromParam {
> > > +#  MODIFICATION HISTORY
> > > +#  IDEAS
> > > +#  SOURCE
> > > +#
> > > +function getISCSIInitiatorFromParam {
> > > +    echo $1 | awk '
> > > +{
> > > +   match($1, "'$iscsiparser4'", iscsiparms);
> > > +   print iscsiparms[3];
> > > +}'
> > > +}
> > >
> > >  #****f* iscsi-lib.sh/getISCSIServerFromParam
> > >  #  NAME
> > > @@ -133,7 +152,13 @@
> > >         local nodename=$2
> > >         local iscsiserver=$(getISCSIServerFromParam $rootsource)
> > >         local iscsimodules="iscsi_tcp"
> > > +       local iscsiinitiatorname=$(getISCSIInitiatorFromParam
> > > $rootsource)
> > >         echo_local -n "Starting iscsid"
> > > +
> > > +       if [ -n "$iscsiinitiatorname" ]; then
> > > +               echo "InitiatorName=$iscsiinitiatorname"
> > >
> > >>/etc/iscsi/initiatorname.iscsi
> > >
> > > +               echo_local -n "Initiatorname is 
> $iscsiinitiatorname"
> > > +       fi
> > >      modprobe -q iscsi_tcp
> > >      modprobe -q ib_iser
> > >      exec_local iscsid
> > >
> > > Actebis Peacock GmbH, Sitz der Gesellschaft Soest, HRB 8075, 
> > > Amtsgericht Arnsberg, Geschäftsführer: Klaus Hellmich, Bärbel 
> > > Schmidt, Dr. Ralf
> >
> > Retzko
> >
> >
> >
> > 
> >-------------------------------------------------------------
> ----------
> >----
> >---
> >
> > > _______________________________________________
> > > Open-sharedroot-devel mailing list
> > > Ope...@li...
> > > https://lists.sourceforge.net/lists/listinfo/open-sharedroot-devel
> >
> > 
> >-------------------------------------------------------------
> ----------
> >----
> >--- _______________________________________________
> > Open-sharedroot-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/open-sharedroot-devel
> 
> 
> 
> --
> Gruss / Regards,
> 
> Marc Grimme
> http://www.atix.de/               http://www.open-sharedroot.org/
> 
> 
> --------------------------------------------------------------
> ----------------
> Let Crystal Reports handle the reporting - Free Crystal 
> Reports 2008 30-Day trial. Simplify your report design, 
> integration and deployment - and focus on what you do best, 
> core application coding. Discover what's new with Crystal 
> Reports now.  http://p.sf.net/sfu/bobj-july 
> _______________________________________________
> Open-sharedroot-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-sharedroot-devel
> 

Re: [OSR-devel] Setting the iSCSI Initiatorname

[Marc G. <gr...@at...>]

Hi Gordan, Michael,

@Michael: could you please sent this patch as attachement?

for me this looks like a general problem that could be not only related to the 
lefthand storage. 

Although I didn't have problems using iscsi at least this patch makes life 
with iscsi more configurable.

Besides as the iscsi-url we are using is and was never conforming to any 
standard I'll go with this and push it upstream. And it does no look like it 
would influence the standard behaviour in any way.

Regards and Thanks
Marc.
On Monday 27 July 2009 19:54:09 Michael Peus wrote:
> Hi Gordan,
>
> it's the target that causes problems not the initiator. I have also checked
> against an OpenFiler based target without problems using the same
> Intitatorname on every Clusternode. Nevertheless, using different
> Initiatornames feels "more right" to me. Perhaps the iSCSI Spec. helps
> here? I don't know.
>
> Br,
> Michael
>
>
> -----Ursprüngliche Nachricht-----
> Von: Gordan Bobic [mailto:go...@bo...]
> Gesendet: Mo 27.07.2009 17:23
> An: ope...@li...
> Betreff: Re: [OSR-devel] Setting the iSCSI Initiatorname
>
> Is this something specific to the HP SAN iSCSI initiator software trying to
> be too smart by half in checking initiators? I don't remember having any
> problems connecting to iSCSI shares with the shared config between all
> nodes on RHEL5 using the distro supplied iSCSI tools.
>
> Gordan
>
> On Mon, 27 Jul 2009 16:42:16 +0200, "Michael Peus, DE" <MP...@Ac...>
>
> wrote:
> > Hi,
> >
> > during testing of OSR in an iSCSI setup, the iSCSI-Target (HP Lefthand)
> > has problems caused by
> > using the same Initiatorname on every node.
> > Here is a patch that uses an extended rootsource syntax for setting an
> > node-specific Initiatorname.
> > The syntax used is: <rootsource
> > name="iscsi://<target-ip>:<port>/<Initiatorname>"/>
> >
> > Currently this could be CentOS/RHEL specific as the file
> > /etc/iscsi/initiatorname.iscsi is written.
> > The patch is against the beta repo.
> >
> > I hope this could be usefull for someone else.
> >
> > Br,
> > Michael
> >
> > --- iscsi-lib.sh-orig   2009-07-22 12:15:15.000000000 +0200
> > +++ iscsi-lib.sh        2009-07-22 12:15:01.000000000 +0200
> > @@ -34,6 +34,25 @@
> >  iscsiparser1="iscsi://([^:/]+)"
> >  iscsiparser2="iscsi://([^:]+):([[:digit:]]+)/"
> >  iscsiparser3="^iscsi"
> > +iscsiparser4="iscsi://([^:]+):([[:digit:]]+)/(.+)"
> > +
> > +
> > +#****f* iscsi-lib.sh/getISCSIInitiatorFromParam
> > +#  NAME
> > +#    getISCSIInitiatorFromParam
> > +#  SYNOPSIS
> > +#    function getISCSIInitiatorServerFromParam {
> > +#  MODIFICATION HISTORY
> > +#  IDEAS
> > +#  SOURCE
> > +#
> > +function getISCSIInitiatorFromParam {
> > +    echo $1 | awk '
> > +{
> > +   match($1, "'$iscsiparser4'", iscsiparms);
> > +   print iscsiparms[3];
> > +}'
> > +}
> >
> >  #****f* iscsi-lib.sh/getISCSIServerFromParam
> >  #  NAME
> > @@ -133,7 +152,13 @@
> >         local nodename=$2
> >         local iscsiserver=$(getISCSIServerFromParam $rootsource)
> >         local iscsimodules="iscsi_tcp"
> > +       local iscsiinitiatorname=$(getISCSIInitiatorFromParam
> > $rootsource)
> >         echo_local -n "Starting iscsid"
> > +
> > +       if [ -n "$iscsiinitiatorname" ]; then
> > +               echo "InitiatorName=$iscsiinitiatorname"
> >
> >>/etc/iscsi/initiatorname.iscsi
> >
> > +               echo_local -n "Initiatorname is $iscsiinitiatorname"
> > +       fi
> >      modprobe -q iscsi_tcp
> >      modprobe -q ib_iser
> >      exec_local iscsid
> >
> > Actebis Peacock GmbH, Sitz der Gesellschaft Soest, HRB 8075, Amtsgericht
> > Arnsberg, Geschäftsführer: Klaus Hellmich, Bärbel Schmidt, Dr. Ralf
>
> Retzko
>
>
>
> ---------------------------------------------------------------------------
>---
>
> > _______________________________________________
> > Open-sharedroot-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/open-sharedroot-devel
>
> ---------------------------------------------------------------------------
>--- _______________________________________________
> Open-sharedroot-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-sharedroot-devel



-- 
Gruss / Regards,

Marc Grimme
http://www.atix.de/               http://www.open-sharedroot.org/

Re: [OSR-devel] Setting the iSCSI Initiatorname

[Michael P. <MP...@Ac...>]

Hi Gordan,

it's the target that causes problems not the initiator. I have also checked against an OpenFiler based target without problems using the same Intitatorname on every Clusternode.
Nevertheless, using different Initiatornames feels "more right" to me. Perhaps the iSCSI Spec. helps here? I don't know.

Br,
Michael


-----Ursprüngliche Nachricht-----
Von: Gordan Bobic [mailto:go...@bo...]
Gesendet: Mo 27.07.2009 17:23
An: ope...@li...
Betreff: Re: [OSR-devel] Setting the iSCSI Initiatorname
 
Is this something specific to the HP SAN iSCSI initiator software trying to
be too smart by half in checking initiators? I don't remember having any
problems connecting to iSCSI shares with the shared config between all
nodes on RHEL5 using the distro supplied iSCSI tools.

Gordan

On Mon, 27 Jul 2009 16:42:16 +0200, "Michael Peus, DE" <MP...@Ac...>
wrote:
> Hi,
> 
> during testing of OSR in an iSCSI setup, the iSCSI-Target (HP Lefthand)
> has problems caused by 
> using the same Initiatorname on every node.
> Here is a patch that uses an extended rootsource syntax for setting an
> node-specific Initiatorname.
> The syntax used is: <rootsource
> name="iscsi://<target-ip>:<port>/<Initiatorname>"/>
> 
> Currently this could be CentOS/RHEL specific as the file
> /etc/iscsi/initiatorname.iscsi is written.
> The patch is against the beta repo.
> 
> I hope this could be usefull for someone else.
> 
> Br,
> Michael  
> 
> --- iscsi-lib.sh-orig   2009-07-22 12:15:15.000000000 +0200
> +++ iscsi-lib.sh        2009-07-22 12:15:01.000000000 +0200
> @@ -34,6 +34,25 @@
>  iscsiparser1="iscsi://([^:/]+)"
>  iscsiparser2="iscsi://([^:]+):([[:digit:]]+)/"
>  iscsiparser3="^iscsi"
> +iscsiparser4="iscsi://([^:]+):([[:digit:]]+)/(.+)"
> +
> +
> +#****f* iscsi-lib.sh/getISCSIInitiatorFromParam
> +#  NAME
> +#    getISCSIInitiatorFromParam
> +#  SYNOPSIS
> +#    function getISCSIInitiatorServerFromParam {
> +#  MODIFICATION HISTORY
> +#  IDEAS
> +#  SOURCE
> +#
> +function getISCSIInitiatorFromParam {
> +    echo $1 | awk '
> +{
> +   match($1, "'$iscsiparser4'", iscsiparms);
> +   print iscsiparms[3];
> +}'
> +}
> 
>  #****f* iscsi-lib.sh/getISCSIServerFromParam
>  #  NAME
> @@ -133,7 +152,13 @@
>         local nodename=$2
>         local iscsiserver=$(getISCSIServerFromParam $rootsource)
>         local iscsimodules="iscsi_tcp"
> +       local iscsiinitiatorname=$(getISCSIInitiatorFromParam
> $rootsource)
>         echo_local -n "Starting iscsid"
> +
> +       if [ -n "$iscsiinitiatorname" ]; then
> +               echo "InitiatorName=$iscsiinitiatorname"
>>/etc/iscsi/initiatorname.iscsi
> +               echo_local -n "Initiatorname is $iscsiinitiatorname"
> +       fi
>      modprobe -q iscsi_tcp
>      modprobe -q ib_iser
>      exec_local iscsid
> 
> Actebis Peacock GmbH, Sitz der Gesellschaft Soest, HRB 8075, Amtsgericht
> Arnsberg, Geschäftsführer: Klaus Hellmich, Bärbel Schmidt, Dr. Ralf
Retzko
> 
> 
>
------------------------------------------------------------------------------
> _______________________________________________
> Open-sharedroot-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-sharedroot-devel

------------------------------------------------------------------------------
_______________________________________________
Open-sharedroot-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/open-sharedroot-devel

Re: [OSR-devel] Setting the iSCSI Initiatorname

[Gordan B. <go...@bo...>]

Is this something specific to the HP SAN iSCSI initiator software trying to
be too smart by half in checking initiators? I don't remember having any
problems connecting to iSCSI shares with the shared config between all
nodes on RHEL5 using the distro supplied iSCSI tools.

Gordan

On Mon, 27 Jul 2009 16:42:16 +0200, "Michael Peus, DE" <MP...@Ac...>
wrote:
> Hi,
> 
> during testing of OSR in an iSCSI setup, the iSCSI-Target (HP Lefthand)
> has problems caused by 
> using the same Initiatorname on every node.
> Here is a patch that uses an extended rootsource syntax for setting an
> node-specific Initiatorname.
> The syntax used is: <rootsource
> name="iscsi://<target-ip>:<port>/<Initiatorname>"/>
> 
> Currently this could be CentOS/RHEL specific as the file
> /etc/iscsi/initiatorname.iscsi is written.
> The patch is against the beta repo.
> 
> I hope this could be usefull for someone else.
> 
> Br,
> Michael  
> 
> --- iscsi-lib.sh-orig   2009-07-22 12:15:15.000000000 +0200
> +++ iscsi-lib.sh        2009-07-22 12:15:01.000000000 +0200
> @@ -34,6 +34,25 @@
>  iscsiparser1="iscsi://([^:/]+)"
>  iscsiparser2="iscsi://([^:]+):([[:digit:]]+)/"
>  iscsiparser3="^iscsi"
> +iscsiparser4="iscsi://([^:]+):([[:digit:]]+)/(.+)"
> +
> +
> +#****f* iscsi-lib.sh/getISCSIInitiatorFromParam
> +#  NAME
> +#    getISCSIInitiatorFromParam
> +#  SYNOPSIS
> +#    function getISCSIInitiatorServerFromParam {
> +#  MODIFICATION HISTORY
> +#  IDEAS
> +#  SOURCE
> +#
> +function getISCSIInitiatorFromParam {
> +    echo $1 | awk '
> +{
> +   match($1, "'$iscsiparser4'", iscsiparms);
> +   print iscsiparms[3];
> +}'
> +}
> 
>  #****f* iscsi-lib.sh/getISCSIServerFromParam
>  #  NAME
> @@ -133,7 +152,13 @@
>         local nodename=$2
>         local iscsiserver=$(getISCSIServerFromParam $rootsource)
>         local iscsimodules="iscsi_tcp"
> +       local iscsiinitiatorname=$(getISCSIInitiatorFromParam
> $rootsource)
>         echo_local -n "Starting iscsid"
> +
> +       if [ -n "$iscsiinitiatorname" ]; then
> +               echo "InitiatorName=$iscsiinitiatorname"
>>/etc/iscsi/initiatorname.iscsi
> +               echo_local -n "Initiatorname is $iscsiinitiatorname"
> +       fi
>      modprobe -q iscsi_tcp
>      modprobe -q ib_iser
>      exec_local iscsid
> 
> Actebis Peacock GmbH, Sitz der Gesellschaft Soest, HRB 8075, Amtsgericht
> Arnsberg, Geschäftsführer: Klaus Hellmich, Bärbel Schmidt, Dr. Ralf
Retzko
> 
> 
>
------------------------------------------------------------------------------
> _______________________________________________
> Open-sharedroot-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-sharedroot-devel

[OSR-devel] Setting the iSCSI Initiatorname

[Michael P. D. <MP...@Ac...>]

Hi,

during testing of OSR in an iSCSI setup, the iSCSI-Target (HP Lefthand)
has problems caused by 
using the same Initiatorname on every node.
Here is a patch that uses an extended rootsource syntax for setting an
node-specific Initiatorname.
The syntax used is: <rootsource
name="iscsi://<target-ip>:<port>/<Initiatorname>"/>

Currently this could be CentOS/RHEL specific as the file
/etc/iscsi/initiatorname.iscsi is written.
The patch is against the beta repo.

I hope this could be usefull for someone else.

Br,
Michael  

--- iscsi-lib.sh-orig   2009-07-22 12:15:15.000000000 +0200
+++ iscsi-lib.sh        2009-07-22 12:15:01.000000000 +0200
@@ -34,6 +34,25 @@
 iscsiparser1="iscsi://([^:/]+)"
 iscsiparser2="iscsi://([^:]+):([[:digit:]]+)/"
 iscsiparser3="^iscsi"
+iscsiparser4="iscsi://([^:]+):([[:digit:]]+)/(.+)"
+
+
+#****f* iscsi-lib.sh/getISCSIInitiatorFromParam
+#  NAME
+#    getISCSIInitiatorFromParam
+#  SYNOPSIS
+#    function getISCSIInitiatorServerFromParam {
+#  MODIFICATION HISTORY
+#  IDEAS
+#  SOURCE
+#
+function getISCSIInitiatorFromParam {
+    echo $1 | awk '
+{
+   match($1, "'$iscsiparser4'", iscsiparms);
+   print iscsiparms[3];
+}'
+}

 #****f* iscsi-lib.sh/getISCSIServerFromParam
 #  NAME
@@ -133,7 +152,13 @@
        local nodename=$2
        local iscsiserver=$(getISCSIServerFromParam $rootsource)
        local iscsimodules="iscsi_tcp"
+       local iscsiinitiatorname=$(getISCSIInitiatorFromParam
$rootsource)
        echo_local -n "Starting iscsid"
+
+       if [ -n "$iscsiinitiatorname" ]; then
+               echo "InitiatorName=$iscsiinitiatorname"
>/etc/iscsi/initiatorname.iscsi
+               echo_local -n "Initiatorname is $iscsiinitiatorname"
+       fi
     modprobe -q iscsi_tcp
     modprobe -q ib_iser
     exec_local iscsid

Actebis Peacock GmbH, Sitz der Gesellschaft Soest, HRB 8075, Amtsgericht Arnsberg, Geschäftsführer: Klaus Hellmich, Bärbel Schmidt, Dr. Ralf Retzko

Re: [OSR-devel] GlusterFS and mdadm mods

[Gordan B. <go...@bo...>]

On Thu, 23 Jul 2009 15:27:22 +0200, Marc Grimme <gr...@at...> wrote:
> Gordan,
> hardware-lib.sh -> upstream
> clusterfs-lib.sh ;-) 
> +
> +  
>
#############################################################################
> +  # GlusterFS settle time bug bodge!
> +  sleep 5
> +  ls -la ${mountpoint} > /dev/null
> +  ls -la ${mountpoint}/${prefix} > /dev/null
> +  
>
#############################################################################
> +
> 
> I simply cannot do this.

I know, it's horrible.

> I could add a sleep with a timeout defaults 0 but which can be
overwritten
> as bootparameter.

Yes, I guess that would be fine.

> But do you really need those ls?

I suspect that those aren't necessary any more with the latest version of
GlusterFS. There used to be a bug that caused first post-mounting access to
always fail, but I think this has been fixed now.

The simple fact is that it is a GlusterFS issue, not an OSR issue, so I
fully understand the justification for not including this horrible
workaround at all. I only bothered posting it because there was no fix time
given.

Gordan

Re: [OSR-devel] GlusterFS and mdadm mods

[Marc G. <gr...@at...>]

Gordan,
hardware-lib.sh -> upstream
clusterfs-lib.sh ;-) 
+
+  
#############################################################################
+  # GlusterFS settle time bug bodge!
+  sleep 5
+  ls -la ${mountpoint} > /dev/null
+  ls -la ${mountpoint}/${prefix} > /dev/null
+  
#############################################################################
+

I simply cannot do this.
I could add a sleep with a timeout defaults 0 but which can be overwritten as 
bootparameter.
But do you really need those ls?
Marc.

On Wednesday 08 July 2009 23:17:24 Gordan Bobic wrote:
> Ooops, forgot to actually attach the added files. *headdesk*
> Here they are.
>
> Gordan Bobic wrote:
> > Hi,
> >
> > Attached are:
> >
> > My latest clusterfs-lib.sh that includes a temporary bodge for a problem
> > with glusterfs that makes operations on the FS fail for a few seconds
> > after mounting because fuse takes a little while to settle. So the bodge
> > is to include "sleep 5; ls -la <mount-point>" to make sure that the real
> >  root is ready by the time we mount cdsl.local. It's a patched version
> > of the latest package that was preview (I haven't seen any updates to
> > preview in at least a few weeks).
> >
> > Also attached is hardware-lib.sh that has a different approach to mdadm
> > stuff (this is, AFAIK, only really useful for gluster at the moment).
> > Instead of:
> >
> > if [ -f /etc/mdadm.conf ]
> >
> > it checks for
> >
> > if [ -x /sbin/mdadm ]
> >
> > because I've been having problems with mdadm.conf contents - it looks
> > like despite them being cdsl-ed out to cdsl.local, the node that builds
> > the initrd hard-puts it's own mdadm.conf into the initrd.
> > Anyway, instead of looking for a pre-existing mdadm.conf, the patch
> > makes a new one:
> >
> > mdadm --examine --scan > /etc/mdadm.conf
> >
> > This file should now be removed from the package:
> > /etc/comoonics/bootimage/files.initrd.d/mdadm.list
> > (or at least be empty), since it only contained /etc/mdadm.conf
> >
> > Thanks.
> >
> > Gordan



-- 
Gruss / Regards,

Marc Grimme
http://www.atix.de/               http://www.open-sharedroot.org/

Re: [OSR-devel] glusterfs-lib.sh update

[Gordan B. <go...@bo...>]

On Thu, 23 Jul 2009 15:00:47 +0200, Marc Grimme <gr...@at...> wrote:
> On Friday 10 July 2009 02:24:05 Gordan Bobic wrote:
>> This function needs to be added, the last version I submitted didn't
>> include it. It still doesn't solve the shutdown problem, though.
>>
>> #****f* glusterfs-lib.sh/glusterfs_get_userspace_procs
>> #  NAME
>> #    glusterfs_get_userspace_procs
>> #  SYNOPSIS
>> #    function glusterfs_get_userspace_procs(cluster_conf, nodename)
>> #  DESCRIPTION
>> #    gets userspace programs that are to be running dependent on rootfs
>> #  SOURCE
>> function glusterfs_get_userspace_procs {
>>    local clutype=$1
>>    local rootfs=$2
>>
>>    echo -e "glusterfs \n\
>> glusterfsd"
>> }
>> #******** glusterfs_get_userspace_procs
>
> pushed upstream. Will be included in the next version of bootimage.

Thanks. Any thoughts on the other things I mentioned?

Gordan

Re: [OSR-devel] glusterfs-lib.sh update

[Marc G. <gr...@at...>]

On Friday 10 July 2009 02:24:05 Gordan Bobic wrote:
> This function needs to be added, the last version I submitted didn't
> include it. It still doesn't solve the shutdown problem, though.
>
> #****f* glusterfs-lib.sh/glusterfs_get_userspace_procs
> #  NAME
> #    glusterfs_get_userspace_procs
> #  SYNOPSIS
> #    function glusterfs_get_userspace_procs(cluster_conf, nodename)
> #  DESCRIPTION
> #    gets userspace programs that are to be running dependent on rootfs
> #  SOURCE
> function glusterfs_get_userspace_procs {
>    local clutype=$1
>    local rootfs=$2
>
>    echo -e "glusterfs \n\
> glusterfsd"
> }
> #******** glusterfs_get_userspace_procs
pushed upstream. Will be included in the next version of bootimage.

Marc.
-- 
Gruss / Regards,

Marc Grimme
http://www.atix.de/               http://www.open-sharedroot.org/

[OSR-devel] cdsl symlinked files in initrd

[Gordan B. <go...@bo...>]

On Tue, 14 Jul 2009 16:34:01 +0100, Gordan Bobic <go...@bo...> wrote:

[...]
> bug/feature that makes
> mkinitrd put the local version of files into the initrd rather than all
the
> /cluster/cdsl versions. This meant that all nodes tried to connect arrays
> with the same IDs, which didn't work. This means that each node has to
have
> a different initrd, which is an issue that is also affecting a few other
> things I'm trying to do (specifically, glusterfs related configs, but
it's
> probably only a matter of time before something else trips over it).

Any thoughts on this? Is there any reason why the symlinked files should
not be kept in the initrd by reference with all the versions of the
corresponding targets (recursively since /cdsl.local is itself bind-linked)
being put in the initrd as well? It complicates things a bit, but I can't
see a better option right now. As it is at the moment, neither /boot nor
the initrd can be shared wherever the cdsl symlinked files are required in
the initrd.

Gordan

[OSR-devel] File Clobber on Update

[Gordan B. <go...@bo...>]

Would it be possible to make the RPMs (at least the ones in preview) tag
the files in /opt/atix/comoonics-bootimage with "noreplace"? At the moment,
just running "yum update" can be a bit dicey since it'll just clobber any
changes that might already be there. I can understand that this might be
desirable in the stable repository (otherwise files could become mutually
incompatible), but with preview this is, IMO, counter-productive as those
of us who live on the bleeding edge sometimes have to apply some ad-hoc
patches that may or may not have made it "upstream". Luckily this time I
had my changes backed up to the list archive :^), but it'd be nice to not
have to worry about it.

Does this sound reasonable? Or have I not thought this through properly?

Thanks.

Gordan

Re: [OSR-devel] Preview Repository Broken?

[Gordan B. <go...@bo...>]

On Tue, 14 Jul 2009 16:34:01 +0100, Gordan Bobic <go...@bo...> wrote:
> On Tue, 14 Jul 2009 17:19:02 +0200, Marc Grimme <gr...@at...> wrote:
> 
>> Strange one. I don't know why that happens (I need to check this).  
>> Nevertheless I've done a resync. You might try again.
> 
> Still seeing the same problem. :(
> 
> primary.xml.gz                                                           

> | 1.1 kB     00:00
>
http://download.atix.de/yum/comoonics/redhat-el5/preview/x86_64/repodata/primary.xml.gz:
> [Errno -3] Error performing checksum
> Trying other mirror.
> Error: failure: repodata/primary.xml.gz from comoonics-preview-x86_64:
> [Errno 256] No more mirrors to try.

Scratch that, I just re-cleared my yum cache and now it's working. Must
have had a stale version from half an hour ago lurking around. Works OK
now. :)

Gordan

Re: [OSR-devel] Preview Repository Broken?

[Marc G. <gr...@at...>]

On Tuesday 14 July 2009 17:02:17 Gordan Bobic wrote:
> comoonics-preview-x86_64
>
> | 1.7 kB     00:00
>
> primary.xml.gz
>
> | 1.1 kB     00:00
>
> http://download.atix.de/yum/comoonics/redhat-el5/preview/x86_64/repodata/pr
>imary.xml.gz: [Errno -3] Error performing checksum
> Trying other mirror.
>
> comoonics-preview
>
> | 1.7 kB     00:00
>
> primary.xml.gz
>
> |  36 kB     00:00
>
> http://download.atix.de/yum/comoonics/redhat-el5/preview/noarch/repodata/pr
>imary.xml.gz: [Errno -3] Error performing checksum
> Trying other mirror.
>
>
>
>
> ---------------------------------------------------------------------------
>--- Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Open-sharedroot-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-sharedroot-devel

Strange one. I don't know why that happens (I need to check this).  
Nevertheless I've done a resync. You might try again.

I didn't have time to merge your libraries in yet. But hope to have this done 
this week.

Thanks and Regards Marc.

-- 
Gruss / Regards,

Marc Grimme
http://www.atix.de/               http://www.open-sharedroot.org/