From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M2CB9-0006Ou-HM for garchives@archives.gentoo.org; Thu, 07 May 2009 22:34:59 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D5AC3E0319; Thu, 7 May 2009 22:34:57 +0000 (UTC) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by pigeon.gentoo.org (Postfix) with ESMTP id 7EC9CE0325 for ; Thu, 7 May 2009 22:34:57 +0000 (UTC) Received: by fk-out-0910.google.com with SMTP id z22so473778fkz.2 for ; Thu, 07 May 2009 15:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=vlE1DUrL8P/SMFTCORA1bJKnXovC248s//zHsel0bTU=; b=deSkshXZfHBzrjKw4dlhvIXUJNSyEYV+x0NFNpdUCAdtIJh57d9/f67w+1uOMtobJH BQnzbZTrPWTNGrekANrtkiWte9pOL3X3h3zKrM5WhZIWWowp8mXOTwXhOIeGKtcquOeU HghOYZ0TTm1mlPh9dMiHBk42trGgCe6kXvhLo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=Ev7mQ5CqJKDPXlNahdxEmrq22LTbQsP+lXVt3v/Ht0r3TpBuOfFkpys5kHm15rNUOP hxMLM0BuSibP6zX7+wTnOmN2gvqxi+9FAuYb2b8KFzU7ijR5o4TLTVn8cFT3r5dkXiPN HqaibOYEve9tcstrOQxKTcES4FoNdea7lgN7Y= Received: by 10.102.253.8 with SMTP id a8mr663112mui.30.1241735696899; Thu, 07 May 2009 15:34:56 -0700 (PDT) Received: from lappy.study (230.3.169.217.in-addr.arpa [217.169.3.230]) by mx.google.com with ESMTPS id y37sm473192mug.19.2009.05.07.15.34.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 07 May 2009 15:34:56 -0700 (PDT) From: Mick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] A networking question... Date: Thu, 7 May 2009 23:34:42 +0100 User-Agent: KMail/1.9.9 References: <4A00A266.9070102@shic.co.uk> <4A017DA0.7010802@anferny.me.uk> <4A032AC0.6000801@shic.co.uk> In-Reply-To: <4A032AC0.6000801@shic.co.uk> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3747542.4bZTgmkCFx"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200905072335.00108.michaelkintzios@gmail.com> X-Archives-Salt: 4998d2ed-fb8b-4330-b4bd-9c6c460ae473 X-Archives-Hash: 7c1da59ef50a75eeacef1ace22e5d01d --nextPart3747542.4bZTgmkCFx Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 07 May 2009, Steve wrote: > Anthony Metcalf wrote: > > *That* depends on the exact specifics of what he is/isn't allowed to > > be showing....."They" may not even want the service to show as > > existing at that address for whatever reason. > > Thanks for all your discussion... I'll try to clarify - the PPP over > SSH approach does seem to offer the best compromise. > > I've a development site which hosts https and http services for existing > applications both remotely and locally. I'm developing an entirely new > https service under Apache and want to be absolutely sure that I get no > unexpected interactions between configurations for "live" services and > the experimental in-development service - and I definitely don't want a > random member of the public stumbling across the in-development site - > which might expose unacceptable vulnerabilities as rough-cuts of code > are trialled. Have your development https service set up as a virtual host on a webroot o= f=20 your choice, listening to a random port and also set up user authentication= =20 for the webroot fs. In this way, whether accessed via the Internet or LAN, visitors will need t= o=20 know the port to connect to and will also have to provide suitable=20 credentials. You can even control access to parts of the development https= =20 fs using tags to define them and setting different user defined= =20 access to them. If you use AuthDigest you can also set separate realms if= =20 the fs is extensive and access requirements complex. > It is entirely acceptable for any host on my LAN to access the > in-development service. I want to allow collaborators to access the > in-development service remotely over a SSH tunnel from their LAN, too > (where I'm also not concerned about abuse...) =46or collaboration setting DAV on is probably a better option as it uses=20 lockfiles and won't have one developer overwritting (un)wittingly changes=20 made by others. > The snag I'm finding at the moment I'm sure I'll overcome... and relates > to access from my LAN. While I can sort-of see how to establish a new > device with a new IP address on the remote LAN (with SSH and pppd) I'm > not sure how to establish a second IP address for my single Ethernet > adaptor to make this work on my LAN (though I'm sure it is do-able...) An adaptor can have more than one public IP address (multi-homing) and you = can=20 use something like: ifconfig eth0:0 192.168.0.2 netmask 255.255.255.0 up to= =20 set them up (increment eth0:1, eth0:2, etc accordingly). However, if your= =20 SSL vhost is listening on a random port you don't need binding of many=20 addresses to one NIC. You can use the same ip address. > I'm also curious to discover if there is a neat Gentooish way to > establish my two instances of Apache. I'm broadly familiar to doing > this a hackish way - but I'd prefer it plays nicely with any emerge > updates. Other than vhost I guest you can run a second instance by reading section 5= =20 here (but I'm not sure you need to do that anyway): http://www.gentoo.org/proj/en/php/php4-php5-configuration.xml =2D-=20 Regards, Mick --nextPart3747542.4bZTgmkCFx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkoDYhQACgkQVTDTR3kpaLaunwCg4RgxMtpaLKHtFqPiXD7JvdjY ZjMAoLLMT2J6USx6v6zVMDRrxtPfF/GD =wOiI -----END PGP SIGNATURE----- --nextPart3747542.4bZTgmkCFx--