#33733: How do home directories work? -------------------------------------------------+------------------------- Reporter: irl | Owner: tpa Type: task | Status: | needs_review Priority: Medium | Milestone: Component: Internal Services/Tor Sysadmin Team | Version: Severity: Normal | Resolution: Keywords: | Actual Points: Parent ID: #33715 | Points: Reviewer: | Sponsor: -------------------------------------------------+------------------------- Changes (by anarcat):
* status: new => needs_review Comment: Replying to [ticket:33733 irl]: > There seems to be little consistency here, which isn't what I expect from an orchestrated process, so I'm maybe missing something. You're right! It's not fully orchestrated yet. Some of those things were created by hands before Puppet, most are managed in LDAP (by hand as well) and some are managed by Puppet *and* LDAP. It's a bit all over the place. You're dealing with old code here. Sorry for the inconvenience! :) > Each service has a directory in /srv/{service}.torproject.org/ and then sometimes there is a home directory, which is sometimes linked in some way to /home/{service}. When there are multiple users for a service, they can share the same /srv directory but then have inconsistent naming of home directories. What do you mean "multiple users"? Could you give an example here specifically? > Is there some documentation I can read to make sense of this? Unfortunately: not much. I created "operational" docs that deal with "how to create a normal or role user", for example, in: https://help.torproject.org/tsa/howto/create-a-new-user/ Then some user-facing documentation and policy is available in: https://help.torproject.org/tsa/doc/accounts/ But I understand you might not have found those or that, if you did, they were not satisfactory. This is not really standardized in Puppet either, as I have just begun refactoring that code. The fact that it's also bound to LDAP complicates things as well because Puppet cannot (currently?) *write* to LDAP so manual operations need to be done on both systems for things to happen. My hope is that we can eventually replace LDAP for some of the role stuff, and move that into puppet, to have a more uniform experience. But it's a far-ranging project, as it involves touching `ud-ldap`, which is a huge challenge. The closest I've got to "standardizing" this is when we setup the new `check` service. I ended up writing this Puppet profile: {{{ # rewrite of the exit scanner # # not to be confused with the old roles::check that is now deprecated. class profile::check inherits apache2 { # disable the default site so the FQDN site alias works Apache2::Site['00-default'] { ensure => absent, } include apache2::ssl include apache2::proxy_http $users = ['tordnsel', 'check'] $users.each |String $user| { file { [ "/srv/${user}.torproject.org", "/srv/${user}.torproject.org/home", "/srv/${user}.torproject.org/htdocs", ]: ensure => 'directory', mode => '0775', owner => $user, group => $user, } # LDAP expects the home there file { "/home/${user}": ensure => link, target => "/srv/${user}.torproject.org", } loginctl_user { $user: linger => enabled, } file { "/etc/sudoers.d/${user}": mode => '0440', content => @("EOF"), # FILE MANAGED BY PUPPET, LOCAL CHANGES WILL BE LOST # allow ${user} user sudo access to ${user} group %${user} ALL=(${user}) ALL | EOF } } $vhost_name = 'check.torproject.org' apache2::site { $vhost_name: content => template('profile/check/vhost.erb'), } ssl::service { 'check.torproject.org': notify => Exec['service apache2 reload'], key => true, } ensure_packages('tor', {ensure => installed}) # NOTE: tor service is ran by the service admin (through systemd # --user), so we mask it here (in systemd --system) dsa_systemd::mask { [ 'tor.service', 'tor@default.service' ]: notify => Package['tor'], } # new exit scanner dependencies, see #33362 ensure_packages( # ... ) } }}} That ` $users.each |String $user| {` should really be a new resource that would standardize the way users are created from Puppet's perspective. You can also see the symlink hack to take into account the LDAP home directory there. > Context: I'm putting together our Ansible roles (#33715) that should replicate what TPA will give us when we move things to a TPA host after we're convinced it's ready for deployment and we know what the specs will be, but I'm having trouble generalising even from just the Onionoo and Exit Scanner setups. Which problem are you having specifically? Hopefully the above code sample should provide you with some guidance, but I understand it's not documentation and I apologize for the lack of standardization in that regard. > I'd like to be able to set some variables, like what usernames exist, what groups exist, and what paths will exist and should be used for stuff, and then let this role set that up. The service specific (e.g. Onionoo or Exit Scanner) roles will then run equally on our AWS dev instances and the production TPA instance. That shouldn't be a problem: we basically do the same in Puppet, even though the users and groups are actually created in LDAP. I hope that helps, let me know if you have any further questions! (PS: one thing that would be useful for me is to know where you look for this documentation, instinctively. Then I could go *there* and add a pointer to the existing documentation. When you're happy with the answers here, I would also go there and add the missing bits. :) -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33733#comment:2> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs