Discuss

discuss@lists.centos.org

5 participants
34752 discussions

About tunnels
by Maciej Żenczykowski 26 May '05

26 May '05

Hi folks, I have two CentOS 4 server I administrate doing routing and firewalling of two networks (one NATed and firewalled and the other one merely firewalled) and I'd like to build a tunnel to allow computers on the normal private network (and the firewall) to access the private IPs of computers behind the NAT/firewall. ie. ALPHA BETA 10.0.0.0/8 - CentOS4 - internet - CentOS4 - X.Y.Z.0/24 Private IPs Firewall Firewall Public IPs and NAT now the internet is intracity, within one provider and decently safe (6 hops), but still some sort of encryption would be nice... (otherwise I'd just use ip tunnel). How do I allow both BETA and X.Y.Z.0/24 to connect to the private IPs? Should I use CIPE? IPSEC? something else? any good howtos? Preferably something fast and reliable, doesn't need to be that easy to set up :) I'm basically looking for comments, I have looked around on google, and it seems there's _tons_ of options, but IPSEC seems to be winning out... am I correct in that assumption? Cheers, MaZe.

2 1

Re: [CentOS] Re: Official CentOS CD/DVD Vendor Program
by Bryan J. Smith <b.j.smith＠ieee.org> 26 May '05

26 May '05

From: Chris Mauritz <chrism(a)imntv.com> > If this was going to be a 100 unit/day or 1000 unit/day affair, I'd > agree with you, but it simply isn't. One or two people with cheap CD > and DVD duplicators, a paypal merchant account, and some time on their > hands is probably still overkill for the volume of sales, especially > when the product is available for free to anyone with a broadband > connection and a burner. Capacity planning. It's better to make only $500 and miss out on $1,000 than to have orders of $10,000 and only be able to service $2,500. > No, not really. What this says to me is that the CentOS team is doing > all the labour and some unecessary middleman is skimming the cream off > the top. Wouldn't you like to see the CentOS project receive more of a > share of the take for doing most of the work? I would. No, CentOS is focusing on what it does best and tapping others to do what they do best. But as someone else pointed out, form a CD/DVD duplication reseller and make a better offer and CentOS will likely take you up on it! > Spare me the condescending remarks. You knew what I meant. You mega-oversimplified, so no I did not. It's one thing to volunteer, that's great. In fact, at first, I thought that's what you were doing. But then you started to post all these things that just were like a "slap in face." Looking from the viewpoint of those CentOS managers who "put the time" and, more importantly, the _detail_ in on this, you showed you didn't have the faintest idea of what was involved. Again, as someone else pointed out, form a CD/DVD duplication reseller and make a better offer and CentOS will likely take you up on it! In fact, although there are the "minimal requirements" of $1/set under this plan, there's _nothing_ stopping different CD/DVD duplication resellers from playing a game of "one-up-manship" to gain the title of "highest proceeds" to CentOS. So instead of being so negative on what the leaders of this project have done so far, from a standpoint that was rather "shallow," why not be constructive and go ahead and offer to be a CD/DVD duplication reseller! The terms of the program are there -- go for it! You're open to it! ;-> > Looking back at the volume in the "demonizing" thread, I think I don't > have nearly the same amount of free time to spend jousting about > something so trivial in this mailing list with you. You're obviously a > very opinionated guy Oh, very, very much so. I am extremely opinionated. As far as "free time," I write for part of my living, and much of it comes from discussions on boards like this. As far as my "day job," it's largely 8x5, one advantage of being a traveling consultant that does more "architecture/design" than "analysis/support." > and often full of very sage advice to go along with the voluminous > opinion. Opinion to one is experience to another. I have _no_problem_ taking years to gain the trust of people. I think credentials don't mean squat, and trust comes from hearing people say things and finding out if they are applicable and useful over time. Again, even years. > But I found this reply to be more than a bit obnoxious. As did I your "volunteering." It's one thing to honestly "volunteer." It's another to belittle the initiative of the managers of this project who obviously took far more time, attention to detail and actually work to get the program going. There is no reason why you can't "volunteer" under this program by becoming a CD/DVD reseller yourself, under the same terms as any other. If you honestly believe you can do it better and cheaper than the current vendors who are signed up, then please do! We would all benefit if you did. That's all I was saying. And yes, I did berrate much of what you said for the reason I just explained. > The point of my message is that it seems like the CentOS guys > are doing all the heavy lifting and companies that (at least to me) > add very little value are taking the lion's share of the revenue for > these CD/DVD sets. As are arm-chair users who don't take the time to understand the details involved on things like this. I have taken what at least one other has said and re-gurgitated what you _can_ do under the program's terms that does _exactly_ what you want to do. So I suggest you consider becoming a CD/DVD duplicator/reseller yourself then. BTW, I might not be involved with CentOS, but I'm trying to do my (small/ too-small-to-even-speak-of) part on Fedora, which affects both RHEL and CentOS. And I can fully appreciate all of what the CentOS project does. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan
by Bryan J. Smith <b.j.smith＠ieee.org> 26 May '05

26 May '05

From: Les Mikesell <lesmikesell(a)gmail.com> > Thanks - as you probably know, the long-winded discussion isn't > really about CIPE specifically so much as the philosophy behind > bundling a few thousand things together and then trying to > please anyone with a blanket policy about maintaining backwards > compatibility vs bug fixes vs new features. You just can't please everyone. But it does help if people focus on "why" something is done -- the pros/cons versus doing something else -- instead of trying to assert what is "better" (as well as stopping to listen to someone and realize they are not asserting anything as "better," just trying to explain "why"). CentOS is based on RHEL. RHEL has its policies. > And while I realize that there may never be a good solution, I'll be > really happy if some new options fall out of it, like this being > included in a centos kernel-unsupported-something-or-other package. I think CentOS is optionally filling that gap between FC and RHEL quite well for those that want it. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: Official CentOS CD/DVD Vendor Program
by Bryan J. Smith <b.j.smith＠ieee.org> 26 May '05

26 May '05

My $0.02 ... From: Chris Mauritz <chrism(a)imntv.com> > What's the point? Awareness, partnerships, retail notoriety and most of all, a starting point for now. You have to start somewhere. > I checked out linux cd mall. They charge $12.50 for the CD set (or DVD) > and CentOS makes ONE DOLLAR. Unless you envision tens of thousands > of people buying CDs, it hardly seems like a worthwhile endeavor I can envision that volume per year. > unless you're the CD distributor. The CD distributor has the economies-of-scale in the fact that they already have a built infrastructure, web front, relationships, etc... that CentOS can tap. For CentOS to build the same infrastructure, it would cost far more per unit sold -- at least at, again, "a starting point for now." > Why not just find a way to make it easier for people to donate directly > to the project instead of creating a needless middleman who is taking > 92% of the money for each CD/DVD set sold? Again, costs involved are relevative here. > Hell, for 92% of the profit, No, that's 92% of the _revenue_, and _not_ the "profit" (sometimes I think some Linux advocates need a refresher course in basic microeconomics ;-). There are more costs involved than just CD duplication here. > I'd be more than happy to sit at home and burn DVDs all day. And take orders? And handle shipping? And resolve issues with the site, customers, MC/VISA complaince on e-commerce, etc...? You can only do so much on your own before you need someone already doing it who can do it for much cheaper. > Where do I sign? 8-) You sign next to "I will learn how the infrastructure and operational costs of e-commerce works before I speak again." ;-> More seriously now, does everyone have to question everything around here? You don't think the management hasn't thought of these things? Why does everyone seem to believe they know better than the management who not only volunteers their time, but puts in the hours to be productive, including all the "less fun stuff" in the logistics and attention to detail? More pertinent, if you make posts like this, that are only include 5% of the actual details involved with doing such (and expose what can only be termed ignorance of the other 95%), how seriously do you think people can take your comments? I didn't. ;-ppp -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

insmod ip_conntrack_ftp
by Mickael Maddison 26 May '05

26 May '05

Hello CentOS, Is there a specific RPM that makes "insmod ip_conntrack_ftp" available? I've been using that on a number of servers fine, but the latest one I've built, running insmod ip_conntrack_ftp gives me: insmod: can't read 'ip_conntrack_ftp': No such file or directory -- Best regards, Mickael mailto:mike@kamloopsbc.com www.MickaelMaddison.com

3 3

Re: Demonizing generic Linux issues as Fedora Core-only issues -- why I hate these meta-discussions ...
by Bryan J. Smith <b.j.smith＠ieee.org> 26 May '05

26 May '05

From: "Bryan J. Smith <b.j.smith(a)ieee.org>" > You are indeed correct (I must have been looking at the RHEL3 dir**) First off, that's now 2 strikes for me. Small ones considering the context well outside of the points, but still it hurts my credibility. This is one of the things I hate about meta-discussions, at least how I approach them. Sometimes I just need to learn that it doesn't matter how many additional examples I give, some people aren't going to do anything but blame Red Hat. And by giving example after example, or attempting explain item after item, I'm going to eventually slip up from memory from time-to-time, which hurts my credibility -- regardless if the actual mistake was small given the context of the discussion. Sigh, there is a point where one should just resign and submit to the fact that if something doesn't work for someone, and { Microsoft, Red Hat, SuSE, even Debian as of late, etc... } is involved anywhere at all (even if it's a fork to another architecture -- e.g., anyone who has dealt with Cobalt/Sun releases, a primary reason for Red Hat's latter trademark enforcement ;-), the other person has no interest in understanding the "root" cause and will not see anyting to the contrary. My apologies for tying up the list with this non-sense. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: Demonizing generic Linux issues as Fedora Core-only issues -- MySQL 3 v. 4 linking licensing issues
by Bryan J. Smith <b.j.smith＠ieee.org> 26 May '05

26 May '05

From: Johnny Hughes <mailing-lists(a)hughesjr.com> > RHEL-4 shipped with MySQL 4.1.x (and has a 3.23.58 client to work with > older databases) ... the latest SRPMS are mysql-4.1.10a-1.RHEL4.1.src.rpm > and mysqlclient10-3.23.58-4.RHEL4.1.src.rpm. You are indeed correct (I must have been looking at the RHEL3 dir**): ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/ Hmmm, that's actually a _major_ variance from Fedora Core 3: http://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/os/Fedora/RP… [ **NOTE: I have not supported MySQL since the RHL9/RHEL3 series, hence why I didn't know it off-hand, just of the linking issues with version 4. ] Which begs the questions: 1) How much testing did it get in the Fedora Development/Core series? 2) How did they solve some of the linking issues I've heard about? As I mentioned before, the current Fedora Core 4 Test has it too, so I have to assume one of the following: A) Red Hat negotiated a license to redistribute as built as before but now for MySQL 4 (not likely since even FC4 has it now, unless the license also applies there, but I doubt it based on how Red Hat makes sure any FC/FE packages are always 100% redistributable by others) B) Red Hat shifted away from the few static links that it has previously used (more likely?) C) The packages causing the linking licensing issues have change their licensing? (NuSphere possibly?) D) MySQL AB changed its stance on linking in MySQL 4 as of v4.1? Anyone know the answer? I have to go back and research why Red Hat stuck with 3.23 and see how they are now redistributing 4.1x? > CentOS-4 has the identical programs {as with all other items except > LOGOS, trademarked text, and yum and where updates are done} in it's > base :) Which is why I love it. I must have just looked at the wrong directory. I'm also very disturbed that Red Hat would not give the public time to test in the leading community releases. If I had to speculate, I'd say it's because it was already testing in most other distros, but I'll have to read up in Bugzilla on why the change was made (as well as what allowed Red Hat to change it's stance on MySQL 4 in the first place). -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

CentOS-announce Digest, Vol 3, Issue 15
by centos-announce-request＠centos.org 26 May '05

26 May '05

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CESA-2005:413 Important CentOS 3 i386 ImageMagick - security update (Tru Huynh) 2. CESA-2005:413 Important CentOS 3 x86_64 ImageMagick - security update (Tru Huynh) 3. CESA-2005:472 Important CentOS 3 i386 kernel - security update (Tru Huynh) 4. CESA-2005:472 Important CentOS 3 x86_64 kernel - security update (Tru Huynh) ---------------------------------------------------------------------- Message: 1 Date: Thu, 26 May 2005 00:46:09 +0200 From: Tru Huynh <tru(a)centos.org> Subject: [CentOS-announce] CESA-2005:413 Important CentOS 3 i386 ImageMagick - security update To: centos-announce(a)centos.org Message-ID: <20050525224609.GA30869(a)sillage.bis.pasteur.fr> Content-Type: text/plain; charset="us-ascii" CentOS Errata and Security Advisory 2005:413 ImageMagick security update for CentOS 3 i386: https://rhn.redhat.com/errata/RHSA-2005-413.html The following updated file has been uploaded and is currently syncing to the mirrors: i386: updates/i386/RPMS/ImageMagick-5.5.6-14.i386.rpm updates/i386/RPMS/ImageMagick-c++-5.5.6-14.i386.rpm updates/i386/RPMS/ImageMagick-c++-devel-5.5.6-14.i386.rpm updates/i386/RPMS/ImageMagick-devel-5.5.6-14.i386.rpm updates/i386/RPMS/ImageMagick-perl-5.5.6-14.i386.rpm source: updates/SRPMS/ImageMagick-5.5.6-14.src.rpm You may update your CentOS-3 i386 installations by running the command: yum update ImageMagick\* Tru -- Tru Huynh (CentOS-3 i386/x86_64 Package Maintenance) http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBEFA581B

1 0

Re: Betr.: [CentOS] VPN
by Peter Farrow 26 May '05

26 May '05

Hi there, yes it was with a Nortel contivity on a few occassions and the other times with a Cisco pix. interstingly enough the Cisco VPNs often required updates to the IOS to make them 3Des compliant, As its late here in the UK (past midnight GMT+1) here is a very quick and dirty freeswan guide. Needless to say the things that cause the biggest headache for most users is the use of RSA keys and opportunistic encryption. Since this is NOT what 99.9% of the masses need or want then there is a quick and simple and just as secure alternative setup, but its not that well documented. Opportunistic encryption came in versions 2 and above of freeswan by default, this has the effect of clobbering the network default route and replacing it down the ipsec interface (what you want if you want to encrypt everything, but not really any great use in the real world). Most people want to do site <-> site vpns and these are best achieved without opportunistic encryption and by the use of preshared keys. 1)Make sure you get a version of freeswan suitable for your kernel, if you can't find one go to somewhere like rpms.pbone.net and find a kernel for which there is a freeswan version. Many people try and hunt a freeswan version to match their kernel, I do it the otherway round, find the latest freeswan compatible kernel you can for your architecture, you can always compile it from source but why my life harder for yourself. 2)get the freeswan module for the kernel you found, and the same freeswan-userland version as well. then proceed as follows: after you have installed the [from rpm] Typically to kill opportunistic encryption add these lines to your ipsec.conf file: after the config setup section near the top, conn block auto=ignore conn private auto=ignore conn private-or-clear auto=ignore conn clear-or-private auto=ignore conn clear auto=ignore conn packetdefault auto=ignore Doing this stops all the crap you get when ipsec starts and then kicks you off the system about 60 seconds later if you're connected remotely as this kills the opportunistic setup feature. Do the same at the other end as well. Then start the service. Then add a section for each tunnel you want to set up. if you have multiple subnets at each site which can't be encapsulated in a single subnet declaration, you will need to add a new tunnel defintion for each. Here is an example : conn site1-site2 #this is the connection name [tunnel] identifier left=21.21.100.10 #This is the ip address of the first linux box leftnexthop=21.21.100.9 #This is usually set to the defualt gateway for the first linux box leftsubnet=10.11.2.0/24 #This is the LAN subnet behind the first linux box right=21.21.100.178 #This is the IP address of the second linux box at the other end of the tunnel rightsubnet=10.11.4.0/24 #This is the LAN subnet behind the second linux box rightnexthop=21.21.100.177 #This is the IP address of the default gateway setting of the other linux box authby=secret #We are going to use a "password" or secret to encrypt/auth the link pfs=no #Turn off perfect forward security, this makes it faster and easier but less secure auto=add #Authorise but don't start esp=3des-md5-96 #encapsulating security payload setting, encryption used for auth and data Now cut and paste this and add it to the ipsec.conf file on the second machine completely as is, unmodified. Then in you /etc/ipsec.secrets file on each machine you will need to add a password [secret] for each each of the tunnels you have specified, in the above example we would have: 21.21.100.10 21.21.100.178 : PSK "a-passwordin-here-with-the-quotes" Add this to the very top of the ipsec secrets file, one entry for each pair of machines in this format leftmachineip rightmachineip : PSK "password" Then do a service ipsec restart on each machine, bring the link up with this command, it only needs to be invoked from either one of the ends ipsec auto --up site1-site2 You should get output like this if you did it right: ipsec auto --up site1-site2 104 "site1-site2" #2086: STATE_MAIN_I1: initiate 106 "site1-site2" #2086: STATE_MAIN_I2: sent MI2, expecting MR2 108 "site1-site2" #2086: STATE_MAIN_I3: sent MI3, expecting MR3 004 "site1-site2" #2086: STATE_MAIN_I4: ISAKMP SA established 112 "site1-site2" #2087: STATE_QUICK_I1: initiate 004 "site1-site2" #2087: STATE_QUICK_I2: sent QI2, IPsec SA established Remember you will need to allow the ipsec interface in your firewall and you will need to add lines like this: # Accept udp connections to port 500 for ipsec $IPTABLES -A INPUT -p udp --sport 500 --dport 500 -j ACCEPT $IPTABLES -A OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT This is just about the quickest way to set up a VPN tunnel with Freeswan, it takes minutes. If you want to make if more secure, you can tune the config once you get it running this way! Remember the only machines that can't see the full extent of the other LAN network are the linux boxes creating the tunnel. So the left linux box will not be able to ping stuff on 10.11.4.0/24 network and the right linux box will not be able to ping stuff on 10.11.2.0/24 network - don't forget this.... its commonly mistaken by some to mean the tunnel isn't working, to truly test it end to end you need hosts on the LANs at each end to ping each other. If you want to make it work through NATing gateways you will need to port forward the udp 500 setting above on your firewall. Enjoy! Pete Kennedy Clark wrote: >Any chance of getting a quick HOW-TO posted to the group for that? >;-) Sounds interesting. > >I saw your post about using it with Cisco & Nortel equipment -- I work >with both a lot at my current customer. What types of equipment have >you used it with from both vendors (e.g., Cisco: IOS, PIX, VPN3K; >Nortel = Contivity)? > >Thanks!! >Kennedy > >

3 13

Re: [CentOS-announce] CESA-2005:472 Important CentOS 3 i386 kernel - security update
by John Newbigin 26 May '05

26 May '05

The yum headers for these updates seem to be incomplete or out of date... perhaps only for non i686 arch. 0:kernel-source-2.4.21-32.EL.i386=RPMS/kernel-source-2.4.21-32.EL.i386.rpm Tru Huynh wrote: > CentOS Errata and Security Advisory 2005:472 > > kernel security update for CentOS 3 i386: > https://rhn.redhat.com/errata/RHSA-2005-472.html > > The following updated file has been uploaded and is currently syncing to > the mirrors: > > i386: > updates/i386/RPMS/kernel-2.4.21-32.0.1.EL.athlon.rpm > updates/i386/RPMS/kernel-2.4.21-32.0.1.EL.i586.rpm > updates/i386/RPMS/kernel-2.4.21-32.0.1.EL.i686.rpm > updates/i386/RPMS/kernel-BOOT-2.4.21-32.0.1.EL.i386.rpm > updates/i386/RPMS/kernel-doc-2.4.21-32.0.1.EL.i386.rpm > updates/i386/RPMS/kernel-hugemem-2.4.21-32.0.1.EL.i686.rpm > updates/i386/RPMS/kernel-hugemem-unsupported-2.4.21-32.0.1.EL.i686.rpm > updates/i386/RPMS/kernel-smp-2.4.21-32.0.1.EL.athlon.rpm > updates/i386/RPMS/kernel-smp-2.4.21-32.0.1.EL.i686.rpm > updates/i386/RPMS/kernel-smp-unsupported-2.4.21-32.0.1.EL.athlon.rpm > updates/i386/RPMS/kernel-smp-unsupported-2.4.21-32.0.1.EL.i686.rpm > updates/i386/RPMS/kernel-source-2.4.21-32.0.1.EL.i386.rpm > updates/i386/RPMS/kernel-unsupported-2.4.21-32.0.1.EL.athlon.rpm > updates/i386/RPMS/kernel-unsupported-2.4.21-32.0.1.EL.i586.rpm > updates/i386/RPMS/kernel-unsupported-2.4.21-32.0.1.EL.i686.rpm > > source: > updates/SRPMS/kernel-2.4.21-32.0.1.EL.src.rpm > > You may update your CentOS-3 i386 installations by running the command: > > yum update kernel\* > > Tru > > > ------------------------------------------------------------------------ > > _______________________________________________ > CentOS-announce mailing list > CentOS-announce(a)centos.org > http://lists.centos.org/mailman/listinfo/centos-announce -- John Newbigin Computer Systems Officer Faculty of Information and Communication Technologies Swinburne University of Technology Melbourne, Australia http://www.ict.swin.edu.au/staff/jnewbigin

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss