...making Linux just a little more fun!
Ben Okopnik [ben at linuxgazette.net]
Hi, all -
I'm hoping that someone here has experience in setting up SVN. I'm running into several issues in setting it up for LG... frankly, it's mostly my own mental state more than anything else; 'buffer full' at the moment. Unsurprising, after a couple of weeks of full-time training course development, setting up LG in its new home, and learning a new language during all that. My brain is pretty cooked, and I desperately need a break. I'm just hoping that someone here has a shortcut; it shouldn't be that difficult, really.
What I'd like to do is set it up so that I don't have to create a system account for everyone who needs SVN access. We don't even need web access to the repo; we just need our editors and proofreaders to authenticate via whatever mechanism SVN uses, pull a copy of the repo, and check their work back in whenever they're done with it.
Any help - and the best of all possible world would be an offer like "I'd be happy to do it for you!" - would be very welcome.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Henry Grebler [henrygrebler at optusnet.com.au]
Hi Ben,
-->Any help - and the best of all possible world would be an offer like -->"I'd be happy to do it for you!" - would be very welcome.
I'd be happy to do it for you. To try, anyway.
I assume you can give me access. If I think about it, I already have access. Maybe.
If I think about it some more, I already have the access you say you want to give. So what am I missing?
My qualifications are that I have never done it before. And then, when I think about it a little harder, I think I have.
help subversion
Not much. Try other machine. Now that's better! Ok, I have done it before. Not for use outside the company, but networks are networks.
Perhaps you should contact me directly (outside TAG) and we can discuss it further. Then I can say:
What do you see? What do you want to see?
Or am I being a shameless self-promoter?
Cheers, Henry
TAG mailing list TAG@lists.linuxgazette.net https://lists.linuxgazette.net/listinfo/tag
Ben Okopnik [ben at linuxgazette.net]
Hi, Henry -
On Thu, Mar 17, 2011 at 09:05:52AM +1100, Henry Grebler wrote:
> > Hi Ben, > > > -->Any help - and the best of all possible world would be an offer like > -->"I'd be happy to do it for you!" - would be very welcome. > > I'd be happy to do it for you. To try, anyway. > > I assume you can give me access. If I think about it, I already have > access. Maybe.
Remember the part where I said "move LG into its new home"? It's been rehosted at a VPS.
[sigh] It's at times like these that a CMS, with a built-in versioning system, etc. begins to sound appealing. Maintaining the rather rickety and somewhat cumbersome lashup that the LG production system has become can be rather wearying.
> If I think about it some more, I already have the access you say you > want to give. So what am I missing?
Now that you've reminded me, I've created an account for you there (henry@linuxgazette.net), with your SSH key already installed.
> Perhaps you should contact me directly (outside TAG) and we can > discuss it further.
Will do.
> Then I can say: > > What do you see? > What do you want to see? > > Or am I being a shameless self-promoter?
You are shameless! But that's not the only reason we like you...
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Ben Okopnik [ben at linuxgazette.net]
On Wed, Mar 16, 2011 at 11:50:30PM +0100, jmanel wrote:
> Hi, > Some time ago i worked for a firm that every task was for yesterday > and I remember having to install a subversion. I don't remember doing > any other thing that follow instructions from a readme or similar. > Sorry, but no clue with the problem. I could try doing it remotely.
Hi, Josep; thanks for your offer. That's a great way to start here - welcome to TAG! - but between Dave Richardson and Henry Grebler, two of the highly-competent folks that we have here, I suspect that it's handled.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Dumont Jean [chaneau at gmail.com]
Le 16/03/11 21:49, Ben Okopnik a =E9crit :
> Hi, all - > =
Hi
The easiest way is to ask Apache to validate your users
Something along the lines:
<VirtualHost xx.xx.xx.xx:80> ServerName your.server.name # no need to explain DocumentRoot /var/www/ # does not matter won't be used RewriteEngine on # to go to the right url RewriteRule ^/$ /svn [L,R] # this one
# You can read the repositoory anonymously but not write to it
<Location /svn> DAV svn # turn the dav mode on SVNPath /your/svnroot # SVNIndexXSLT /svnindex.xsl # to customize the look AuthType Basic # no need to explain AuthName "Subversion repository" # whatever AuthUserFile /etc/subversion/password # Apache must be able to read it <LimitExcept GET PROPFIND OPTIONS REPORT> Require valid-user </LimitExcept> </Location>
# next an example with no access except when authentified
<Location /svn/documents> DAV svn SVNPath /svn-root-private SVNIndexXSLT /svnindex.xsl AuthType Basic AuthName "Subversion Documents repository" AuthUserFile /etc/subversion/password-docs Require valid-user </Location>
</VirtualHost>
You can then create your users with htpasswd and no need to have systems users
HTH
Good day and keep doing the fantastic job with LG
-- =
HTH TAG mailing list TAG@lists.linuxgazette.net https://lists.linuxgazette.net/listinfo/tag
Ben Okopnik [ben at linuxgazette.net]
Hi, Dumont -
On Thu, Mar 17, 2011 at 01:36:57PM +0100, Dumont Jean wrote:
> Le 16/03/11 21:49, Ben Okopnik a écrit : > > Hi, all - > > > Hi > > The easiest way is to ask Apache to validate your users
[snip]
That would be a terrific answer - a shortcut of exactly the sort that I asked for - if it did what we need it to do. I may be wrong, but I don't think it does. My fault for not clarifying this, but I've been doing it for so long that it just seemed like "the obvious thing"; it's clearly not.
The LG editing process all happens at the command line; every pass goes something like this:
svn update # Get the latest changes vi STATUS # Mark an article as "out for editing/proofing" svn commit # Check STATUS back in vi article.html # Edit the article vi STATUS # Update article status svn commit # Check it all back in
Apache isn't involved anywhere; neither is WebDAV. Configuring Apache
would be pretty simple; learning about WebDAV, etc. would be yet another
major task to take on - which just isn't in the cards. And having
everyone relearn a new method of doing this... like I said, at that
point, a CMS starts to look really good.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Ben Okopnik [ben at linuxgazette.net]
On Thu, Mar 17, 2011 at 02:20:17PM +0100, Dumont Jean wrote:
> > Well you asked for a solution where you do not have to create system > users the alternative is to use ssh with key authentication but unless > you are prepared to set up some LDAP I don't think you can do it without > creating users
OK; thanks for that overview (I'm ignorant enough of the whole SVN system that I didn't realize that.)
> We do use subversion on a daily basis with dozens of users having > different access rights to different parts of the repository and it's > very easy to set-up and maintain. > > And we use no graphical client at all if I must make a commit I just do > > (this is my last commit) > > svn ci -m 'Modified the schema to create an index for the categories'
Oh, OK - that is exactly the kind of interaction that we need.
> Sorry if I misunderstood your first request.
Maybe you didn't. Although I'm still not clear on how Apache
interacts with SVN to provide authentication, and I have no experience
or even the slightest knowledge about DAV.
I think that given the time constraints (the LG publishing cycle begins in just three days), I may be best off doing what I did previously, when I had no root access to the host account: that is, setting up SVN-only access via SSH using a single account for everyone. Having had a night of sleep has helped a bit with the mental burn-out, and I just might be able to handle that.
(I do have a pretty decent cure for that burnout, sitting just a few hundred yards away from me - I just bought a beautiful Yamaha Virago 1100 bike that rides like a dream. But, well, responsibilities. Dammit.)
https://motoprofi.com/motospecspictures/yamaha/xv_1100_virago-1995.html
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Ben Okopnik [ben at linuxgazette.net]
Hey there, Arslan!
On Thu, Mar 17, 2011 at 06:21:12PM +0500, Arslan Farooq wrote:
> Hi > > like I said, at that point, a CMS starts to look really good.> > I make websites in Joomla. But version control is not built-in in it.
WordPress has it, but then WordPress has everything. It's the ultimate
kitchen-sink - and that's just the default configuration. I've been
doing sites in it, and although I've had to write my own plugins a
couple of times, the usual answer is "it's already in there."
A friend has recommended TextPattern, and I've been very impressed with what I've seen so far. Minimalist, clean approach and fast. The only problem is, it doesn't produce static HTML (only a couple of CMSes do.) If I found one that was as clean as TextPattern and produced static HTML, I'd have shifted the production system to it long ago.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Dumont Jean [chaneau at gmail.com]
Le 17/03/11 14:47, Ben Okopnik a =E9crit :
Ok, I must not assume that my explanations are clear (english is not my first language nor my second so I'll try harder)
Subversion has no concept of authentication, so you must put in place some mechanism to authenticate your users
Usually you do that with a shell access using ssh and you put your users in a group which has write access to the physical path of your repository.
The url for the commit is something like this
svn ci svn+ssh...
That's one way to do it
The downside is that you have to give to your users shell access to your server although you can strictly restrict what they can do with ssh + pam options (but once again this is not trivial)
Another approach is to use Apache as a authentication proxy, all you have to do is enable the dav module and put your users in a file which Apache can read
the url for the commit is thus
svn ci https://myserver/myrepository
The downside is that you will be obliged to use username + password which will force you to use ssl on Apache if security is to be considered.
There is a third approach, you could set up a CA or obtain a certificate and distribute client certificates to your users.
Here, as we live in Belgium, we use our EID (Identity card delivered by the Belgian Government, we don't have a governement but we still have the cards ;-) ) and in fact I also used my FSFE card to authenticate myself.
So there are numerous choices to choose from but by far Apache is the easiest to implement if you don't want to create system users of course.
-- =
Jean TAG mailing list TAG@lists.linuxgazette.net https://lists.linuxgazette.net/listinfo/tag
Ben Okopnik [ben at okopnik.com]
On Thu, Mar 17, 2011 at 03:14:00PM +0100, Dumont Jean wrote:
> Le 17/03/11 14:47, Ben Okopnik a écrit : > > Ok, I must not assume that my explanations are clear (english is not my > first language nor my second so I'll try harder)
Jean, your English is excellent. I can only imagine myself having to do
this in French, and... well, I learned enough (Canadian) French after a
week in Montreal to order a "breuvage" (rather than a ""boisson"), but I
doubt that it would get me through SVN and Apache authentication.
Thank you for making the effort!
> Subversion has no concept of authentication, so you must put in place > some mechanism to authenticate your users > > Usually you do that with a shell access using ssh and you put your users > in a group which has write access to the physical path of your repository. > > The url for the commit is something like this > > svn ci svn+ssh... > > That's one way to do it
I think that I've got this running at this point. Maybe. I've tested it as much as I could (more on this in a bit), but here's what I did:
1) Created a 'gazette' system account. 2) Added all the SSH pubkeys to ~gazette/.ssh/authorized_keys in the "command" SSH format - i.e.,
command="svnserve -t --tunnel-user=joe",no-pty ssh-dss AAAAB3NzaC1kc3MAAACBAKOCcqOj4...
This does not allow logging in, but it does allow SVN transactions over SSH.
3) Tested it from several locations, using not only my own credentials but those of other LG staffers:
SVN_SSH='/usr/bin/ssh -l gazette -i /tmp/id_dsa.pub' svn checkout svn+ssh://linuxgazette.net/var/svn/linuxgazette.net lg_svn
Seems fine so far. Obviously, once the working copy is on your machine, you don't need to type out all of the above - mostly, this requires setting the SVN_SSH variable - but it should all be back to normal.
Oh, right - I still need to check out uploading. [sigh] Brain still not all there. I think I'm going to take a break and go bend the bike around some hairpin turns for a few hours.
Jean, even if your "only" contribution here were to be a sounding board, you've really helped out. Again, thank you!
Ben
--
OKOPNIK CONSULTING
Custom Computing Solutions For Your Business
Expert-led Training | Dynamic, vital websites | Custom programming
443-250-7895 https://okopnik.com https://twitter.com/okopnik
Ben Okopnik [ben at linuxgazette.net]
On Thu, Mar 17, 2011 at 10:52:56PM +0100, Marcello Romani wrote:
> Il 17/03/2011 14:02, Ben Okopnik ha scritto: > > > >The LG editing process all happens at the command line; every pass goes > >something like this: > > > >svn update # Get the latest changes > >vi STATUS # Mark an article as "out for editing/proofing" > >svn commit # Check STATUS back in > >vi article.html # Edit the article > >vi STATUS # Update article status > >svn commit # Check it all back in > > Ben, the workflow you listed above can be performed regardless of > how the svn client accesses the repository (yes subversion is THAT > good
I'd kinda gathered that.
> If the working copy is on the same host where the repository files > reside then the svn client can read and write them directly, without > any middleware inbetween.
Unfortunately, this is where the problem comes in. If it was on the same
host, then that would presume that everybody works on that same host...
and thus has an account on it, right?
In any case, it's all serviceable at this point - at least as far as all the testing I've done indicates. The only thing that's left is setting up the rsync server and the FTP server... and that's just going to have to wait. My time is pretty thoroughly commited for the next couple of weeks. FTP, I might be able to sneak in - it's a pretty trivial task, and one I'm thoroughly familiar with; rsync, on the other hand, isn't, and I just don't have the time to study all the pertinent issues.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Ben Okopnik [ben at linuxgazette.net]
On Fri, Mar 18, 2011 at 08:30:11AM +0100, Dumont Jean wrote:
> > Yes the solution you posted yesterday will work, I just see two flaws in > it, first you do have a system user albeit a single one
Oh, it wasn't a religious issue: I wasn't going to kill myself if I had
to set up so much as one single user account. I just didn't like the
idea of having to set up all those just to provide SVN access. Besides,
that's a non-login account anyway, which takes away all the maintenance
headaches.
> second this > is a solution that can't scale beyond a few contributors, I guess that > the management of the public keys alone would rapidly turn into a nightmare.
I'm not sure why you'd think that; I'll never have to do anything more complicated than copy and paste the "command section" of a line and then add the user's key. I've never had a reason to revoke anyone's SVN access, but if I ever did, deleting one line would do it. I suppose I could quickly crank out a GUI that would help me manage it... but I don't even see a reason to do that; it's pretty basic as it is.
> And besides how do you know who has committed? Just so you can put the > blame on somebody when everything is broken??
That is the one downside of this approach - but now that we've given
up on flogging and hanging for the first offense, it's not quite as
important as it used to be. Mostly, we rely on people to note who
they are in the SVN comments; i.e.
Finished editing knuth.html; checking out wirth.html next. -- HLMencken
It's always worked fine (although I suspect we're going to see a few
"Horace Greely" entries and maybe a "Max Perkins" or two in there now
that I've said this. If that ever becomes important - well, it's a
lot easier to go from a nominally-working system to an improved one
rather than making it all work from scratch. This gives us at least the
basic functionality, which is good enough for the moment.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Ben Okopnik [ben at okopnik.com]
Hi, Henry -
On Sat, Mar 19, 2011 at 11:53:01AM +1100, Henry Grebler wrote:
> > Ben wrote: > > -->In any case, it's all serviceable at this point - at least as far as all > -->the testing I've done indicates. The only thing that's left is setting > -->up the rsync server and the FTP server... and that's just going to have > > rsync server? I must have missed something. I don't recall hearing > anything about an rsync server.
Those are two of the ways, aside from HTTP, in which we make our archives available to our mirrors (and anyone else who wants them.)
https://linuxgazette.net/ftpfiles/
Normally, we would have all of the above available via rsync as well - but we don't, at the moment.
> Look, it's not intended as a criticism. And what keeps running around > in my brain (for more than just this reason) is the old saw, "When > you're up to your ass (arse) in alligators (crocodiles), it's easy to > forget that the initial objective was to drain the swamp."
The original objective was to set up LG so that we can provide all the services we used to. 'rsync' has been a problem for quite a while, because our previous hosting arrangement turned out to have a policy prohibiting rsync along with any other daemons. Therefore, bye-bye former hosting arrangement.
> I guess if you had the time to spec out everything you want, you'd > pretty much have cracked most of your problems.
Actually, I've listed all that's left. Setting everything up was a pretty major undertaking, but it's almost done. /Viva Linux!/
> Since you have ssh access, you don't actually need an rsync server.
I'm afraid you're operating from a false perspective, Henry; the purpose of rsync in this case is not to give us access - it's to provide access for the world.
> You can do whatever you need with simple rsync over ssh. I'm also not > clear why you need an rsync server and an ftp server. Don't they do > about the same thing (with different amounts of security)? And doesn't > rsync do everything ftp does, only as well or better?
FTP is what some people use to download our archives - and it's there for the same reason as rsync. No security issue obtains, since it's all anonymous access.
> What I think I'm missing is what was it in what existed previously > that you feel is unsatisfactory? What problems are you trying to > solve?vvvvvvvvvv Nothing. Which is why I'm trying to bring up this new system up to speed. ^^^^^^^^^^
> My next thought goes along these lines. It seems that you have had a > change of venue forced upon you.
Nope. I saw a net gain to rehosting LG, and put in the effort to get it done.
> I would advise caution; and recommend a two-step approach. (Especially > because, as I understand it, there is no fall-back.) Having been > forced to move, simply aim for replication. Make improvement a > subsequent objective. That approach buys you time. Act in haste, > repent at leisure.
It's done. The bridge is long burned, the ashes and the remains of the main span have fallen into the fast-flowing river below and been swept downstream. Furthermore, the fires are out - there isn't even any residual heat left. Birds have built nests in the charred remains; winter has come and gone, and a new generation of hatchlings is cracking the shells peering out at the world, and uttering hungry cries.
The point you're talking about, in other words, is long past.
> You said something about having to get the next edition of LG out. If > you start messing with the (production) environment at such a crucial > time, you might end up with paradise;
Nonono. The production environment needed to be brought into working order; thus, the desperate need for SVN. Now that it's up, the production environment is in working order.
> O, that way madness lies; let me shun that; > No more of that. > - King Lear.
...
Thou think'st 'tis much that this contentious storm Invades us to the skin: so 'tis to thee; But where the greater malady is fix'd, The lesser is scarce felt. Thou'ldst shun a bear; But if thy flight lay toward the raging sea, Thou'ldst meet the bear i' the mouth.
The raging sea is stilled, and the only remaining bears are quite small
and rather inoffensive.
> Of course, I've probably missed something crucial.
Minor details, is all.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Francis Daly [francis at daoine.org]
On Fri, Mar 18, 2011 at 10:06:01AM -0400, Ben Okopnik wrote:
> On Fri, Mar 18, 2011 at 08:30:11AM +0100, Dumont Jean wrote:
Hi there,
Unlike the ftp and rsync mails, this one is not from any experience, but purely from manual-reading. So assume the appropriate amount of salt...
[re-added from earlier Ben-mail]
> here's what I did: > > 1) Created a 'gazette' system account. > 2) Added all the SSH pubkeys to ~gazette/.ssh/authorized_keys in the > "command" SSH format - i.e., > > command="svnserve -t --tunnel-user=joe",no-pty ssh-dss AAAAB3NzaC1kc3MAAACBAKOCcqOj4... > > This does not allow logging in, but it does allow SVN transactions over > SSH.
> > And besides how do you know who has committed? Just so you can put the > > blame on somebody when everything is broken?? > > That is the one downside of this approach
What you've set up seems to be pretty much by the book -- the book being https://svnbook.red-bean.com/ -- and according to (my reading of) chapter 6 "Server Configuration", section "svnserve, a Custom Server", subsections "svnserve over a tunnel" and "Controlling the invoked command", what you have done should Just Work:
""" the --tunnel-user option tells svnserve to assume that the named argument is the authenticated user. Without --tunnel-user, it would appear as though all commits were coming from the one shared system account. """
(A bit further down, there is an extra note
""" To give the user as little permission as possible, you may want to specify a number of restrictive options immediately after the command:
command="svnserve -t --tunnel-user=harry",no-port-forwarding,no-agent-forw arding,no-X11-forwarding,no-pty TYPE1 KEY1 harry@example.com """
all on one line; but possibly the sshd_config already enforces the no-*-forwarding rule for the gazette user.)
So if you test with two different ssh keys, and modify a file each time, then a later "svn log" should (hopefully) show that two different users had been there.
Theory is a wonderful thing, of course; and what is present now is presumably working well enough for the immediate need; and Copious Free Time is just over the next horizon; so it's not worth spending more effort now on checking all this.
But maybe it's already perfect.
Cheers,
f
--
Francis Daly francis@daoine.org
TAG mailing list
TAG@lists.linuxgazette.net
https://lists.linuxgazette.net/listinfo/tag
Ben Okopnik [ben at okopnik.com]
On Fri, Mar 18, 2011 at 07:52:43PM -0700, Joey Prestia wrote:
> On 3/18/2011 6:12 AM, Ben Okopnik wrote: > > > > In any case, it's all serviceable at this point - at least as far as all > > the testing I've done indicates. The only thing that's left is setting > > up the rsync server and the FTP server... > > Rsync is set up and working as it was originally.
Joey, you're terrific! Thank you!
> Entire archive > > rsync -azv linuxgazette.net::lg-all /HTTP_ROOT > > Exclude FTP files > > rsync -azv --exclude /ftpfiles/ linuxgazette.net::lg-all /HTTP_ROOT > > Only FTP files > > rsync -azv linuxgazette.net::lg-ftp /FTP_ROOT
I've updated our ftpfiles/README.mirrors. I'll leave the pleasure of
notifying our mirror sites to you.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Ben Okopnik [ben at linuxgazette.net]
On Sat, Mar 19, 2011 at 03:46:15PM +0000, Francis Daly wrote:
> On Fri, Mar 18, 2011 at 10:06:01AM -0400, Ben Okopnik wrote: > > > > command="svnserve -t --tunnel-user=joe",no-pty ssh-dss AAAAB3NzaC1kc3MAAACBAKOCcqOj4... > > > > This does not allow logging in, but it does allow SVN transactions over > > SSH. > > > > And besides how do you know who has committed? Just so you can put the > > > blame on somebody when everything is broken?? > > > > That is the one downside of this approach > > What you've set up seems to be pretty much by the book -- the book being > https://svnbook.red-bean.com/ -- and according to (my reading of) chapter 6 > "Server Configuration", section "svnserve, a Custom Server", subsections > "svnserve over a tunnel" and "Controlling the invoked command", what > you have done should Just Work: > > """ > the --tunnel-user option tells svnserve to assume that the named argument > is the authenticated user. Without --tunnel-user, it would appear as > though all commits were coming from the one shared system account. > """
Hmm, odd - we've been doing this "--tunnel-user" stuff for a year now, and the logs have always just read "gazette". It makes sense, but I guess something else is needed to make it work.
> (A bit further down, there is an extra note > > """ > To give the user as little permission as possible, you may want to > specify a number of restrictive options immediately after the command: > > command="svnserve -t --tunnel-user=harry",no-port-forwarding,no-agent-forw > arding,no-X11-forwarding,no-pty TYPE1 KEY1 harry@example.com > """ > > all on one line; but possibly the sshd_config already enforces the > no-*-forwarding rule for the gazette user.)
Heh, you've caught me. I snipped all that stuff just so I wouldn't have to wrap the line; it's actually
command="svnserve -t --tunnel-user=xxx",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAAB3Nza [...]
> So if you test with two different ssh keys, and modify a file each time, > then a later "svn log" should (hopefully) show that two different users > had been there.
Hmm? I don't quite get this. Everybody does indeed use their own SSH key.
> Theory is a wonderful thing, of course; and what is present now is > presumably working well enough for the immediate need; and Copious Free > Time is just over the next horizon; so it's not worth spending more > effort now on checking all this. > > But maybe it's already perfect.
Not quite yet - having the log be stamped with the right name would be quite nice albeit not 100% necessary - but it's all definitely workable.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Ben Okopnik [ben at linuxgazette.net]
On Sat, Mar 19, 2011 at 03:49:41PM -0700, Joey Prestia wrote:
> > Ben, > > You may want to update the following link too. > > https://linuxgazette.net/faq/mirrors-faq.html
Right; thanks for the reminder. Done.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Ben Okopnik [ben at linuxgazette.net]
On Sat, Mar 19, 2011 at 02:47:51PM +0000, Francis Daly wrote:
> > In case it is still useful: > > for anonymous read-only ftp access to world-readable files below one > specific directory, "install vsftpd" is probably a good starting point.
Yep; that's what I've been using on my other systems - including my laptop, which I use as a fallback server for when a classroom setup at a client's place falls apart. A nice minimum chroot environment in there, too. I should probably write an article someday, when I'm not swamped.
> The default compile-time defaults disallow authenticated (system user) > login, and disallow any uploading, and disallow getting a file without o+r > set, and disallow any access outside the ftp-user home directory. An empty > /etc/vsftpd.conf will probably do most of what you want.
Mostly, what was needed was
listen=YES anonymous_enable=YES write_enable=NO anon_upload_enable=NO anon_root=/var/www/linuxgazette.net/ftpfiles/
The last one isn't in the conffile (which is rather silly), and is kinda hard to find in the docs, but I remembered it from the last time I set up an anonymous FTP server.
Which is up and running now. So the LG system is now happily working
in every particular - although there will be much tweaking, fiddling,
gnashing of teeth, and wailing unto the uncaring universe in the future.
But it's all good.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *