Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
For a handy pound port see: http://folesvaert.no/pound/ /Pete On 9 Jul 2007, at 4:59 PM, Richard Wilson wrote: > Stuart Henderson wrote: >> On 2007/07/08 15:30, Chris Cappuccio wrote: >>> Stuart Henderson [EMAIL PROTECTED] wrote: Or use different ports and proxy them based on host headers rather than burning IP addresses (for some RIR you are expected not to use IP addresses for non-SSL virtual web hosting). I haven't checked, but hoststated should be able to do this. >>> What software would you run on port 80 to break out the requests >>> to the >>> various apache instances? Squid with accelerator mode seems like >>> a massive >>> beast to use for this purpose. Any smaller apps? >> >> I thought you may already be able to use hoststated but I was >> mistaken. >> The least intrusive way to add it there may be to provide a new >> action >> that matches on the Host: header and allows the table name to be >> over- >> ridden (obviously this is only any good with relay, not PF tables). >> >> Other than that, it looks like Apache mod_proxy (ProxyPass) can be >> configured per-virtual-host so that should work. >> >> http://www.apsis.ch/pound/ is another option but I don't know how >> well it works on OpenBSD. I think I've seen it run here, but I don't >> know if it really works well. >> >> Varnish can probably do this too, but doesn't run here at all. >> (It's a bit of an unusual app...) >> > > I can vouch that Pound works very well on OpenBSD, and is very BSD- > like > in its style and philosophy, the developers aiming of simple, > readable, > provable code doing a specific job well. > > -- > > Richard 'Dave' Wilson > Systems Administrator > > Senokian Solutions Ltd. > Business Innovation Centre, > Binley Business Park, Coventry, > United Kingdom > CV3 2TX > T: +44 (0)24 76 233 400 > DDI: +44 (0)24 76 233 416 > F: +44 (0)24 76 233 401 > Pete Vickers [EMAIL PROTECTED] | +47 48 17 91 00 SystemNet AS
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
Stuart Henderson wrote: > On 2007/07/08 15:30, Chris Cappuccio wrote: >> Stuart Henderson [EMAIL PROTECTED] wrote: >>> Or use different ports and proxy them based on host headers rather >>> than burning IP addresses (for some RIR you are expected not to use >>> IP addresses for non-SSL virtual web hosting). >>> >>> I haven't checked, but hoststated should be able to do this. >> What software would you run on port 80 to break out the requests to the >> various apache instances? Squid with accelerator mode seems like a massive >> beast to use for this purpose. Any smaller apps? > > I thought you may already be able to use hoststated but I was mistaken. > The least intrusive way to add it there may be to provide a new action > that matches on the Host: header and allows the table name to be over- > ridden (obviously this is only any good with relay, not PF tables). > > Other than that, it looks like Apache mod_proxy (ProxyPass) can be > configured per-virtual-host so that should work. > > http://www.apsis.ch/pound/ is another option but I don't know how > well it works on OpenBSD. I think I've seen it run here, but I don't > know if it really works well. > > Varnish can probably do this too, but doesn't run here at all. > (It's a bit of an unusual app...) > I can vouch that Pound works very well on OpenBSD, and is very BSD-like in its style and philosophy, the developers aiming of simple, readable, provable code doing a specific job well. -- Richard 'Dave' Wilson Systems Administrator Senokian Solutions Ltd. Business Innovation Centre, Binley Business Park, Coventry, United Kingdom CV3 2TX T: +44 (0)24 76 233 400 DDI: +44 (0)24 76 233 416 F: +44 (0)24 76 233 401
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
On 2007/07/08 15:30, Chris Cappuccio wrote: > Stuart Henderson [EMAIL PROTECTED] wrote: > > > > Or use different ports and proxy them based on host headers rather > > than burning IP addresses (for some RIR you are expected not to use > > IP addresses for non-SSL virtual web hosting). > > > > I haven't checked, but hoststated should be able to do this. > > What software would you run on port 80 to break out the requests to the > various apache instances? Squid with accelerator mode seems like a massive > beast to use for this purpose. Any smaller apps? I thought you may already be able to use hoststated but I was mistaken. The least intrusive way to add it there may be to provide a new action that matches on the Host: header and allows the table name to be over- ridden (obviously this is only any good with relay, not PF tables). Other than that, it looks like Apache mod_proxy (ProxyPass) can be configured per-virtual-host so that should work. http://www.apsis.ch/pound/ is another option but I don't know how well it works on OpenBSD. I think I've seen it run here, but I don't know if it really works well. Varnish can probably do this too, but doesn't run here at all. (It's a bit of an unusual app...)
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
Stuart Henderson [EMAIL PROTECTED] wrote: > > Or use different ports and proxy them based on host headers rather > than burning IP addresses (for some RIR you are expected not to use > IP addresses for non-SSL virtual web hosting). > > I haven't checked, but hoststated should be able to do this. What software would you run on port 80 to break out the requests to the various apache instances? Squid with accelerator mode seems like a massive beast to use for this purpose. Any smaller apps?
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
> > >You don't want user 1's web applications to be able to access data in user > > >2's web application storage space. > > I will only be using mod_php. In the past, without the user shell > > accounts, this has worked rather well for me in combination with the > > "open_base_dir" directive in the VirtualHost. > > This binds PHP's abilities to the specified directory (or directories) > > for that specific virtual host. > > > > Am I overlooking something with that setup? > > I get the impression from your reply this might be rather unsafe? A timely note: http://www.theregister.co.uk/2007/07/03/mpack_reloaded/ 'SANS Institute researchers conclude. "Check if your hosting company uses chroot and/or suExec because that is the only way to make sure that your own web site will not be compromised by other users sharing the same physical server."'
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
On 2007/06/30 20:23, Chris Cappuccio wrote: > For the rest, just give each domain name/user > their own httpd instance running with its own config, its own unix user, and > its own IP address. Or use different ports and proxy them based on host headers rather than burning IP addresses (for some RIR you are expected not to use IP addresses for non-SSL virtual web hosting). I haven't checked, but hoststated should be able to do this.
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
I've found that most clients don't need or expect to login to a web server. The handful of people that do can be given their own dedicated server to use or something like that. For the rest, just give each domain name/user their own httpd instance running with its own config, its own unix user, and its own IP address. Or give each domain two users-one user to own the file system and a separate one that is selectively given permission to write within that filesystem. Run httpd chrooted, and you can use any module you want without sharing write permissions between unix users (shared webhosting evil). Give all the users chrooted access to their own web root files through ftp or sftp. I've never tried to chroot sftp, or at least there is no obvious way to do it to me. But, since no unix user needs access to another's directory tree, it's pretty easy to lock people out of places they don't need to be. You need to give SSL users their own IP address anyways, and this technique makes it easier to ensure security on a shared server. It is a bit more resource intensive since each virtual host has several apache processes running, but apache will scale down the number of processes when hits are low and modern hardware is fast and big enough that this becomes a decent compromise for resource usage (versus multiple virtualized OS servers or whatever.) For email it is nice to keep the users in an sql or ldap database, use one of a million web/database mangement tools for it, and point your software to use it. I like postfix and dovecot but i am not overjoyed with any of the mediocre web tools for managing the virtual users and whatever else. A well thought out database driven system can be fairly easy to scale as disk or cpu load increases by using multiple data stores, pop/imap proxies and multiple front end spam processors. There are lots of examples of these sorts of designs available through google so I won't bore you anymore. Also if you have the right kind of user popluation, a significant percentage expect MS Frontpage support. These are always the same peopel who don't ever ask for shell access. MS Frontpage is fairly easy to do with some mod_rewrite rules and a custom CGI that calls the MS cgi (i386 bsdos executable). There are almost certainly buffer overflows in the MS cgi. So if you are running a chrooted per-user apache installation, you can theoretically limit potential damage to the user. suexec would be the only privileged binary in the chroot (and not necessary if the apache user has write permission where expected). Chris
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
On Sat, Jun 30, 2007 at 05:51:22PM +0200, Matt wrote: > >You don't want user 1's web applications to be able to access data in user > >2's web application storage space. > I will only be using mod_php. In the past, without the user shell > accounts, this has worked rather well for me in combination with the > "open_base_dir" directive in the VirtualHost. > This binds PHP's abilities to the specified directory (or directories) > for that specific virtual host. > > Am I overlooking something with that setup? > I get the impression from your reply this might be rather unsafe? I'm no PHP expert. If you're sure the PHP interpreter will restrict your users' accounts to their own directory, then good. But note: - you must trust it to enforce this in all possible circumstances (rather obviously, for example, your users' PHP scripts must not be able to fork/exec any external program or script which could have been written by the user, nor load any untrusted C extensions, nor modify the environment for external programs); - you must trust both the PHP interpreter and the web server not to have any remotely-exploitable holes, since anyone who breaks in as the web server user will have read *and* write access to everyone's data files; - you must be sure that as well as locking everything down, you've not inadvertently left any way for users to change the restrictions (e.g. in .htaccess) Now, finding documentation for this feature was hard. It appears that it's actually called "open_basedir", not "open_base_dir". See http://www.php.net/manual/en/features.safe-mode.php It looks like every single library function in PHP which opens files must validate this setting. Given PHP's security track record, I'm not sure I'd bet my business on it. You'll also need to take care with file permissions, given that you're now giving shell accounts to each user with their own uids. Each user will need to have read/write access on their own files of course, and grant read/write access to the webserver's gid, but without being members of the webserver group themselves (otherwise they'd be able to read/write all the other users' files). You may be able to achieve this by suitable checks on the top-level directory, and making files world-writable inside (ergh). Otherwise, welcome to sticky-bit city :-) Regards, Brian.
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
Brian Candler schreef: In their homedir there is a `ln -s` to their /var/www/home/username webspace. That webspace is chowned username:www and chmodded 770 so httpd can access/write to their dir as well. Is that advisable / workable? Other ideas? You don't want the www user being able to write to your web space. Think about it. DS Just did - Thanks for pointing that out. So that should be chmod 750. You've raised an interesting point though. This is fine if all they want to do is serve static content. But it gets hairier if they want to run CGIs, and even hairer again if they want to run long-lived processes which handle multiple requests (such as Rails, or mod_php for php intensive sites) You don't want user 1's web applications to be able to access data in user 2's web application storage space. I will only be using mod_php. In the past, without the user shell accounts, this has worked rather well for me in combination with the "open_base_dir" directive in the VirtualHost. This binds PHP's abilities to the specified directory (or directories) for that specific virtual host. Am I overlooking something with that setup? I get the impression from your reply this might be rather unsafe? Thanks, Matt
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
> >>In their homedir there is a `ln -s` to their /var/www/home/username > >>webspace. That webspace is chowned username:www and chmodded 770 so > >>httpd can access/write to their dir as well. > >>Is that advisable / workable? Other ideas? > > > >You don't want the www user being able to write to your web space. > >Think about it. > > > >DS > > > Just did - > Thanks for pointing that out. > So that should be chmod 750. You've raised an interesting point though. This is fine if all they want to do is serve static content. But it gets hairier if they want to run CGIs, and even hairer again if they want to run long-lived processes which handle multiple requests (such as Rails, or mod_php for php intensive sites) You don't want user 1's web applications to be able to access data in user 2's web application storage space. Apart from allowing a malicious user 1 to access or modify private data belonging to user 2, an unintentional security hole in any user's site could also expose all the other users' data. If users are writing or installing their own web apps, I can *guarantee* you'll end up with a Swiss cheese, so containment is critical. If you can give each of your users a sysjail [or virtual machine], bound to its own IP address, then the problem goes away. Each user can simply run their own webserver inside their own file system space. If the users only need to run one-shot CGIs, then you can use cgiwrap or suexec. But those can get very resource intensive, e.g. if every PHP page hit spawns a fresh PHP interpreter and loads in a zillion libraries. With some care you might be able to set up something with fastcgi, at least for serving PHP pages, but adding individual user's apps as different fastcgi processes running as their own UIDs will get awkward if you have to modify a central httpd.conf for each change they request. If the users need to share a single outside IP address, then you can still run a separate webserver for each user, bound to a high port, running as their own UID. But then you need a proxy webserver in front to redirect incoming requests on port 80 to the correct port. Apache mod_proxy does this just fine, but there is some fiddling to do to ensure that the source IP address is still seen as the real outside address (check out mod_extract_forwarded), so that logs and access controls work properly. Personally I think the proxy solution is a good one, as long as you're talking about hosting tens of sites, not tens of thousands, as it gives each user full control over their own web server's configuration (or indeed to run a completely different webserver). Remember that this will result in extra web server processes sitting around consuming RAM. There's also a race risk that when user 1 kills their webserver, user 2 could maliciously bind to user 1's port. In some ways the best solution ultimately is to go with jails, or full VMs. In that case, when user 1 asks you to upgrade mod_fribble from version 0.99a to 1.73b, you can do this confidently (or even let them do it themselves) without any risk of accidentally breaking other users. Disk space is very cheap these days, although RAM and other virtualisation overhead is less so. Regards, Brian.
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
On Fri, Jun 29, 2007 at 09:41:49PM +0200, Almir Karic wrote: > >> i like virtual mail users. I don't. But that's me. > > if you have relativelly few users the postfix hashes should do the > trick, there is one annoyance tho, after every edit you have to run > postmap (easily solvable by wrapper scripts). i tend to use mysql, > maybe it is because i'm used to it. > > if you have trully big setups you might wanna look at ldap, from what > i've heard/read it should perform well under heavy read intensive > operations. > Err... No. NOTHING outperforms flat files. LDAP is good, but not that good. The more users that you have, the *more* likely you are to use postfix's builtin maps (esp btree). The way that ISP's often do it: Keep customer data in a Postgres database (views, forigen keys, ACID, triggers, stored procedures, functions,. this is what a database is for) Support staff and customers can web into this and manipulate accounts. Heck, even give the account's lassie a button where she can suspend services for non-payment. Customer data != OS data. Have scripts that pull data from (materialised) views periodically, use that data to generate the postfix maps. Diff the new maps to the live ones, and install the new ones if there is a difference, on all of the MTA boxes in your mail farm. When you have (tens of) thousands of users, your CPU is going to be busy with spam and virus filtering, and SQL is just way to slow. LDAP is faster, but it is just as much work to set up as is some perl/shell scripts to set up maps. But you have introduced a weak point, namely LDAP must be online for you to receive mail. Repeat the above for passwd, httpd.conf, ftpusers, ftpchroot, sshd_config, quota.user, mailman, courier, mysql wont help you with half of the services that you'll end up offering, so why bother? And just so you don't think that I'm anti SQL, I work as an SQL Data Analyst. Before that, I worked as a sysadmin, and before that, I worked as a sysadmin for a national ISP. Just take the time to think about what it is that you want to achive, and work back from there, using the bare minimum of stuff, because stuff goes wrong. e.g: you place all of your trust in a database, and a new release comes out, that enforces strict practices that your schema does not adhere to. You upgrade, can't serve requests for week while you alter all of your data, your name is mud. If you use flat files, kill the update cronjobs so that things run as they are, fix your data, and then you can insert new customers. But your existing customers are unaware that there was a problem at your end as the vast bulk of business went on as normal. SQL is complex, and complex equals unreliable. It has its place, but be careful where you use it. -- Craig Skinner | http://www.kepax.co.uk | [EMAIL PROTECTED]
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
On 6/29/07, Daniel Ouellet <[EMAIL PROTECTED]> wrote: Almir Karic wrote: > if you have trully big setups you might wanna look at ldap, from what > i've heard/read it should perform well under heavy read intensive > operations. I always see a lots of LDAP talks and some documents on it for many things including managing multiples users on multiples servers as a way to make life easier. To be honest. I never set one up yet. Doesn't know much about it either. Always been on my list of things to learn and explore. I guess I never came across a very good document that explain it so well to me with pro/cons to trigger my interest to try it yet. Lots on the net for sure. It just haven't grab me yet. May be that's the best things after slice bread and I am missing out. I don't know. May be if someone have a reference they ever come across that really trigger their interest and turn them to it, I would love to read it. I would very much appreciate the pointers to much reading. My ignorance on that subject always makes me think that it could be done with SQL, what ever flavor you like, so why yet use an other database LDAP? See my total dark side to it. (;> I never came across a reason or reading to push me to learn it and see it as better then other solutions. I am more then open to be put in the 21th century and learn it however if that's so blind of me. http://www.ldapman.org/articles/intro_to_ldap.html IMO good intro to ldap. if you just want to deploy a not-huge mail server you probably won't see any advantages of ldap over mysql. what you can do with ldap (IMO) much better than with mysql is ACL, i found the 'self' to be pretty nice, example: access to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=my,dc=domain" write by anonymous auth by self write by * none -- almir
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
Almir Karic wrote: if you have trully big setups you might wanna look at ldap, from what i've heard/read it should perform well under heavy read intensive operations. I always see a lots of LDAP talks and some documents on it for many things including managing multiples users on multiples servers as a way to make life easier. To be honest. I never set one up yet. Doesn't know much about it either. Always been on my list of things to learn and explore. I guess I never came across a very good document that explain it so well to me with pro/cons to trigger my interest to try it yet. Lots on the net for sure. It just haven't grab me yet. May be that's the best things after slice bread and I am missing out. I don't know. May be if someone have a reference they ever come across that really trigger their interest and turn them to it, I would love to read it. I would very much appreciate the pointers to much reading. My ignorance on that subject always makes me think that it could be done with SQL, what ever flavor you like, so why yet use an other database LDAP? See my total dark side to it. (;> I never came across a reason or reading to push me to learn it and see it as better then other solutions. I am more then open to be put in the 21th century and learn it however if that's so blind of me. Best, Daniel
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
Daniel Ouellet schreef: 3) Mail setups I can find lots of setups with virtual mailusers. I have been succesfully using a Courier-imap/Postfix/MySQL setup for several years i like virtual mail users. I am curious about this statement here. Care to provide more details? The setup I have been using for a long time now is based on this document: http://postfix.wiki.xs4all.nl/index.php?title=OpenBSD_PostfixAdmin_Guide I've succesfully used that on everything up to (and including) 4.1, although there are some small changes. Namely the courier-auth libs are now different packages. However I have never liked the sasl2 / imap connection setup - it seems a bit dodgy. Then again I am not anywhere near able to come up with something better. Any new mailboxes / aliases / etc are immediately available, which is nice and convenient. Downside is MySQL has now become a point of failure for maildelivery. Matt
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
On 6/29/07, Daniel Ouellet <[EMAIL PROTECTED]> wrote: >> 3) Mail setups >> >> I can find lots of setups with virtual mailusers. I have been >> succesfully using a Courier-imap/Postfix/MySQL setup for several years >> now, connected to a webbased mailmanagement tool. >> If I was to drop all that in favor of a more 'core' OpenBSD setup - what >> would be a nice maintainable (both for users and myself) way to offer >> single users multiple domains / mailboxes? > > i like virtual mail users. I am curious about this statement here. Care to provide more details? I used to do and am still doing a lots of it in QMail that is changing for postfix now and was actually going to add MySQL backend for that to make my life easier to manage multiple domains and obviously multiple users. I am curious at the replay as it may look like you have something more efficient? I was actually looking to just possibly use the postmap with hash may be, or may be the built db tools. Wasn't sure however if that would be best then MySQL. Obviously much smaller setup. Simpler is always better anyway. So, I would appreciate just a bit more suggestion, or details on your statement, so that may be something better I haven't thought of yet might be best. I am sure not oppose to use MySQL however. As for any web tools, I could care less. CLI is plenty good for me and anyone else here. SSH access does wonders... (:> what excatly are you curious about? :) if you have relativelly few users the postfix hashes should do the trick, there is one annoyance tho, after every edit you have to run postmap (easily solvable by wrapper scripts). i tend to use mysql, maybe it is because i'm used to it. if you have trully big setups you might wanna look at ldap, from what i've heard/read it should perform well under heavy read intensive operations. -- almir
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
3) Mail setups I can find lots of setups with virtual mailusers. I have been succesfully using a Courier-imap/Postfix/MySQL setup for several years now, connected to a webbased mailmanagement tool. If I was to drop all that in favor of a more 'core' OpenBSD setup - what would be a nice maintainable (both for users and myself) way to offer single users multiple domains / mailboxes? i like virtual mail users. I am curious about this statement here. Care to provide more details? I used to do and am still doing a lots of it in QMail that is changing for postfix now and was actually going to add MySQL backend for that to make my life easier to manage multiple domains and obviously multiple users. I am curious at the replay as it may look like you have something more efficient? I was actually looking to just possibly use the postmap with hash may be, or may be the built db tools. Wasn't sure however if that would be best then MySQL. Obviously much smaller setup. Simpler is always better anyway. So, I would appreciate just a bit more suggestion, or details on your statement, so that may be something better I haven't thought of yet might be best. I am sure not oppose to use MySQL however. As for any web tools, I could care less. CLI is plenty good for me and anyone else here. SSH access does wonders... (:>
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
On 6/29/07, Matt <[EMAIL PROTECTED]> wrote: 2) Chroot jails / limited shells - do's and don'ts I understand the implications of chroot jails. I understand they are not worth the risk. Which is a shame really as they bring certain functionality (or limits if you will) that I would consider nice to have. How do you prevent people from snooping around the system, looking for that sloppy permissioned file / gathering intelligence about your clientbase? All by setting permissions manually? How do you prevent them from compiling and installing all sorts of things? regarding the info about client database, it depends what kind of backend are you using, if it is flat files than permissions are sane way to protect them IMO. regarding compiling, IMO not worth the hassle to try to prevent that, it is not really hard to compile the code on other machine + lack of compiler makes it painfull for you to follow -current. regarding all sorts of junk that they might throw at you, well, i use ulimit. it works. 3) Mail setups I can find lots of setups with virtual mailusers. I have been succesfully using a Courier-imap/Postfix/MySQL setup for several years now, connected to a webbased mailmanagement tool. If I was to drop all that in favor of a more 'core' OpenBSD setup - what would be a nice maintainable (both for users and myself) way to offer single users multiple domains / mailboxes? i like virtual mail users. 4) Other considerations Any advice on what to avoid and what to certainly do/check/follow up on is appreciated. I will certainly miss stuff that might present a problem down the road. For instance things like cronjobs- do you limit their use by custom scripts or do you just monitor abuse? IMO not worth the effort to restrict usage of crontab. (afterall it is fairly simple to setup ssh keys and a cronjob on local machine that will execute some code/script/whatever) I am aware of things like 'accounting', 'quota' and 'ulimit' - any other handy utils I might check? logcheck (never set it up on OBSD tho, just linux). -- almir
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
Darren Spruell schreef: On 6/29/07, Matt <[EMAIL PROTECTED]> wrote: In their homedir there is a `ln -s` to their /var/www/home/username webspace. That webspace is chowned username:www and chmodded 770 so httpd can access/write to their dir as well. Is that advisable / workable? Other ideas? You don't want the www user being able to write to your web space. Think about it. DS Just did - Thanks for pointing that out. So that should be chmod 750. Matt
Re: Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
On 6/29/07, Matt <[EMAIL PROTECTED]> wrote: In their homedir there is a `ln -s` to their /var/www/home/username webspace. That webspace is chowned username:www and chmodded 770 so httpd can access/write to their dir as well. Is that advisable / workable? Other ideas? You don't want the www user being able to write to your web space. Think about it. DS
Setting up a virtual hosting machine w. SSH/SFTP accounts - pitfalls/experiences?
Hello, Someone far more experienced than me challenged my take on virtual hosting setups. I am accustomed to having virtual users, not real users, doing stuff with MySQL backends etc. My ideas now seem to have corrupted that what made me choose OpenBSD in the first place. I would like to setup a multi user (real accounts) hosting machine without using any MySQL/web-gui kind of user management. For you perhaps intuitive and elementary stuff, for me a bold and new undertaking. So I would really like some advise on this from those of you that have been working with non-virtual hosting setups all along. 1) What kind of permission scheme is sane for non-jailed user accounts (SSH+SFTP) These are website owners that need nothing fancy but being able to edit their site(s), manage their e-mail and edit their zone-files. All of this is now virtual (and with regular FTP chrooted). My setup so far consists of the user accounts in /home - owned by username:username and chmodded 700. In their homedir there is a `ln -s` to their /var/www/home/username webspace. That webspace is chowned username:www and chmodded 770 so httpd can access/write to their dir as well. Is that advisable / workable? Other ideas? 2) Chroot jails / limited shells - do's and don'ts I understand the implications of chroot jails. I understand they are not worth the risk. Which is a shame really as they bring certain functionality (or limits if you will) that I would consider nice to have. How do you prevent people from snooping around the system, looking for that sloppy permissioned file / gathering intelligence about your clientbase? All by setting permissions manually? How do you prevent them from compiling and installing all sorts of things? Is it possible/maintainable at all without chrootjails for your users? 3) Mail setups I can find lots of setups with virtual mailusers. I have been succesfully using a Courier-imap/Postfix/MySQL setup for several years now, connected to a webbased mailmanagement tool. If I was to drop all that in favor of a more 'core' OpenBSD setup - what would be a nice maintainable (both for users and myself) way to offer single users multiple domains / mailboxes? 4) Other considerations Any advice on what to avoid and what to certainly do/check/follow up on is appreciated. I will certainly miss stuff that might present a problem down the road. For instance things like cronjobs- do you limit their use by custom scripts or do you just monitor abuse? I am aware of things like 'accounting', 'quota' and 'ulimit' - any other handy utils I might check? Thanks, Matt
