72 | | |
| 74 | |
| 75 | |
| 76 | - Secure your database connections : |
| 77 | |
| 78 | Depending on the database backend used, either PostgreSQL or LDAP, |
| 79 | you may have to take additionnal measures to render your database |
| 80 | more secure. Please refer to your database system's documentation |
| 81 | to learn how to do so. This is out of the scope of the present |
| 82 | document which will only give basic informations. |
| 83 | |
| 84 | Keep in mind that if you use a centralized database, the first thing |
| 85 | you may want to do is to restrict which hosts can access to it, i.e. |
| 86 | only the print servers. |
| 87 | |
| 88 | PostgreSQL : |
| 89 | |
| 90 | For the PostgreSQL backend, PyKota already defines a user with |
| 91 | read/write access and another user with read-only access to the |
| 92 | Print Quota Database. PyKota doesn't set any passwords for these |
| 93 | users though, but doing so is recommended, and here's how to do : |
| 94 | |
| 95 | From the root shell do : |
| 96 | |
| 97 | $ su - postgres |
| 98 | $ psql template1 |
| 99 | template1=# ALTER USER pykotauser WITH PASSWORD 'a.difficult.password'; |
| 100 | template1=# ALTER USER pykotaadmin WITH PASSWORD 'another.password'; |
| 101 | template1=# \q |
| 102 | $ exit |
| 103 | |
| 104 | Now modify PostgreSQL's pg_hba.conf to restrict access to the PyKota |
| 105 | database to PostgreSQL users 'pykotauser' and 'pykotaadmin' only, |
| 106 | and only if they connect from localhost and provide the correct |
| 107 | password. Here's an excerpt from our own pg_hba.conf : |
| 108 | |
| 109 | --- CUT --- |
| 110 | local all postgres ident sameuser |
| 111 | local all all reject |
| 112 | host pykota pykotauser 127.0.0.1 255.255.255.255 crypt |
| 113 | host pykota pykotaadmin 127.0.0.1 255.255.255.255 crypt |
| 114 | host pykota all 127.0.0.1 255.255.255.255 reject |
| 115 | --- CUT --- |
| 116 | |
| 117 | Finally restart PostgreSQL so that the changes will be applied : |
| 118 | |
| 119 | $ /etc/init.d/postgresql restart |
| 120 | |
| 121 | Of course, depending on your needs, you may want to secure |
| 122 | your database connexions in a completely different way or |
| 123 | add other security layers on top of this. To do so please |
| 124 | refer to PostgreSQL's documentation because this is out of |
| 125 | the scope of the present document. |
| 126 | |
| 127 | LDAP : |
| 128 | |
| 129 | For the LDAP backend, you have to ensure that no regular user can |
| 130 | write to any PyKota specific attribute or objectClass. Otherwise |
| 131 | they could modify their quota at will. Here too you will have to |
| 132 | create two LDAP users which will be used for readonly and read+write |
| 133 | access to PyKota's datas. PyKota currently doesn't do this, so |
| 134 | you have to create an LDIF file this way (please adapt the |
| 135 | DNs to your own environment) : |
| 136 | |
| 137 | --- CUT --- |
| 138 | dn: cn=pykotauser,dc=example,dc=com |
| 139 | cn: pykotauser |
| 140 | objectClass: simpleSecurityObject |
| 141 | objectClass: organizationalRole |
| 142 | description: PyKota ReadOnly User |
| 143 | userPassword: {CRYPT}jfdsk653dsZFL |
| 144 | |
| 145 | dn: cn=pykotaadmin,dc=example,dc=com |
| 146 | cn: pykotaadmin |
| 147 | objectClass: simpleSecurityObject |
| 148 | objectClass: organizationalRole |
| 149 | description: PyKota Read+Write User |
| 150 | userPassword: {CRYPT}kqsIu43Exoi5s |
| 151 | --- CUT --- |
| 152 | |
| 153 | Then add these two users to your existing LDAP tree : |
| 154 | |
| 155 | $ ldapadd -W -x -D "cn=admin,dc=example,dc=com" -f users.ldif |
| 156 | |
| 157 | Now modify your LDAP server's configuration to respectively allow |
| 158 | read+write and readonly access to the datas : |
| 159 | |
| 160 | --- CUT --- |
| 161 | by dn="cn=pykotaadmin,dc=example,dc=com" write |
| 162 | by dn="cn=pykotauser,dc=example,dc=com" read |
| 163 | --- CUT --- |
| 164 | |
| 165 | Finally restart your LDAP server so that the changes will be applied : |
| 166 | |
| 167 | $ /etc/init.d/slapd restart |
| 168 | |
| 169 | Of course, depending on your needs, you may want to secure |
| 170 | your database connexions in a completely different way or |
| 171 | add other security layers on top of this. To do so please |
| 172 | refer to your LDAP server's documentation because this is out |
| 173 | of the scope of the present document. |
| 174 | |
| 175 | |
100 | | - Secure your database connection : |
101 | | |
102 | | Depending on the database backend used, either PostgreSQL or |
103 | | OpenLDAP, you may have to take additionnal measures to render |
104 | | your database more secure. Please refer to your database system's |
105 | | documentation on configuration to learn how to do so. This is out |
106 | | of the scope of the present document which will only give basic |
107 | | informations. |
108 | | |
109 | | Keep in mind that if you use a centralized database, you may have |
110 | | to restrict which hosts can access to it (i.e. the Print Servers). |
111 | | |
112 | | For the PostgreSQL backend, PyKota already defines a user with |
113 | | read/write access and another user with read-only access to |
114 | | the Print Quota Database. PyKota doesn't set any passwords |
115 | | for these users though, but doing it is recommended, and |
116 | | explained elsewhere in PyKota's documentation. |
117 | | |
118 | | For the LDAP backend, you have to ensure that no regular |
119 | | user can write to any PyKota specific attribute or objectClass. |
120 | | Otherwise they could modify their quota at will. |
121 | | |
122 | | You also have to define two binding DNs in your LDAP tree, |
123 | | one of them should be able to have a read only access to |
124 | | everything. The other one should be able to write, for |
125 | | example your LDAP admin user is fine for this. |
126 | | Now put the readonly user in /etc/pykota/pykota.conf |
127 | | and the read-write one in /etc/pykota/pykotadmin.conf |
128 | | |