Re: [CentOS] Configuring source-specific routing
On 05/03/2013 06:05 PM, Rob Townley wrote: > Michael, very frustrating that so much noise for a very simple request. I > set up multi source routing in 5.3 or so and was astounded at all the > negativity on this list and that it could not be done. It will take > forever to read the noise in this thread alone. Some said you have to use > DHCP i could go on. > > Do not trust that ping -I will work how you would think. Must specify an > IP address, not eth0, not eth1. > ping -I 10.0.0.1 8.8.8.8 Yup. Sans the obfuscated IP address, that's exactly what I tested. > > This really is just a few lines per interface. > > Learn by changing the /etc/sysconfig/network-scripts/ifup-route shell > scripts to add logging. > echo out variables. I tried adding "set -x" to them. :) > > There is no need to get iptables involved at all unless doing something > very special. > > i did not want to setup quagga or some form of dynamic routing deamon > because of security concerns. i wanted static IP addresses communicating > to the ISP on static routes. It is pretty simple. Maybe i can hook up my > laptop to 3G and WiFi and Cat6 and make sure i get it working. Please > remember to use IP addresses, not names for ping testing. Scrutinize ping > results. > > ping -I 10.0.0.1 8.8.8.8 Yeah, I don't see a use for quagga at this time. [snip] signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Configuring source-specific routing
On 05/03/2013 05:06 PM, Ljubomir Ljubojevic wrote: > On 05/02/2013 08:48 PM, Michael Mol wrote: [snip] > > Alternate source routing, firewall and netfilter marking of packets: > > > iptables -t mangle -A PREROUTING -s 172.24.5.0/24 -j MARK --set-mark 100 # > iptables -t mangle -A PREROUTING -s 192.168.150.107 -j MARK --set-mark > 200 # > iptables -t mangle -A PREROUTING -s 192.168.150.224 -j MARK --set-mark 100 > > > # Local network > iptables -t mangle -A PREROUTING -d 192.168.0.0/16 -j MARK --set-mark 20 > iptables -t mangle -A PREROUTING -d 172.16.0.0/12 -j MARK --set-mark 20 > iptables -t mangle -A PREROUTING -s -d 192.168.0.0/16 -j MARK > --set-mark 20 > iptables -t mangle -A PREROUTING -s -d 172.16.0.0/12 -j MARK > --set-mark 20 > > And then something like: > > # echo 201 mail.out >> /etc/iproute2/rt_tables > # ip rule add fwmark 1 table mail.out > # /sbin/ip route add default via 195.96.98.253 dev eth0 table mail.out > > (http://lartc.org/howto/lartc.netfilter.html). > > Used firewall rules are from StarOS router OS that has simple script for > policy routing so that second part with ip rule and ip route is just a > pointer in right direction. I don't figure I want to use the mangle table for this. Though thanks for the example code; that will come in handy for tc. Just need how to work that in with sanewall. I think I know what I did wrong, but it's going to be a while before I can test it. (Dang, I wish I had enough spare hardware at home to set up a test lab.) signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Configuring source-specific routing
Michael, very frustrating that so much noise for a very simple request. I set up multi source routing in 5.3 or so and was astounded at all the negativity on this list and that it could not be done. It will take forever to read the noise in this thread alone. Some said you have to use DHCP i could go on. Do not trust that ping -I will work how you would think. Must specify an IP address, not eth0, not eth1. ping -I 10.0.0.1 8.8.8.8 This really is just a few lines per interface. Learn by changing the /etc/sysconfig/network-scripts/ifup-route shell scripts to add logging. echo out variables. There is no need to get iptables involved at all unless doing something very special. i did not want to setup quagga or some form of dynamic routing deamon because of security concerns. i wanted static IP addresses communicating to the ISP on static routes. It is pretty simple. Maybe i can hook up my laptop to 3G and WiFi and Cat6 and make sure i get it working. Please remember to use IP addresses, not names for ping testing. Scrutinize ping results. ping -I 10.0.0.1 8.8.8.8 On Fri, May 3, 2013 at 4:26 PM, Michael Mol wrote: > On 05/03/2013 03:24 PM, Michael H. Warfield wrote: > > On Wed, 2013-05-01 at 17:52 -0400, Michael Mol wrote: > > [snip] > > > > >> Curiously, at least one guy has reported success: > > > >> > http://sysadminsjourney.com/content/2009/04/15/doing-simple-source-policy-routing-centos/ > > > >> Now, the only thing different between his setup and mine (apart from my > >> using ethN:1 instead of ethN, as all three routers hang off the same > >> ethernet segment) is that were his guide says: > > > >> echo "default table CorpNet via 10.0.0.1" > > >> /etc/sysconfig/network-scripts/route-eth1 > > > > Ok... Wow... If that's the only difference between his description and > > what you did, you certainly left A LOT out. He's using both rules and > > tables neither of which you made any mention of in your original post. > > I tried it both ways, honestly. I've been blasted (postfix) or ignored > (samba) more than a few times in other environments for providing too > much information, so I didn't think it wise doing a writeup of both > approaches. Can't win. Can't even break even... > > > > > At this point, having read that article, I will eat my earlier words > > (not the first time and certainly won't be the last time). I guess you > > can now do this using the standard files, it's just that I haven't done > > it in so long that you couldn't do it back then (my excuse and I'm > > sticking with it). Following his description, I could easily reproduce > > my old setups using ifcfg-ethN, rule-ethN, and route-ethN. I'm > > impressed. I don't need it any more but - nice... That makes it a lot > > easier than what I had to figure out. > > I was going to ask you how you tied in your manual script... > > > > > Ok... So, I'm assuming you properly set up the rules-ethN file as well > > (and the proper entry in /etc/iproute2/rt_tables? You made no mention > > of that in your OP. That's a very crucial bit there. > > So, this is interesting. I'd read that you could use a command like > > ip route add 1.2.3.4/32 dev eth0 via 10.1.0.1 src 10.1.0.12 from > 4.3.2.1/24 > > with the "from 8.3.2.1/24" portion as part of the IP command, but that > using tables was usually done because it was easier. > > What's bizarre is that I could have sworn I had this type of rule even > working. But when I run it on my laptop, and follow up with "ip rule > show", the "from X" clause is gone. > > This calls into question everything else I was convinced I had working, > too. But I do know my 'table CorpNet' approach worked when applied > manually, but not when I tried converting it to route-ethN. I won't be > able to try it again for a while, either, but I've got a hunch why it > didn't work. > > > > > Also, in your OP you mentioned this: > > > > On Wed, 2013-05-01 at 16:05 -0400, Michael Mol wrote: > >> I've created a route-eth0:1 file that looks roughly like this: > >> > >> 10.0.0.1 dev eth0:1 \ > >> src 10.0.0.2 \ > >> from 10.0.0.0/29 > >> > >> default via 10.0.0.1 dev eth0:1 \ > >> src 10.0.0.2 \ > >> from 10.0.0.0/29 > > > > You're not showing table numbers or names there so it's not clear if you > > are using different route tables or not (which you MUST do and associate > > them with appropriate match rules). > > Yup. See above where I discover "from a.b.c.d" isn't a valid clause to > attach to the ip command. As finicky as that command is, I'm > disappointed it didn't throw an error. > > > > > According to "man ip-route" on my router the "from" stanza is not valid > > in a "route add" (route-ethN files) and in a "route ls" is only > > applicable to "cloned" routes. What you wrote can not literally work, > > by my reading of the "ip" man pages. > > Yup. I just re-read through to double check, when my manual invocation > on my laptop didn't work. > > > > > You get the source matching from the "
Re: [CentOS] repeat command
> repeat 10 some_command Found this on the web somewhere: #!/bin/sh i=0 num=$1 shift while [ $(( i += 1 )) -le $num ]; do eval "$@" done Worked fine. Thanks. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Configuring source-specific routing
On 05/03/2013 03:24 PM, Michael H. Warfield wrote: > On Wed, 2013-05-01 at 17:52 -0400, Michael Mol wrote: [snip] > >> Curiously, at least one guy has reported success: > >> http://sysadminsjourney.com/content/2009/04/15/doing-simple-source-policy-routing-centos/ > >> Now, the only thing different between his setup and mine (apart from my >> using ethN:1 instead of ethN, as all three routers hang off the same >> ethernet segment) is that were his guide says: > >> echo "default table CorpNet via 10.0.0.1" > >> /etc/sysconfig/network-scripts/route-eth1 > > Ok... Wow... If that's the only difference between his description and > what you did, you certainly left A LOT out. He's using both rules and > tables neither of which you made any mention of in your original post. I tried it both ways, honestly. I've been blasted (postfix) or ignored (samba) more than a few times in other environments for providing too much information, so I didn't think it wise doing a writeup of both approaches. Can't win. Can't even break even... > > At this point, having read that article, I will eat my earlier words > (not the first time and certainly won't be the last time). I guess you > can now do this using the standard files, it's just that I haven't done > it in so long that you couldn't do it back then (my excuse and I'm > sticking with it). Following his description, I could easily reproduce > my old setups using ifcfg-ethN, rule-ethN, and route-ethN. I'm > impressed. I don't need it any more but - nice... That makes it a lot > easier than what I had to figure out. I was going to ask you how you tied in your manual script... > > Ok... So, I'm assuming you properly set up the rules-ethN file as well > (and the proper entry in /etc/iproute2/rt_tables? You made no mention > of that in your OP. That's a very crucial bit there. So, this is interesting. I'd read that you could use a command like ip route add 1.2.3.4/32 dev eth0 via 10.1.0.1 src 10.1.0.12 from 4.3.2.1/24 with the "from 8.3.2.1/24" portion as part of the IP command, but that using tables was usually done because it was easier. What's bizarre is that I could have sworn I had this type of rule even working. But when I run it on my laptop, and follow up with "ip rule show", the "from X" clause is gone. This calls into question everything else I was convinced I had working, too. But I do know my 'table CorpNet' approach worked when applied manually, but not when I tried converting it to route-ethN. I won't be able to try it again for a while, either, but I've got a hunch why it didn't work. > > Also, in your OP you mentioned this: > > On Wed, 2013-05-01 at 16:05 -0400, Michael Mol wrote: >> I've created a route-eth0:1 file that looks roughly like this: >> >> 10.0.0.1 dev eth0:1 \ >> src 10.0.0.2 \ >> from 10.0.0.0/29 >> >> default via 10.0.0.1 dev eth0:1 \ >> src 10.0.0.2 \ >> from 10.0.0.0/29 > > You're not showing table numbers or names there so it's not clear if you > are using different route tables or not (which you MUST do and associate > them with appropriate match rules). Yup. See above where I discover "from a.b.c.d" isn't a valid clause to attach to the ip command. As finicky as that command is, I'm disappointed it didn't throw an error. > > According to "man ip-route" on my router the "from" stanza is not valid > in a "route add" (route-ethN files) and in a "route ls" is only > applicable to "cloned" routes. What you wrote can not literally work, > by my reading of the "ip" man pages. Yup. I just re-read through to double check, when my manual invocation on my laptop didn't work. > > You get the source matching from the "rules" not the "routes". You > haven't mentioned (or acknowledged) anything about them but they are > crucial (as are the use of multiple tables). What did you set up for > your match rules? No match rules, then only the default and local > tables are going to be used. Your "from" specifier goes in your rules, > not your routes. I hear you. I just wish I'd documented my first approach (using tables) better; I'm sure it was a silly error, and I'm getting more sure it was. I'd rather have had someone thump me over the head and point out a simple error than spend three days arguing over whether or not source-specific routing makes sense. > > When I look at my route tables, I see src associated with an appropriate > route. I don't see any "from" matches because they are not in the route > tables they're in the rules. You also have to look at "ip rules ls". > That's where your "from" is going to show up and then tell you what > table it's going to use as its routing table. > >> My first pass at making my code platform-idomatic effectively was: > >> echo "default via 10.0.0.1 table CorpNet" > >> /etc/sysconfig/network-scripts/route-eth1 > >> (the "table $table" clause in mine was at the end of the line, following >> the pattern I'd read in LARTC, rather than near the beginning of the line
Re: [CentOS] Configuring source-specific routing
On 05/02/2013 08:48 PM, Michael Mol wrote:
> On 05/02/2013 02:02 PM, Les Mikesell wrote:
>> On Thu, May 2, 2013 at 12:31 PM, Michael Mol wrote:
> with its default gateway pointing toward the ISP handling it. DNS
service is simple enough to have standalone servers for each instance
you need.
>>> This would also require either resources or underlying authorizations I
>>> don't have.
>> CentOS VMs are really, really cheap
> That's really, truly, seriously not the issue. I don't know if you saw
> where I said I was setting up a private cloud.
>
> And, as I said, I can't discuss the problem without breach of NDA.
>
Web browsers are actually very good at handling multiple IPs in DNS
responses and doing their own failover if some of the IPs don't
respond.
>>> It varies greatly by client software. And given the explosion of
>>> unreliable network connections (wifi, mobile), some of that failover
>>> logic's margin is already lost in dropped packets between the client and
>>> their local network gateway.
>> Yes, but typically they can deal with receiving multple IPs from the
>> initial DNS lookup even if some are broken better/faster than getting
>> one IP which subsequently breaks and then having to do another DNS
>> lookup to get a working target. At least the few broswers I tested a
>> while back did...
> You missed my point, my point was that your margin is already eaten into
> by unreliable networks.
>
For other services you might need to actively change DNS to drop IPs
if you know they have become unreachable, though.
>>> Yup. That's what I was planning on doing, more or less. Start with
>>> ordering IPs by route preference, drop IPs by link state. I just wish I
>>> could drive it by snooping OSPF...
>> I don't think you can count on your ordering reaching the clients or
>> meaning anything to them if it does. And some applications won't ever
>> do a lookup again.
> Yes, intermediate resolvers may reorder responses. That's fine and
> pretty normal. If ordering responses doesn't work, I fall back to a
> stochastic approach; that's actually rather a "given", since an
> oversaturated link qualifies as "down" for the purpose of new connections.
>
> And, yes, there's a lot of client software out there (*especially web
> browsers*) which cache responses and disregard TTLs. To those users, I
> really can only say "have you tried turning it off and back on again?"
>
> But here we are, arguing about *load balancing*, when the problem I face
> is, frankly, one of taking either of a pair of *known-to-work* sequences
> of invocations of "ip" commands and getting whatever process
> /etc/sysconf/network-scripts/{ifcfg-eth*,ifcfg-route*} to maneuver the
> kernel into the same resulting state.
>
> Source-based routing frankly isn't that hard! From the perspective of an
> edge node (i.e. a server):
>
> # First subnet
> ip addr add 10.0.0.2/24 dev eth0 brd 10.1.0.255
> ip route add default via 10.0.0.1 dev eth0 src 10.0.0.2
>
> # Second subnet
> ip addr add 10.1.0.2/24 dev eth0 brd 10.1.0.255
> ip route add default via 10.1.0.1 dev eth0 src 10.1.0.2
>
> and from a router's perspective, it's
>
> # Assuming proxy_arp is set on eth0 and eth1
> # Sets up source-specific routing for 10.0.0.0/24
> # WAN hangs off eth0. LAN hangs off eth1.
> ip addr add 10.0.0.2/24 dev eth1 brd 10.0.0.255 # To LAN
> ip addr add 10.0.0.2 dev eth0 # For the benefit of 'src 10.0.0.2' below
> ip route add 10.0.0.1 dev eth0 src 10.0.0.2 # For 'via 10.0.0.1' below
> ip route add default via 10.0.0.1 dev eth0 src 10.0.0.2 from 10.0.0.0/24
>
> # Assuming proxy_arp is set on eth0 and eth1
> # Sets up source-specific routing for 10.1.0.0/24
> # WAN hangs off eth0. LAN hangs off eth1.
> ip addr add 10.1.0.2 dev eth1 brd 10.1.0.255 # To LAN
> ip addr add 10.1.0.2 dev eth0 # For the benefit of 'src 10.1.0.2' below
> ip route add 10.1.0.1 dev eth0 src 10.1.0.2 # For 'via 10.1.0.1' below
> ip route add default via 10.1.0.1 dev eth0 src 10.1.0.2 from 10.1.0.0/24
>
> That's it! (unless I typo'd or thinko'd something coming up with these
> examples.) It took me all of three or four hours yesterday to learn this
> much of it. Then the rest of the day discovering the stuff I was putting
> in route-ethN wasn't being honored.
>
> My problem has been that the "from 10.x.0.0/24" parameter keeps getting
> stripped by whatever processes /etc/sysconfig/network-scripts/route-ethN
>
Alternate source routing, firewall and netfilter marking of packets:
iptables -t mangle -A PREROUTING -s 172.24.5.0/24 -j MARK --set-mark 100 #
iptables -t mangle -A PREROUTING -s 192.168.150.107 -j MARK --set-mark
200 #
iptables -t mangle -A PREROUTING -s 192.168.150.224 -j MARK --set-mark 100
# Local network
iptables -t mangle -A PREROUTING -d 192.168.0.0/16 -j MARK --set-mark 20
iptables -t mangle -A PREROUTING -d 172.16.0.0/12 -j MARK --set-mark 20
iptables -t mangle -A PREROUTING -s -d 192.168.0.0/16 -j MARK
--set-mark 20
iptables -t mang
Re: [CentOS] repeat command
On Fri, May 3, 2013 at 3:52 PM, Frank Cox wrote: > >> Is it _really_ that hard to type the explicit loop with test ([) and >> expr? These were builtins even in bourne shell eons ago. > > Here is the simplest possible solution, and exactly what I think the OP was > looking for: > > http://www.melvilletheatre.com/articles/repeat/ > Yes, if you think that downloading/installing/maintaining yet another specialized program on every device that might need it is simpler than typing a couple of lines re-using knowledge that's been good for 20+ years. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] repeat command
On Fri, 3 May 2013 13:02:47 -0500 Les Mikesell wrote: > Is it _really_ that hard to type the explicit loop with test ([) and > expr? These were builtins even in bourne shell eons ago. Here is the simplest possible solution, and exactly what I think the OP was looking for: http://www.melvilletheatre.com/articles/repeat/ -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com www.creekfm.com - FIFTY THOUSAND WATTS of POW WOW POWER! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Configuring source-specific routing
On Wed, 2013-05-01 at 17:52 -0400, Michael Mol wrote:
> On 05/01/2013 05:15 PM, Michael H. Warfield wrote:
> > On Wed, 2013-05-01 at 16:05 -0400, Michael Mol wrote:
> >> I'm attempting to configure source-specific routing so that my servers
> >> can exist on multiple subnets from multiple upstream providers.
> >
> > Kinda curious why you are attempting this without getting involved in
> > dynamic routing (BGP)... It's usually someone trying to do multihoming
> > or multi-link load balancing on the cheap without involving their ISPs
> > (which tends to be expensive as soon as you're talking with them about
> > redundant / backup loops, provider independent addresses, and BGP
> > peering). Generally equates to "champagne taste on a beer budget" but
> > there are exceptions and reasons, as I know from personal experience.
> > It often doesn't end well and is unreliable as network conditions
> > change. But that depends on your requirements and application. I'm not
> > one to judge - just pointing out the pitfalls.
>
> Yup, I know.
>
> Intent is to maintain the old, slow (but has an SLA) connection as a
> fallback, and migrate services to the new connection piecemeal.
> Meanwhile, the same DNS server on the new connection can be, e.g. "ns3".
> The same mailserver can have a new MX on the new connection...likely
> prioritized to it.
>
> Inbound services can be load-balanced fairly easily via DNS, if TTLs are
> kept low, and records updated in response to link state. It's not
> anycast DNS, but it also doesn't require to you get BGP peering and PI
> space. (I don't even know if I could *get* IPv4 PI space at this point.
> I certainly know I wouldn't be able to if I waited a year...)
>
> >
> > I have done this a number of times in the past (mostly for VPN's and
> > redundant load-balancing links). You're probably going to have get real
> > down and dirty into policy routing rules and tables with iproute2. I
> > don't honestly believe you will be able to pull it off with the basic
> > stuff provided in the ifcfg-*, route-*, or static-route files (proviso
> > below).
> >
> > I had to do it using completely custom files utilizing "ip rule" and "ip
> > route {add|delete} table [n]" subcommands to "ip" to build custom
> > matching rules and mapping them to different routing tables containing
> > different routes and priorities. In some cases, with OpenVPN VPNs, I
> > also had to incorporate iptables filtering commands to mark and match
> > packets and interact with the ip rule tables but I doubt you're going
> > that deep.
>
> Yeah, I've gone that deep. And a tad deeper. I had almost *everything*
> working by hand, and went to figure out how to convert it to idomatic
> CentOS network configuration scripts. And took my network down *three
> times* because of the script-processing stripping things out.
>
> >
> > man ip-rule
> >
> > --
> >In some circumstances we want to route packets differently depending
> >not only on destination addresses, but also on other packet fields:
> >source address, IP protocol, transport protocol ports or even packet
> >payload. This task is called 'policy routing'.
> >
> >To solve this task, the conventional destination based routing table,
> >ordered according to the longest match rule, is replaced with a
> > 'rout‐
> >ing policy database' (or RPDB), which selects routes by executing
> > some
> >set of rules.
> Yup. I went through LARTC before writing a line of code, just to be sure.
> Curiously, at least one guy has reported success:
> http://sysadminsjourney.com/content/2009/04/15/doing-simple-source-policy-routing-centos/
> Now, the only thing different between his setup and mine (apart from my
> using ethN:1 instead of ethN, as all three routers hang off the same
> ethernet segment) is that were his guide says:
> echo "default table CorpNet via 10.0.0.1" >
> /etc/sysconfig/network-scripts/route-eth1
Ok... Wow... If that's the only difference between his description and
what you did, you certainly left A LOT out. He's using both rules and
tables neither of which you made any mention of in your original post.
At this point, having read that article, I will eat my earlier words
(not the first time and certainly won't be the last time). I guess you
can now do this using the standard files, it's just that I haven't done
it in so long that you couldn't do it back then (my excuse and I'm
sticking with it). Following his description, I could easily reproduce
my old setups using ifcfg-ethN, rule-ethN, and route-ethN. I'm
impressed. I don't need it any more but - nice... That makes it a lot
easier than what I had to figure out.
Ok... So, I'm assuming you properly set up the rules-ethN file as well
(and the proper entry in /etc/iproute2/rt_tables? You made no mention
of that in your OP. That's a very crucial bit there.
Also, in your OP you mentioned this:
On Wed, 2013-05-01 at 16:05 -0400, M
Re: [CentOS] repeat command
Les Mikesell wrote: > On Fri, May 3, 2013 at 1:23 PM, wrote: > True. Thing I like about seq is that it also takes an optional increment value which can be very handy at times. >>> >>> Is it _really_ that hard to type the explicit loop with test ([) and >>> expr? These were builtins even in bourne shell eons ago. >> >> It is not hard. I *tested* what I posted yesterday, and copied and >> pasted it into my email. > > Sure it worked on the box where you tested it, but I think your > version was at least bash-specific and something you'd need to know > which version runs where if you use bourne shells anywhere. I'm not > good at tracking that stuff, so I like backwards and cross-platform > compatibility. Oh, sure. Running CentOS 6.4, and yes, I use bash. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] repeat command
On Fri, May 3, 2013 at 1:23 PM, wrote: >>> True. Thing I like about seq is that it also takes an optional >>> increment value which can be very handy at times. >> >> Is it _really_ that hard to type the explicit loop with test ([) and >> expr? These were builtins even in bourne shell eons ago. > > It is not hard. I *tested* what I posted yesterday, and copied and pasted > it into my email. Sure it worked on the box where you tested it, but I think your version was at least bash-specific and something you'd need to know which version runs where if you use bourne shells anywhere. I'm not good at tracking that stuff, so I like backwards and cross-platform compatibility. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] repeat command
Les Mikesell wrote:
> On Thu, May 2, 2013 at 6:45 PM, John R. Dennison wrote:
>> On Fri, May 03, 2013 at 01:36:36AM +0200, Markus Falb wrote:
>>>
>>> this works but at least with bash you can do it with brace expansion
>>> for x in {1..10}; do … ; done
>>>
>>> it's a bashism but maybe more portable, e.g. OS-X has no seq
>>> no fork (for the seq) is necessary as well
>>
>> True. Thing I like about seq is that it also takes an optional
>> increment value which can be very handy at times.
>
> Is it _really_ that hard to type the explicit loop with test ([) and
> expr? These were builtins even in bourne shell eons ago.
It is not hard. I *tested* what I posted yesterday, and copied and pasted
it into my email.
mark
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] repeat command
On Thu, May 2, 2013 at 6:45 PM, John R. Dennison wrote:
> On Fri, May 03, 2013 at 01:36:36AM +0200, Markus Falb wrote:
>>
>> this works but at least with bash you can do it with brace expansion
>> for x in {1..10}; do … ; done
>>
>> it's a bashism but maybe more portable, e.g. OS-X has no seq
>> no fork (for the seq) is necessary as well
>
> True. Thing I like about seq is that it also takes an optional
> increment value which can be very handy at times.
Is it _really_ that hard to type the explicit loop with test ([) and
expr? These were builtins even in bourne shell eons ago.
--
Les Mikesell
lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kickstart and volume group with a dash in the name
On 02.Mai.2013, at 18:13, Dennis Jacobfeuerborn wrote: > The problem is that kickstart doesn't allow > dashed in volume group names? It seems so. https://bugzilla.redhat.com/show_bug.cgi?id=186439 https://bugzilla.redhat.com/show_bug.cgi?id=407701 https://bugzilla.redhat.com/show_bug.cgi?id=430907 http://rhn.redhat.com/errata/RHBA-2009-0164.html If I understand it correct then it should have been fixed long ago. I tried it. CentOS 5 does *not* strip the dash Fedora 18 does *not* strip the dash but CentOS 6 *does strip* the dash It seems like a regression. You are using CentOS 6, aren't you? Would you mind filing a bugzilla? -- Markus ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is there a good nntp client for Centos 6 that handles SSL native?
On Fri, 3 May 2013 12:32:28 +0200 Markus Falb wrote: > On 02.Mai.2013, at 00:54, Rock wrote: > > > I also found out elsewhere that Thunderbird has native > > SSL support - but TB treats NNTP as SMTP which makes > > it difficult, if not unwieldy to use. > > What exactly do you mean with that? > At times I use thunderbird with the gmane news to mail gateway and it seemed > to worked great for me. > I did not bother with ssl for that, though. I'm using claws-mail to read gmane news. It support SSL in mail, probably will work for NNTP too. BR, Bob ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kickstart and volume group with a dash in the name
Dennis Jacobfeuerborn wrote: > On 02.05.2013 18:33, maxxik wrote: > >> >> On 03/05/13 00:13, Dennis Jacobfeuerborn wrote: >>> Hi, >>> I'm trying to setup the provisioning of new OpenStack hypervisors with >>> cinder volumes on them. The problem is that kickstart doesn't allow >>> dashed in volume group names? >>> I tried this: >>> >>> volgroup cinder-volumes --pesize=4096 pv.02 >>> >>> and this: >>> >>> volgroup cinder--volumes --pesize=4096 pv.02 >>> >>> but in both cases I end up with a volume group named "cindervolumes" on >>> the system. Any idea what I have to do to accomplish this? >>> Defining VGs with dashes works perfectly fine on the command line. >> >> Did you try to screen it via "\" ? i.e. "volgroup cinder\-volumes >> --pesize=4096 pv.02" ? > > Just tried this and the volume group still ends up as "cindervolumes". Dunno why you're insisting on putting dashes in the name, but have you tried volgroup 'cinder-volumes', with single quotes around the name? mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kickstart and volume group with a dash in the name
On 02.05.2013 18:33, maxxik wrote: > Hi Dennis > > Did you try to screen it via "\" ? i.e. "volgroup cinder\-volumes > --pesize=4096 pv.02" ? Just tried this and the volume group still ends up as "cindervolumes". > > On 03/05/13 00:13, Dennis Jacobfeuerborn wrote: >> Hi, >> I'm trying to setup the provisioning of new OpenStack hypervisors with >> cinder volumes on them. The problem is that kickstart doesn't allow >> dashed in volume group names? >> I tried this: >> >> volgroup cinder-volumes --pesize=4096 pv.02 >> >> and this: >> >> volgroup cinder--volumes --pesize=4096 pv.02 >> >> but in both cases I end up with a volume group named "cindervolumes" on >> the system. Any idea what I have to do to accomplish this? >> Defining VGs with dashes works perfectly fine on the command line. >> >> Regards, >> Denis >> ___ >> CentOS mailing list >> CentOS@centos.org >> http://lists.centos.org/mailman/listinfo/centos >> > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is there a good nntp client for Centos 6 that handles SSL native?
On 02.Mai.2013, at 00:54, Rock wrote: > I also found out elsewhere that Thunderbird has native > SSL support - but TB treats NNTP as SMTP which makes > it difficult, if not unwieldy to use. What exactly do you mean with that? At times I use thunderbird with the gmane news to mail gateway and it seemed to worked great for me. I did not bother with ssl for that, though. -- Markus ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is there a good nntp client for Centos 6 that handles SSL native?
On 03.Mai.2013, at 08:12, Rock wrote: > On Thu, 02 May 2013 20:36:53 -0500, Rex Dieter wrote: > >> I like knode (in kdepim rpm) … > So, looking for a Centos RPM repository: > $ yum --noplugins --showduplicates --enablerepo \* --disablerepo c6- > media,\*-source,\*debug\* provides "*/knode" you likely missed it because of all the language rpms. $ yum -q provides /usr/bin/knode 6:kdepim-4.3.4-6.el6.x86_64 : PIM (Personal Information Manager) applications Repo: base Matched from: Filename: /usr/bin/knode As rex told us ;-) -- Markus ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
