[Cluster-devel] Building clufter on EL8
Hi all, While waiting to see what CentOS 8 will do with regard to HA, I decided to rebuild the rhel 8 packages for our own repo[1]. To this end, I've rebuilt all packages, except clufter. The clufter package relies on jing, and jing is not provided in RHEL 8. Obviously, clufter was build for RHEL 8, so I'm curious how this was done... I started the process of building jing myself, but very quickly fell into a very deep dependency well. Tips? -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould
Re: [Cluster-devel] [ClusterLabs] DLM connection channel switch take too long time (> 5mins)
On 2018-03-09 01:32 AM, Gang He wrote: > Hello Digimer, > > > >>>> >> On 2018-03-08 12:10 PM, David Teigland wrote: >>>> I use active rrp_mode in corosync.conf and reboot the cluster to let the >> configuration effective. >>>> But, the about 5 mins hang in new_lockspace() function is still here. >>> >>> The last time I tested connection failures with sctp was several years >>> ago, but I recall seeing similar problems. I had hoped that some of the >>> sctp changes might have helped, but perhaps they didn't. >>> Dave >> >> To add to this; We found serious issues with DLM over sctp/rrp. Our >> solution was to remove RRP and reply on active/passive (mode=1) bonding. >> I do not believe you can make anything using DLM reliable on RRP in >> either active or passive mode. > Do you have the detailed steps to describe this workaround? > My means is, how to remove RRP? and reply on active/passive (mode=1) bonding? > From the code, we have to use sctp protocol in DLM on a two-rings cluster. > > Thanks > Gang I'm using RHEL 6, so for me, disabling rrp was simply removing the rrp attribute and the child elements. As for bonding, here's how I did it; https://www.alteeve.com/w/AN!Cluster_Tutorial_2#Configuring_our_Bridge.2C_Bonds_and_Interfaces -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould
Re: [Cluster-devel] [ClusterLabs] DLM connection channel switch take too long time (> 5mins)
On 2018-03-08 12:10 PM, David Teigland wrote: >> I use active rrp_mode in corosync.conf and reboot the cluster to let the >> configuration effective. >> But, the about 5 mins hang in new_lockspace() function is still here. > > The last time I tested connection failures with sctp was several years > ago, but I recall seeing similar problems. I had hoped that some of the > sctp changes might have helped, but perhaps they didn't. > Dave To add to this; We found serious issues with DLM over sctp/rrp. Our solution was to remove RRP and reply on active/passive (mode=1) bonding. I do not believe you can make anything using DLM reliable on RRP in either active or passive mode. -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould
Re: [Cluster-devel] [ClusterLabs] Adding 'virsh migrate migrate-setspeed' support to the vm RA
On 14/09/15 07:19 AM, Dejan Muhamedagic wrote: > Hi Digimer, > > On Fri, Sep 04, 2015 at 03:36:09AM -0400, Digimer wrote: >> Hi all, >> >> I hit an issue a little while ago where live-migrating a VM (on the >> same management network normally used for corosync and a few other >> monitoring tasks) ate up all the bandwidth, causing corosync to declare >> a failure and triggering a fence. >> >> I've dealt with this, in part, by adding redundant ring support on a >> different network. However, I'd like to also limit the migration >> bandwidth so that I don't need to fail over the ring in the first place. > > As you certainly know, heavy traffic networks are not well suited > for the latency sensitive cluster communication. Best to have the > two separated. Oh for sure, but I've already hit 6 NICs per node (back-channel, normally just corosync, storage dedicated to DRBD and internet-facing dedicated to the user app). Adding two more NICs just for live migration, which happens very rarely, is hard to justify, despite this issue. If I can't reliably solve it with this (and/or tc and/or rrp...) then I will revisit this option. >> Is it reasonable/feasible to add 'virsh migrate-setspeed' support to >> the vm.sh RA? Something like; 'setspeed="75MiB"'? > > Yes, sounds like a good idea. Care to open an issue in github? > > Thanks, > > Dejan Done. https://github.com/ClusterLabs/resource-agents/issues/679 -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
[Cluster-devel] Adding 'virsh migrate migrate-setspeed' support to the vm RA
Hi all, I hit an issue a little while ago where live-migrating a VM (on the same management network normally used for corosync and a few other monitoring tasks) ate up all the bandwidth, causing corosync to declare a failure and triggering a fence. I've dealt with this, in part, by adding redundant ring support on a different network. However, I'd like to also limit the migration bandwidth so that I don't need to fail over the ring in the first place. Is it reasonable/feasible to add 'virsh migrate-setspeed' support to the vm.sh RA? Something like; 'setspeed="75MiB"'? -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] Mailing list moderated?
On 04/08/15 07:35 AM, Thomas Lamprecht wrote: Hello, I've now send to times patches for the GFS utils repository and the doesn't show up anywhere on the mailing list. Is it only for redhat or what's going on here, a bit confused. Regards, Thomas Hi Thomas, Most of the various cluster mailing lists are merging. Can you join these two and resend your patches to the devel list? http://clusterlabs.org/wiki/Mailing_lists -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] Mailing list moderated?
On 04/08/15 07:59 PM, Andrew Beekhof wrote: On 4 Aug 2015, at 11:37 pm, Andrew Price anpr...@redhat.com wrote: On 04/08/15 14:15, Digimer wrote: On 04/08/15 07:35 AM, Thomas Lamprecht wrote: Hello, I've now send to times patches for the GFS utils repository and the doesn't show up anywhere on the mailing list. Is it only for redhat or what's going on here, a bit confused. Regards, Thomas Hi Thomas, Most of the various cluster mailing lists are merging. Can you join these two and resend your patches to the devel list? http://clusterlabs.org/wiki/Mailing_lists We have no plans/motivation to move gfs2 development away from cluster-devel@ currently, so it's best to continue sending gfs2 and gfs2-utils patches here for the time being. Agreed. The consolidation was aimed more at the user lists. Works for me. I was only concerned about the user-side of things anyway, sorry for the confusion. -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] [Linux-cluster] gfs2-utils 3.1.8 released
Hi Andrew, Congrats!! Want to add the cluster labs mailing list to your list of release announcement locations? digimer On 07/04/15 01:03 PM, Andrew Price wrote: Hi, I am happy to announce the 3.1.8 release of gfs2-utils. This release includes the following visible changes: * Performance improvements in fsck.gfs2, mkfs.gfs2 and gfs2_edit savemeta. * Better checking of journals, the jindex, system inodes and inode 'goal' values in fsck.gfs2 * gfs2_jadd and gfs2_grow are now separate programs instead of symlinks to mkfs.gfs2. * Improved test suite and related documentation. * No longer clobbers the configure script's --sbindir option. * No longer depends on perl. * Various minor bug fixes and enhancements. See below for a complete list of changes. The source tarball is available from: https://fedorahosted.org/released/gfs2-utils/gfs2-utils-3.1.8.tar.gz Please test, and report bugs against the gfs2-utils component of Fedora rawhide: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedoracomponent=gfs2-utilsversion=rawhide Regards, Andy Changes since version 3.1.7: Abhi Das (6): fsck.gfs2: fix broken i_goal values in inodes gfs2_convert: use correct i_goal values instead of zeros for inodes tests: test for incorrect inode i_goal values mkfs.gfs2: addendum to fix broken i_goal values in inodes gfs2_utils: more gfs2_convert i_goal fixes gfs2-utils: more fsck.gfs2 i_goal fixes Andrew Price (58): gfs2-utils tests: Build unit tests with consistent cpp flags libgfs2: Move old rgrp layout functions into fsck.gfs2 gfs2-utils build: Add test coverage option fsck.gfs2: Fix memory leak in pass2 gfs2_convert: Fix potential memory leaks in adjust_inode gfs2_edit: Fix signed value used as array index in print_ld_blks gfs2_edit: Set umask before calling mkstemp in savemetaopen() gfs2_edit: Fix use-after-free in find_wrap_pt libgfs2: Clean up broken rgrp length check libgfs2: Remove superfluous NULL check from gfs2_rgrp_free libgfs2: Fail fd comparison if the fds are negative libgfs2: Fix check for O_RDONLY fsck.gfs2: Remove dead code from scan_inode_list mkfs.gfs2: Terminate lockproto and locktable strings explicitly libgfs2: Add generic field assignment and print functions gfs2_edit: Use metadata description to print and assign fields gfs2l: Switch to lgfs2_field_assign libgfs2: Remove device_name from struct gfs2_sbd libgfs2: Remove path_name from struct gfs2_sbd libgfs2: metafs_path improvements gfs2_grow: Don't use PATH_MAX in main_grow gfs2_jadd: Don't use fixed size buffers for paths libgfs2: Remove orig_journals from struct gfs2_sbd gfs2l: Check unchecked returns in openfs gfs2-utils configure: Fix exit with failure condition gfs2-utils configure: Remove checks for non-existent -W flags gfs2_convert: Don't use a fixed sized buffer for device path gfs2_edit: Add bounds checking for the journalN keyword libgfs2: Make find_good_lh and jhead_scan static Build gfs2_grow, gfs2_jadd and mkfs.gfs2 separately gfs2-utils: Honour --sbindir gfs2-utils configure: Use AC_HELP_STRING in help messages fsck.gfs2: Improve reporting of pass timings mkfs.gfs2: Revert default resource group size gfs2-utils tests: Add keywords to tests gfs2-utils tests: Shorten TESTSUITEFLAGS to TOPTS gfs2-utils tests: Improve docs gfs2-utils tests: Skip unit tests if check is not found gfs2-utils tests: Document usage of convenience macros fsck.gfs2: Fix 'initializer element is not constant' build error fsck.gfs2: Simplify bad_journalname gfs2-utils build: Add a configure script summary mkfs.gfs2: Remove unused declarations gfs2-utils/tests: Fix unit tests for older check libraries fsck.gfs2: Fix memory leaks in pass1_process_rgrp libgfs2: Use the correct parent for rgrp tree insertion libgfs2: Remove some obsolete function declarations gfs2-utils: Move metafs handling into gfs2/mkfs/ gfs2_grow/jadd: Use a matching context mount option in mount_gfs2_meta gfs2_edit savemeta: Don't read rgrps twice fsck.gfs2: Fetch directory inodes early in pass2() libgfs2: Remove some unused data structures gfs2-utils: Tidy up Makefile.am files gfs2-utils build: Remove superfluous passive header checks gfs2-utils: Consolidate some bad constants strings gfs2-utils: Update translation template libgfs2: Fix potential NULL deref in linked_leaf_search() gfs2_grow: Put back the definition of FALLOC_FL_KEEP_SIZE Bob Peterson (15): fsck.gfs2: Detect and correct corrupt journals fsck.gfs2: Change basic dentry checks for too long of file names
Re: [Cluster-devel] [Pacemaker] HA Summit Key-signing Party
On 02/02/15 11:48 AM, Jan Pokorný wrote: On 26/01/15 15:14 +0100, Jan Pokorný wrote: Timeline? Best if you send me your public keys before 2015-02-02. I will then compile a list of the attendees together with their keys and publish it at https://people.redhat.com/jpokorny/keysigning/2015-ha/ so you can print it out and be ready for the party. Thanks for your cooperation, looking forward to this side-event and hope this will be beneficial to all involved. Thanks for participating. Please print out https://people.redhat.com/jpokorny/keysigning/2015-ha/complete.html (best in landscape format), prior to checking your fingerprints there, indeed, prepare you ID document, and you are ready to proceed the signing event, which is currently planned on 2015-02-05 16:30 CET: http://plan.alteeve.ca/index.php/Main_Page#Feb_5th (I'll post an update should it change). Will there be a printer available in the room/area of the summit? If so, it might be good to set aside a bit of time to help people new to PGP get setup before the actual key-signing. -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] [Pacemaker] HA Summit Key-signing Party
On 26/01/15 09:14 AM, Jan Pokorný wrote: Hello cluster masters, On 13/01/15 00:31 -0500, Digimer wrote: Any concerns/comments/suggestions, please speak up ASAP! I'd like to throw a key-signing party as it will be a perfect opportunity to build a web of trust amongst us. If you haven't incorporated OpenPGP to your communication with the world yet, I would recommend at least considering it, even more in the post-Snowden era. You can use it to prove authenticity/integrity of the data you emit (signing; not just for email as is the case with this one, but also for SW releases and more), provide privacy/confidentiality of interchanged data (encryption; again, typical scenario is a private email, e.g., when you responsibly report a vulnerability to the respective maintainers), or both. In case you have no experience with this technology, there are plentiful resources on GnuPG (most renowned FOSS implementation): - https://www.gnupg.org/documentation/howtos.en.html - http://cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html#prep (preparation steps for a key-signing party) - ... To make the verification process as smooth and as little time-consuming as possible, I would stick with a list-based method: http://cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html#list_based and volunteer for a role of a coordinator. What's needed? Once you have a key pair (and provided that you are using GnuPG), please run the following sequence: # figure out the key ID for the identity to be verified; # IDENTITY is either your associated email address/your name # if only single key ID matches, specific key otherwise # (you can use gpg -K to select a desired ID at the sec line) KEY=$(gpg --with-colons 'IDENTITY' | grep '^pub' | cut -d: -f5) # export the public key to a file that is suitable for exchange gpg --export -a -- $KEY $KEY # verify that you have an expected data to share gpg --with-fingerprint -- $KEY with IDENTITY adjusted as per the instruction above, and send me the resulting $KEY file, preferably in a signed (or even encrypted[*]) email from an address associated with that very public key of yours. [*] You can find my public key at public keyservers: http://pool.sks-keyservers.net/pks/lookup?op=vindexsearch=0x60BCBB4F5CD7F9EF Indeed, the trust in this key should be ephemeral/one-off (e.g., using a temporary keyring, not a universal one before we proceed with the signing :) Timeline? Best if you send me your public keys before 2015-02-02. I will then compile a list of the attendees together with their keys and publish it at https://people.redhat.com/jpokorny/keysigning/2015-ha/ so you can print it out and be ready for the party. Thanks for your cooperation, looking forward to this side-event and hope this will be beneficial to all involved. P.S. There's now an opportunity to visit an exhibition of the Bohemian Crown Jewels replicas directly in Brno (sorry, Google Translate only) https://translate.google.com/translate?sl=autotl=enjs=yprev=_thl=enie=UTF-8u=http%3A%2F%2Fwww.letohradekbrno.cz%2F%3Fidm%3D55 =o, keysigning is a brilliant idea! I can put the keys in the plan wiki, too. -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] [Pacemaker] [Linux-HA] [ha-wg-technical] [RFC] Organizing HA Summit 2015
Woohoo!! Will be very nice to see you. :) I've added you. Can you give me a short sentence to introduce yourself to people who haven't met you? Madi On 13/01/15 11:33 PM, Yusuke Iida wrote: Hi Digimer, I am Iida to participate from NTT along with Mori. I want you added to the list of participants. I'm sorry contact is late. Regards, Yusuke 2014-12-23 2:13 GMT+09:00 Digimer li...@alteeve.ca: It will be very nice to see you again! Will Ikeda-san be there as well? digimer On 22/12/14 03:35 AM, Keisuke MORI wrote: Hi all, Really late response but, I will be joining the HA summit, with a few colleagues from NTT. See you guys in Brno, Thanks, 2014-12-08 22:36 GMT+09:00 Jan Pokorný jpoko...@redhat.com: Hello, it occured to me that if you want to use the opportunity and double as as tourist while being in Brno, it's about the right time to consider reservations/ticket purchases this early. At least in some cases it is a must, e.g., Villa Tugendhat: http://rezervace.spilberk.cz/langchange.aspx?mrsname=languageId=2returnUrl=%2Flist On 08/09/14 12:30 +0200, Fabio M. Di Nitto wrote: DevConf will start Friday the 6th of Feb 2015 in Red Hat Brno offices. My suggestion would be to have a 2 days dedicated HA summit the 4th and the 5th of February. -- Jan ___ ha-wg-technical mailing list ha-wg-techni...@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/ha-wg-technical -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education? ___ Linux-HA mailing list linux...@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
[Cluster-devel] HA Summit 2015 - plan wiki closed for registration
Spammers got through the captcha, *sigh*. If anyone wants to create an account to edit, please email me off-list and I'll get you setup ASAP. Sorry for the hassle. http://plan.alteeve.ca/index.php/Main_Page -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] [ha-wg-technical] [Pacemaker] [RFC] Organizing HA Summit 2015
It will be very nice to see you again! Will Ikeda-san be there as well? digimer On 22/12/14 03:35 AM, Keisuke MORI wrote: Hi all, Really late response but, I will be joining the HA summit, with a few colleagues from NTT. See you guys in Brno, Thanks, 2014-12-08 22:36 GMT+09:00 Jan Pokorný jpoko...@redhat.com: Hello, it occured to me that if you want to use the opportunity and double as as tourist while being in Brno, it's about the right time to consider reservations/ticket purchases this early. At least in some cases it is a must, e.g., Villa Tugendhat: http://rezervace.spilberk.cz/langchange.aspx?mrsname=languageId=2returnUrl=%2Flist On 08/09/14 12:30 +0200, Fabio M. Di Nitto wrote: DevConf will start Friday the 6th of Feb 2015 in Red Hat Brno offices. My suggestion would be to have a 2 days dedicated HA summit the 4th and the 5th of February. -- Jan ___ ha-wg-technical mailing list ha-wg-techni...@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/ha-wg-technical -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] [ha-wg-technical] Wiki for planning created - Re: [Pacemaker] [RFC] Organizing HA Summit 2015
On 27/11/14 11:52 AM, Digimer wrote: I just created a dedicated/fresh wiki for planning and organizing: http://plan.alteeve.ca/index.php/Main_Page Other than the domain, it has no association with any existing project, so it should be a neutral enough platform. Also, it's not owned by $megacorp (I wish!), so spying/privacy shouldn't be an issue I hope. If there is concern, I can setup https. If no one else gets to it before me, I'll start collating the data from the mailing list onto that wiki tomorrow (maaaybe today, depends). The wiki requires registration, but that's it. I'm not bothering with captchas because, in my experience, spammer walk right through them anyway. I do have edits email me, so I can catch and roll back any spam quickly. Ok, I was getting 3~5 spam accounts created per day. To deal with this, I setup 'questy' captcha program with five (random) questions that should be easy to answer, even for non-english speakers. Just the same, if anyone has any trouble registering, please feel free to email me directly and I will be happy to help. Madi -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] [Pacemaker] Wiki for planning created - Re: [RFC] Organizing HA Summit 2015
On 29/11/14 12:45 AM, Fabio M. Di Nitto wrote: On 11/28/2014 8:10 PM, Jan Pokorný wrote: On 28/11/14 00:37 -0500, Digimer wrote: On 28/11/14 12:33 AM, Fabio M. Di Nitto wrote: On 11/27/2014 5:52 PM, Digimer wrote: I just created a dedicated/fresh wiki for planning and organizing: http://plan.alteeve.ca/index.php/Main_Page [...] Awesome! thanks for taking care of it. Do you have a chance to add also an instance of etherpad to the site? Mostly to do collaborative editing while we sit all around the same table. Otherwise we can use a public instance and copy paste info after that in the wiki. Never tried setting up etherpad before, but if it runs on rhel 6, I should have no problem setting it up. Provided no conspiracy to be started, there are a bunch of popular instances, e.g. http://piratepad.net/ Right, some of them only store etherpads for 30 days. Just be careful the one we choose or we make our own. Fabio I'll set one up, but I'll need a few days, I'm out of the country at the moment. It's not needed until the conference, is it? Or will you want to have it before then? -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
[Cluster-devel] Wiki for planning created - Re: [Pacemaker] [RFC] Organizing HA Summit 2015
I just created a dedicated/fresh wiki for planning and organizing: http://plan.alteeve.ca/index.php/Main_Page Other than the domain, it has no association with any existing project, so it should be a neutral enough platform. Also, it's not owned by $megacorp (I wish!), so spying/privacy shouldn't be an issue I hope. If there is concern, I can setup https. If no one else gets to it before me, I'll start collating the data from the mailing list onto that wiki tomorrow (maaaybe today, depends). The wiki requires registration, but that's it. I'm not bothering with captchas because, in my experience, spammer walk right through them anyway. I do have edits email me, so I can catch and roll back any spam quickly. -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] Wiki for planning created - Re: [Pacemaker] [RFC] Organizing HA Summit 2015
On 28/11/14 12:33 AM, Fabio M. Di Nitto wrote: On 11/27/2014 5:52 PM, Digimer wrote: I just created a dedicated/fresh wiki for planning and organizing: http://plan.alteeve.ca/index.php/Main_Page Other than the domain, it has no association with any existing project, so it should be a neutral enough platform. Also, it's not owned by $megacorp (I wish!), so spying/privacy shouldn't be an issue I hope. If there is concern, I can setup https. If no one else gets to it before me, I'll start collating the data from the mailing list onto that wiki tomorrow (maaaybe today, depends). The wiki requires registration, but that's it. I'm not bothering with captchas because, in my experience, spammer walk right through them anyway. I do have edits email me, so I can catch and roll back any spam quickly. Awesome! thanks for taking care of it. Do you have a chance to add also an instance of etherpad to the site? Mostly to do collaborative editing while we sit all around the same table. Otherwise we can use a public instance and copy paste info after that in the wiki. Fabio Never tried setting up etherpad before, but if it runs on rhel 6, I should have no problem setting it up. -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] [ha-wg-technical] [Linux-HA] [ha-wg] [RFC] Organizing HA Summit 2015
On 25/11/14 04:31 PM, Andrew Beekhof wrote: Yeah, but you're already bringing him for your personal conference. That's a bit different. ;-) OK, let's switch tracks a bit. What *topics* do we actually have? Can we fill two days? Where would we want to collect them? Personally I'm interested in talking about scaling - with pacemaker-remoted and/or a new messaging/membership layer. Other design-y topics: - SBD - degraded mode - improved notifications This my be something my company can bring to the table. We just hired a dev whose principle goal is to develop and alert system for HA. We're modelling it heavily on the fence/resource agent model with a scan core and scan agents. It's sort of like existing tools, but designed specifically for HA clusters and heavily focused on not interfering with the host more than at all necessary. By Feb., it should be mostly done. We're doing this for our own needs, but it might be a framework worth talking about, if nothing else to see if others consider it a fit. Of course, it will be entirely open source. *If* there is interest, I could put together a(n informal) talk on it with a demo. - containerisation of services (cgroups, docker, virt) - resource-agents (upstream releases, handling of pull requests, testing) User-facing topics could include recent features (ie. pacemaker-remoted, crm_resource --restart) and common deployment scenarios (eg. NFS) that people get wrong. -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] [ha-wg] [Linux-HA] [RFC] Organizing HA Summit 2015
On 26/11/14 12:51 AM, Fabio M. Di Nitto wrote: On 11/25/2014 10:54 AM, Lars Marowsky-Bree wrote: On 2014-11-24T16:16:05, Fabio M. Di Nitto fdini...@redhat.com wrote: Yeah, well, devconf.cz is not such an interesting event for those who do not wear the fedora ;-) That would be the perfect opportunity for you to convert users to Suse ;) I´d prefer, at least for this round, to keep dates/location and explore the option to allow people to join remotely. Afterall there are tons of tools between google hangouts and others that would allow that. That is, in my experience, the absolute worst. It creates second class participants and is a PITA for everyone. I agree, it is still a way for people to join in tho. I personally disagree. In my experience, one either does a face-to-face meeting, or a virtual one that puts everyone on the same footing. Mixing both works really badly unless the team already knows each other. I know that an in-person meeting is useful, but we have a large team in Beijing, the US, Tasmania (OK, one crazy guy), various countries in Europe etc. Yes same here. No difference.. we have one crazy guy in Australia.. Yeah, but you're already bringing him for your personal conference. That's a bit different. ;-) OK, let's switch tracks a bit. What *topics* do we actually have? Can we fill two days? Where would we want to collect them? I´d say either a google doc or any random etherpad/wiki instance will do just fine. As for the topics: - corosync qdevice and plugins (network, disk, integration with sdb?, others?) - corosync RRP / libknet integration/replacement - fence autodetection/autoconfiguration For the user facing topics (that is if there are enough participants and I only got 1 user confirmation so far): - demos, cluster 101, tutorials - get feedback - get feedback - get more feedback Fabio I'd be happy to do a cluster 101 or similar, if there is interest. Not sure if that would be particularly appealing to anyone coming to our meeting, as I think anyone interested is probably well past 101. :) Anyway, you guys know my background, let me know if there is a topic you'd like me to cover for the user side of things. -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] [ha-wg-technical] [ha-wg] [Linux-HA] [RFC] Organizing HA Summit 2015
On 26/11/14 12:51 AM, Fabio M. Di Nitto wrote: On 11/25/2014 10:54 AM, Lars Marowsky-Bree wrote: On 2014-11-24T16:16:05, Fabio M. Di Nitto fdini...@redhat.com wrote: Yeah, well, devconf.cz is not such an interesting event for those who do not wear the fedora ;-) That would be the perfect opportunity for you to convert users to Suse ;) I´d prefer, at least for this round, to keep dates/location and explore the option to allow people to join remotely. Afterall there are tons of tools between google hangouts and others that would allow that. That is, in my experience, the absolute worst. It creates second class participants and is a PITA for everyone. I agree, it is still a way for people to join in tho. I personally disagree. In my experience, one either does a face-to-face meeting, or a virtual one that puts everyone on the same footing. Mixing both works really badly unless the team already knows each other. I know that an in-person meeting is useful, but we have a large team in Beijing, the US, Tasmania (OK, one crazy guy), various countries in Europe etc. Yes same here. No difference.. we have one crazy guy in Australia.. Yeah, but you're already bringing him for your personal conference. That's a bit different. ;-) OK, let's switch tracks a bit. What *topics* do we actually have? Can we fill two days? Where would we want to collect them? I´d say either a google doc or any random etherpad/wiki instance will do just fine. As for the topics: - corosync qdevice and plugins (network, disk, integration with sdb?, others?) - corosync RRP / libknet integration/replacement - fence autodetection/autoconfiguration For the user facing topics (that is if there are enough participants and I only got 1 user confirmation so far): - demos, cluster 101, tutorials - get feedback - get feedback - get more feedback Fabio Ok, I do have a topic I want to add; Merging the dozen different mailing lists, IRC channels and other support forums. This thread is a good example of the thinness that the community is spread over. A 'dev', 'user', 'announce' list should be enough for all HA. Likewise, one IRC channel should be enough, too. The trick will be discussing this without bikeshedding. :) digimer -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] [Pacemaker] [ha-wg] [RFC] Organizing HA Summit 2015
On 24/11/14 09:54 AM, Fabio M. Di Nitto wrote: On 11/24/2014 3:39 PM, Lars Marowsky-Bree wrote: On 2014-09-08T12:30:23, Fabio M. Di Nitto fdini...@redhat.com wrote: Folks, Fabio, thanks for organizing this and getting the ball rolling. And again sorry for being late to said game; I was busy elsewhere. However, it seems that the idea for such a HA Summit in Brno/Feb 2015 hasn't exactly fallen on fertile grounds, even with the suggested user/client day. (Or if there was a lot of feedback, it wasn't public.) I wonder why that is, and if/how we can make this more attractive? I suspect a lot of it is that, given people's busy schedules, February seems far away. Also, I wonder how much discussion has happened outside of these lists. Is it really that there hasn't been much feedback? Fabio started this ball rolling, so I would be interested to hear what he's heard. Frankly, as might have been obvious ;-), for me the venue is an issue. It's not easy to reach, and I'm theoretically fairly close in Germany already. I wonder if we could increase participation with a virtual meeting (on either those dates or another), similar to what the Ceph Developer Summit does? Requested feedback given; Virtual meetings are never as good, and I really don't like this idea. In my experience, just as much productive decision making happens in the unofficial after-hours activities as during formal(ish) meetings/presentations. I think it is very important that the meeting remain in-person if at all possible. Those appear really productive and make it possible for a wide range of interested parties from all over the world to attend, regardless of travel times, or even just attend select sessions (that would otherwise make it hard to justify travel expenses time off). Alternatively, would a relocation to a more connected venue help, such as Vienna xor Prague? Personally, I don't care where we meet, but I do believe Fabio already ruled out a relocation. I'd love to get some more feedback from the community. I agree. some feedback would be useful. digimer puts on her flame-retardant pantaloons and waits for the worst... -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] [Pacemaker] [ha-wg] [RFC] Organizing HA Summit 2015
On 24/11/14 10:12 AM, Lars Marowsky-Bree wrote: Beijing, the US, Tasmania (OK, one crazy guy), various countries in Oh, bring him! crazy++ -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] [Linux-HA] [ha-wg] [RFC] Organizing HA Summit 2015
All the cool kids will be there. You want to be a cool kid, right? :p On 01/11/14 01:06 AM, Fabio M. Di Nitto wrote: just a kind reminder. On 9/8/2014 12:30 PM, Fabio M. Di Nitto wrote: All, it's been almost 6 years since we had a face to face meeting for all developers and vendors involved in Linux HA. I'd like to try and organize a new event and piggy-back with DevConf in Brno [1]. DevConf will start Friday the 6th of Feb 2015 in Red Hat Brno offices. My suggestion would be to have a 2 days dedicated HA summit the 4th and the 5th of February. The goal for this meeting is to, beside to get to know each other and all social aspect of those events, tune the directions of the various HA projects and explore common areas of improvements. I am also very open to the idea of extending to 3 days, 1 one dedicated to customers/users and 2 dedicated to developers, by starting the 3rd. Thoughts? Fabio PS Please hit reply all or include me in CC just to make sure I'll see an answer :) [1] http://devconf.cz/ Could you please let me know by end of Nov if you are interested or not? I have heard only from few people so far. Cheers Fabio ___ Linux-HA mailing list linux...@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] [Pacemaker] [RFC] Organizing HA Summit 2015
On 08/09/14 06:30 AM, Fabio M. Di Nitto wrote: All, it's been almost 6 years since we had a face to face meeting for all developers and vendors involved in Linux HA. I'd like to try and organize a new event and piggy-back with DevConf in Brno [1]. DevConf will start Friday the 6th of Feb 2015 in Red Hat Brno offices. My suggestion would be to have a 2 days dedicated HA summit the 4th and the 5th of February. The goal for this meeting is to, beside to get to know each other and all social aspect of those events, tune the directions of the various HA projects and explore common areas of improvements. I am also very open to the idea of extending to 3 days, 1 one dedicated to customers/users and 2 dedicated to developers, by starting the 3rd. Thoughts? Fabio PS Please hit reply all or include me in CC just to make sure I'll see an answer :) [1] http://devconf.cz/ How is this looking? -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] [Pacemaker] [Linux-HA] [RFC] Organizing HA Summit 2015
On 09/09/14 12:36 PM, Fabio M. Di Nitto wrote: On 09/09/2014 06:31 PM, Alan Robertson wrote: My apologizes for spamming everyone. I thought I deleted all the other email addresses. I failed. Apologies :-( I think it's good that we have an open discussion with all parties involved. I hardly fail to see that as an issue. Apologies not accepted ;) Fabio +1 to err'ing on the side of too much talk. :) -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] [Pacemaker] [RFC] Organizing HA Summit 2015
On 08/09/14 06:30 AM, Fabio M. Di Nitto wrote: All, it's been almost 6 years since we had a face to face meeting for all developers and vendors involved in Linux HA. I'd like to try and organize a new event and piggy-back with DevConf in Brno [1]. DevConf will start Friday the 6th of Feb 2015 in Red Hat Brno offices. My suggestion would be to have a 2 days dedicated HA summit the 4th and the 5th of February. The goal for this meeting is to, beside to get to know each other and all social aspect of those events, tune the directions of the various HA projects and explore common areas of improvements. I am also very open to the idea of extending to 3 days, 1 one dedicated to customers/users and 2 dedicated to developers, by starting the 3rd. Thoughts? Fabio PS Please hit reply all or include me in CC just to make sure I'll see an answer :) [1] http://devconf.cz/ I think this is a good idea. 3 days may be a good idea, as well. I think I would be more useful trying to bring the user's perspective more so than a developer's. So on that, I would like to propose a discussion on merging some of the disparate lists, channels, sites, etc. to help simplify life for new users looking for help from or to wanting to join the HA community. I also understand that Fabio will buy the first round of drinks. :) -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] fence-agents-4.0.2 stable release
On 30/07/13 07:00, Marek Grac wrote: Welcome to the fence-agents 4.0.2 release. This release includes a minor bug fix, invalid names in fence_eps, fence_rhevm and fence_xenapi. In this release you can also find a new fence agent for OVH (http://www.ovh.com) and symbolic link fence_ilo4 which runs fence_ipmilan with required arguments. For the 4.0.x series, I plan to release a new version on at least monthly basis. The new source tarball can be downloaded here: https://fedorahosted.org/releases/f/e/fence-agents/fence-agents-4.0.1.tar.xz To report bugs or issues: https://bugzilla.redhat.com/ Would you like to meet the cluster team or members of its community? Join us on IRC (irc.freenode.net #linux-cluster) and share your experience with other sysadministrators or power users. Thanks/congratulations to all people that contributed to achieve this great milestone. m, Yet another release goes by and I didn't get around to asking for a new agent to be added. :) I've got a fence agent for TrippLite switched PDUs; https://github.com/digimer/fence_tripplite_snmp They're hardly ideal as fence devices because they are slow, but they do work reliably and their cost makes them very common in DCs. Also, \o/ new release! -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] Problems in fence_drac.8, fence_na.8, fence_drac5.8
The Node Assassin project has been on extended hiatus. I would say that you should remote fence_na for now. If/when it restarts, I'll request re-adding it. Cheers On 06/18/2013 01:14 AM, e...@thyrsus.com wrote: This is automatically generated email about markup problems in a man page for which you appear to be responsible. If you are not the right person or list, please tell me so I can correct my database. See http://catb.org/~esr/doclifter/bugs.html for details on how and why these patches were generated. Feel free to email me with any questions. Note: These patches do not change the modification date of any manual page. You may wish to do that by hand. I apologize if this message seems spammy or impersonal. The volume of markup bugs I am tracking is over five hundred - there is no real alternative to generating bugmail from a database and template. -- Eric S. Raymond Problems with fence_drac.8: Ambiguous or invalid backslash. This doesn't cause groff a problem. but it confuses doclifter and may confuse older troff implementations. --- fence_drac.8-unpatched2012-06-27 21:42:05.566240179 -0400 +++ fence_drac.8 2012-06-27 21:42:57.718239206 -0400 @@ -73,10 +73,10 @@ \fIagent = param \fR This option is used by fence_node(8) and is ignored by fence_apc. .TP -\fIcmd_prompt = param \fr +\fIcmd_prompt = param \fR Force fence_drac to use cmd_prompt as the command prompt .TP -\fIdrac_version = param \fr +\fIdrac_version = param \fR Force fence_drac to treat the device as though it was for the specified drac version. .TP \fIdebug = dumpfile \fR @@ -88,7 +88,7 @@ \fIlogin = param \fR Login name. .TP -\fImodulename = param \fr +\fImodulename = param \fR The module name of the blade when using DRAC/MC firmware. .TP \fIpasswd = param \fR Problems with fence_drac5.8: Ambiguous or invalid backslash. This doesn't cause groff a problem. but it confuses doclifter and may confuse older troff implementations. --- fence_drac5.8-unpatched 2012-07-20 08:26:46.593786658 -0400 +++ fence_drac5.8 2012-07-20 08:27:00.557786903 -0400 @@ -44,7 +44,7 @@ .TP .B -c, --command-prompt=prompt . -Force command prompt (Default Value: \$) +Force command prompt (Default Value: \\$) .TP .B -x, --ssh @@ -198,7 +198,7 @@ .TP .B cmd_prompt . -Force command prompt (Default Value: \$) +Force command prompt (Default Value: \\$) .TP .B secure Problems with fence_na.8: Missing or garbled name section. The most common form of garbling is a missing - or extra -. Or your manual page may have been generated by a tool that doesn't emit a NAME section as it should. Or your page may add running text such as a version or authorship banner. These problems make it impossible to lift the page to DocBook. They can also confuse third-party manpage browsers and some implementations of man -k. This page was generated from some sort of non-man markup. Please fix the upstream markup so that it generates a well-formed manual page with the indicated corrections. --- fence_na.8-unpatched 2012-07-04 16:06:48.253591845 -0400 +++ fence_na.82012-07-04 16:07:34.345590983 -0400 @@ -130,9 +130,7 @@ .if n .ad l .nh .SH NAME -fence_na -.PP -This is the fence agent for the Node Assassin fence device. +fence_na \- fence agent for the the Node Assassin fence device. .SH SYNOPSIS .IX Header SYNOPSIS .Vb 1 -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Re: [Cluster-devel] Fence agents - supported fence devices in next major release
On 11/25/2012 09:56 AM, Fabio M. Di Nitto wrote: On 11/25/2012 02:55 PM, Marek Grac wrote: Hi, In next major version of fence agents we would like to include only those fence agents which are used and can be tested. We have access to various fence devices but there is still need for more and we would like to include you and your hardware in testing process. Testing process will follow of creating simple configuration file for your device (almost copypaste from cluster.conf) and running simple script ( 5 minutes). We believe that with yours help we will be able to test more devices and make upstream code even better. We are looking for these fence devices (and their owners) used by following fence agents: * fence_baytech * fence_bullpap * fence_vixel * fence_zvm * fence_cpint * fence_rackswitch * fence_brocade * fence_mcdata Thanks for you help. If you would like to help with testing please send me a mail directly. We can probably drop fence_na too from this list. Hardware has not made production and I don't think it will happen in any short time. Digimer? Fabio Ya, drop it. I am still trying to finish it, but it's not a priority. I can always move it back in later. -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
[Cluster-devel] [ Spam ] Re: Rebélate by self-management, first project of free software by which we bet all / Rebélate por la autogestión, primer proyecto de software libre por el que apostamos toda
On 03/02/2012 01:50 PM, Orquidea Salt mas wrote: Inglés : Many already we have contributed to the first project of free software dedicated to self-management in this campaign of collective financing, it collaborates and it spreads!/ This jerk has been spamming every mailing list I am on. Personally, I'd love to see this project completely ignored and this user kicked from the list. /rant -- Digimer E-Mail: digi...@alteeve.com Papers and Projects: https://alteeve.com
Re: [Cluster-devel] 3.1.8 rc fails to validate IP resources
On 12/04/2011 03:12 AM, Fabio M. Di Nitto wrote: On 12/03/2011 11:34 PM, Digimer wrote: Looks like the IP section was not added to cluster.rng. You need to install latest and greatest resource-agents :) Fabio Now *that's* just embarrassing! :P -- Digimer E-Mail: digi...@alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org omg my singularity battery is dead again. stupid hawking radiation. - epitron
Re: [Cluster-devel] cluster: STABLE31 - Changes the kernel version check to handle 3.x.y kernels. Now if the 'x' version of the running kernel is higher than the 'x' version of the minimum kernel, the
On 12/04/2011 03:14 AM, Fabio M. Di Nitto wrote: On 12/03/2011 07:48 PM, Madison Kelly wrote: Gitweb: http://git.fedorahosted.org/git/cluster.git?p=cluster.git;a=commitdiff;h=9be00f89c9b3d9670cbd73525d4c41440a37b08a Commit:9be00f89c9b3d9670cbd73525d4c41440a37b08a Parent:991bfb0b1f547da5314141fcd79e0ea2253f78f4 Author:Digital Mermaid digi...@lework.alteeve.com AuthorDate:Sat Dec 3 12:53:15 2011 -0500 Committer: Digital Mermaid digi...@lework.alteeve.com CommitterDate: Sat Dec 3 12:53:15 2011 -0500 Changes the kernel version check to handle 3.x.y kernels. Now if the 'x' version of the running kernel is higher than the 'x' version of the minimum kernel, the test passes. Also changed the method of checking that version numbers were gathered so that a version number of '0' would be seen as valid. Signed-off-by: Digital Mermaid digi...@lework.alteeve.com Minor nit-pick. git is smart when handling the changelog entry. First line: short log rest of the body .. long explanation of the change Signed-off... The Short log is also used for email subjects on commit/push. Otherwise it gets a bit too long ;) remember to break at 80 cols more or less. Fabio Heh, ya, as soon as I saw the email I realized what was happening. -ENOOB :) -- Digimer E-Mail: digi...@alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org omg my singularity battery is dead again. stupid hawking radiation. - epitron
[Cluster-devel] 3.1.8 rc fails to validate IP resources
Looks like the IP section was not added to cluster.rng. -- Digimer E-Mail: digi...@alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org omg my singularity battery is dead again. stupid hawking radiation. - epitron
[Cluster-devel] patch for cluster 3.1.8's 'configure'
This patch fixes two small bugs in cluster's configure script;
1. When checking the x.y.z kernel version values, it changes the '!$foo'
to 'not defined $foo'. This is because a version number of '0' matches
not (!$foo). A safer but slower approach would be to do '$foo =~
/^\d+$/'. Not sure which is preferred.
2. Added a check where if 'x' in 'x.y.z' is greater in the detected
kernel than in the minimum required kernel, the test passes. This
handles 3.x kernels where the minimum is 2.y.
I tested this patch against Fedora 16 x86-64 and Ubuntu 11.10 amd64.
--
Digimer
E-Mail: digi...@alteeve.com
Freenode handle: digimer
Papers and Projects: http://alteeve.com
Node Assassin: http://nodeassassin.org
omg my singularity battery is dead again.
stupid hawking radiation. - epitron
--- configure.orig 2011-12-02 00:20:04.513600907 -0500
+++ configure 2011-12-02 00:30:49.025600160 -0500
@@ -254,13 +254,14 @@
}
close MAKEFILE;
# Warn and continue if kernel version was not found
-if (!$build_version || !$build_patchlevel || !$build_sublevel) {
+if (not defined $build_version || not defined $build_patchlevel || not defined $build_sublevel) {
print WARNING: Could not determine kernel version.\n;
print Build might fail!\n;
return 1;
}
# checking VERSION, PATCHLEVEL and SUBLEVEL for the supplied kernel
-if ($build_version = $version[0]
+if (($build_version $version[0]) ||
+$build_version == $version[0]
$build_patchlevel = $version[1]
$build_sublevel = $version[2]) {
print Current kernel version appears to be OK\n;
Re: [Cluster-devel] RFC: generic improvement to fence agents api
On 03/21/2011 01:07 PM, David Teigland wrote: On Sat, Mar 19, 2011 at 07:34:55AM +0100, Fabio M. Di Nitto wrote: My suggestion would be to allow to specify a list of ports instead. This comes up now and then. The current rule of one action per agent execution is a tried and true, fundamental property of the agent api. It should not be changed IMO. I'll need some time to come up with the various specific reasons against it, but at least one of them (a big one) is partial failure/success. Dave Could it not be set so that anything shy of a complete success is treated as a failure? -- Digimer E-Mail: digi...@alteeve.com AN!Whitepapers: http://alteeve.com Node Assassin: http://nodeassassin.org
Re: [Cluster-devel] RFC: generic improvement to fence agents api
On 03/19/2011 02:34 AM, Fabio M. Di Nitto wrote: Hi all, while discussing on linux-cluster the support of the Tripp Lite switched PDU, it occurred to me that we can effectively improve (almost half) the time it takes to perform power fencing of certain devices, when for example, more than one PSU needs to be powered off to complete the action. Node X has 2 PSU. In our current state, the config would look like: clusternode . fence method... device name=... port=1/ device name=... port=2/ . it means effectively spawning, most likely the same agent, twice. Increasing the time it takes to fence and maybe increasing the possibility to fail to fence if the second connection fails. My suggestion would be to allow to specify a list of ports instead. clusternode . fence method... device name=... ports=1 2/ Either by using a new keyword ports or re-using port itself. If using port, current configuration will continue to work as-is and the change effectively would not introduce any backward compatibility issue. This way the agent can: 1) connect once (reducing in most cases the ssh/telnet/whatever time) 2) issue the OFF command as fast as possible (almost in parallel) 3) then wait for the results. By adopting a list, the configuration would look cleaner too IMHO. A quick glance, the change should not affect fenced (David can you confirm please?), and most agents could handle it via the fencing python lib (Marek?). Does it sound reasonable? Cheers Fabio I like this idea, but would like to suggest: * Keep 'port' for a single port, as it is, and add 'ports' for multiple port definitions. * When using ports, I'd recommend comma-separated values and dash-separated ranges (ie: ports=1,2, ports=1-4, ports=1,3-5) and combinations there-of. This strikes me as more standard and possibly less prone to typos. -- Digimer E-Mail: digi...@alteeve.com AN!Whitepapers: http://alteeve.com Node Assassin: http://nodeassassin.org
