Thread: [SSI-devel] removing SIGCLUSTER ?
Brought to you by:
brucewalker,
rogertsang
From: Aneesh K. K.V <ane...@di...> - 2003-03-08 13:23:03
|
Hi, Are we planning to remove SIGCLUSTER in 0.9.5 release. ? -aneesh |
From: Aneesh K. K.V <ane...@di...> - 2003-03-11 12:50:22
|
Is this the getpty permission denied issue ? -aneesh On Tue, 2003-03-11 at 00:04, John Byrne wrote: > Aneesh Kumar K.V wrote: > > Hi, > > > > Are we planning to remove SIGCLUSTER in 0.9.5 release. ? > > > > -aneesh > > > > Yes, but I need to chase one more /dev issue first. > > John > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger > > for complex code. Debugging C/C++ programs can leave you feeling lost and > > disoriented. TotalView can help you find your way. Available on major UNIX > > and Linux platforms. Try it free. www.etnus.com > > _______________________________________________ > > ssic-linux-devel mailing list > > ssi...@li... > > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > > > > |
From: John B. <joh...@hp...> - 2003-03-11 18:19:47
|
Aneesh Kumar K.V wrote: > Is this the getpty permission denied issue ? > > -aneesh I know about "reop_import_path" path problems the checked in code faces and I have fixes for that, but I haven't seen any getpty permission denied issue. A few details, please? John > > > > On Tue, 2003-03-11 at 00:04, John Byrne wrote: > >>Aneesh Kumar K.V wrote: >> >>>Hi, >>> >>>Are we planning to remove SIGCLUSTER in 0.9.5 release. ? >>> >>> -aneesh >>> >> >>Yes, but I need to chase one more /dev issue first. >> >>John >> >> >>> >>> >>> >>> >>>------------------------------------------------------- >>>This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger >>>for complex code. Debugging C/C++ programs can leave you feeling lost and >>>disoriented. TotalView can help you find your way. Available on major UNIX >>>and Linux platforms. Try it free. www.etnus.com >>>_______________________________________________ >>>ssic-linux-devel mailing list >>>ssi...@li... >>>https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel >>> >> >> > > > |
From: Dave P. <dp...@w3...> - 2003-04-06 21:09:19
|
against stock RH8.0 install with dhcp, tftp-server, and nasm installed. # rpm -i cluster-tools-0.9.6-1.i386.rpm mv: cannot stat `/var/lib/nfs/statd': No such file or directory ln: creating symbolic link `/var/lib/nfs/statd' to `statd.{nodenum}': No such file or directory patch: **** Can't find file /etc/rc.d/init.d/nfslock : No such file or directory patching file /etc/rc.d/rc.sysinit # addnode -1 [...standard messages and expected questions...] (S)ave configuration or (r)econfigure [S]: addnode: fatal error: Error looking up username rpcuser: No such file or directory # At this point, the cluster refuses to be built. No mention of needing to create this user in the INSTALL document included in the binary tarball either. After inspecting the addnode script, it looks like it simply fails to check if the current installation is even using NFS at all, assumes it is, wonders why the user doesn't exist, and then dies if you don't have NFS configured, regardless of the need. It also seems to assume one wants the /etc/sysconfig/network-scripts-`nodenum` directory to be owned by the NFS user in the first place. I'm not sure I agree with that from a number of perspectives - perhaps the most visible of these is the security viewpoint. Patches to follow shortly. :-) Kind Regards, -dsp |
From: Dave P. <dp...@w3...> - 2003-04-06 21:44:09
|
--- addnode 2003-04-06 16:10:00.000000000 -0400 +++ addnode 2003-04-06 16:40:56.000000000 -0400 @@ -362,24 +362,25 @@ my $node = shift; my $username = 'rpcuser'; - my @result = getpwnam $username - or die "Error looking up username $username: $!\n"; - my $uid = $result[2]; - @result = getgrnam $username - or die "Error looking up groupname $username: $!\n"; - my $gid = $result[2]; - - my $dir = "/var/lib/nfs/statd.nodenum$node"; - mkdir $dir, 0700 - or die "Can't make directory $dir: $!\n"; - chown $uid, $gid, $dir; + my @result = getpwnam $username; + my ($uid,$gid) = (); + if(defined $result[0]) { + ($uid,$gid) = @result[2,3]; + my $dir = "/var/lib/nfs/statd.nodenum$node"; + mkdir $dir, 0700 or die "Can't make directory $dir: $!\n"; + chown $uid, $gid, $dir; + } + else { + my $msg = "Error looking up username $username: $!\n"; + $msg .= "If NFS is installed, you may need to create the rpcuser user.\n"; + warn $msg; + } return if $node == 1; - $dir = "/etc/sysconfig/network-scripts-$node"; + my $dir = "/etc/sysconfig/network-scripts-$node"; mkdir $dir, 0700 or die "Can't make directory $dir: $!\n"; - chown $uid, $gid, $dir; } sub gethost { |
From: Martin <mar...@me...> - 2003-04-07 07:02:55
|
Quoting Dave Paris <dp...@w3...>: > > against stock RH8.0 install with dhcp, tftp-server, and nasm > installed. > > # rpm -i cluster-tools-0.9.6-1.i386.rpm > mv: cannot stat `/var/lib/nfs/statd': No such file or directory It looks like you don't have the package nfs-utils installed. Martin -- "Computer science is not about computers any more than astronomy is about telescopes." -- EW Dijkstra ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ |
From: Brian J. W. <Bri...@hp...> - 2003-04-16 03:02:32
|
Dave Paris wrote: > against stock RH8.0 install with dhcp, tftp-server, and nasm installed. > > # rpm -i cluster-tools-0.9.6-1.i386.rpm > mv: cannot stat `/var/lib/nfs/statd': No such file or directory > ln: creating symbolic link `/var/lib/nfs/statd' to `statd.{nodenum}': No > such file or directory > patch: **** Can't find file /etc/rc.d/init.d/nfslock : No such file or > directory > patching file /etc/rc.d/rc.sysinit This NFS stuff done by the cluster-tools RPM is rather hacky, escpecially the patching stuff. I think we should roll our own version of nfs-utils, instead. For the short-term, however, I'm making cluster-tools dependent on nfs-utils. That should avoid this problem. BTW, I'll comment on your addnode patch tomorrow. Remind me if I forget. ;) Brian |
From: Brian J. W. <Bri...@hp...> - 2003-04-19 00:42:10
|
Dave Paris wrote: > psst.. friendly reminder. ;-) Sorry I've been delinquent. ;) A better way to approach the problem might be to check a statd directory for an existing node, extract its uid and gid, and use them to make the statd directory for the new node. If no statd directories exist, that means nfs-utils wasn't installed and there's no need to make a new directory. The same logic could apply to network-scripts. Brian |
From: Aneesh K. K.V <ane...@di...> - 2003-04-19 11:26:38
|
On Sat, 2003-04-19 at 06:08, Brian J. Watson wrote: > Dave Paris wrote: > > psst.. friendly reminder. ;-) > > Sorry I've been delinquent. ;) > > A better way to approach the problem might be to check a statd directory > for an existing node, extract its uid and gid, and use them to make the > statd directory for the new node. Instead of extracting uid/gid. can't we do a cp -a of the directory ? > If no statd directories exist, that > means nfs-utils wasn't installed and there's no need to make a new > directory. This is how it is done in openssi_addnode. > The same logic could apply to network-scripts. > done in openssi_addnode. -aneesh |
From: Brian J. W. <Bri...@hp...> - 2003-04-21 21:07:04
|
Aneesh Kumar K.V wrote: > Instead of extracting uid/gid. can't we do a cp -a of the directory ? I don't think we want to copy the contents of the directory. We just want to create a new directory with the same mode, owner and group as the original. Brian |