Intro
Our apache2 setup serves files from a wide variety of folders using webdav, and use authz_dbd to communicate with a mysql database (this part works without problems).
Summary:
Apache2, mod_authz_dbd, mod_authn_dbd, mysql, enabling webdav, multi user environment (iot nodes).
However... some of these folders are user specific.
folder1 admins
+--subfolder1.1 admins+some other folk+user1
+--subfolder1.2 admins+again other folk+user1
folder2
+--subfolder 2.1 same as 1.1 but with user2
+--subfolder 2.2 as1.2.. but..user2
We use dbd-groups with wildcards, similar to this:
location /var/www/html/*/subfolder1.1
require dbd-group read
And normally wrote all in the vhosts file
(require user.. )
The problem
This becomes too large, we need another fix.
We cannot use .htaccess files in combination with dbd groups (dbd groups are not allowed in .htacces). Our debian (jessy) does not allow the other mysql apache2 mods.
The combination of .htaccess files with dbd's mysql authorization does not work (dbd groups are not allowed in .htaccess).
Our debian server does not allow other mysql apache2 mods (like mod_auth_mysql).
How can I combine mysql authorization with the folder specific users?
Ok, i believe ive cracked it:
Technique
Apache natively support for named groupes and backreferances.
The capture group can be employed to identify the folder (and with this the user).
How does this work;
every subdir with of the hosted directory (/var/www/web)
Beginning with M and containing at least three decimals (M\d{3,}) <- the capture group.
This is stored in a variable ( sitedir)
eg.
/var/www/web/M1234/etc. sitedir=M1234
/var/www/web/M1234567/test/ANY other directory sitedir=M1234567
In my case I match the user with the directory name require user %{env:MATCH_SITEDIR}
Be very aware to use the queries outside the require directives (as shown below).
Using cascaded RequireAny/Requireall other requirements can be made
(requirements on dbd groups, ip ristrictions etc).
Drawbacks
The capture group might allow for multiple folders with an Mcode.
This can be mitigated by adapting the capture group.
The captured foldername cannot be used inside the query (it does not allow this)
This would have been even nicer, but it does not work...(the variable is considered plain text).
working example
<DirectoryMatch /var/www/web/(?<sitedir>(M\d{3,}))>
AuthDBDUserPWQuery "SELECT password FROM mysql_auth WHERE username = %s"
AuthzDBDQuery "SELECT groups FROM mysql_auth WHERE username = %s"
<RequireAny>
Require user %{env:MATCH_SITEDIR}
<RequireAll>
Require valid-user
Require ip 10.0.0.0/16
<RequireAny>
Require dbd-group internal
Require dbd-group write
</RequireAny>
</RequireAll>
</RequireAny>
</DirectoryMatch>
Related
We have a need to set some directives in the snappy config files for the various components (servers, locators, etc).
The snappy_ec2 scripts do a good job at creating all of the config's and keeping them in sync across the cluster, but I need to find a serviceable method to add directives to the auto generated scripts.
What is the preferred method using this script?
Example: Add the following to the 'servers' file:
-gemfirexd.disable-getall-local-index=true
Or perhaps I should add these strings to an environments file such as
snappy-env.sh
TIA
-doug
Have you tried adding the directives directly in the servers (or locators or leads) file and placing this file under (SNAPPY_DIR)/ec2/deploy/home/ec2-user/snappydata/? The script would read the conf files under this dir at the time of launching the cluster.
You'll need to specify it for each server you want to launch, with the name of server as shown below. See 'Specifying properties' section in README, if you have not already done so. e.g.
{{SERVER_0}} -heap-size=4096m -locators={{LOCATOR_0}}:9999,{{LOCATOR_1}}:9888 -J-Dgemfirexd.disable-getall-local-index=true
{{SERVER_1}} -heap-size=4096m -locators={{LOCATOR_0}}:9999,{{LOCATOR_1}}:9888 -J-Dgemfirexd.disable-getall-local-index=true
If you want it to be applied for all the servers, simply put it in snappy-env.sh as you mentioned (as SERVER_STARTUP_OPTIONS) and place the file under directory mentioned above.
We could have read the conf files directly from (SNAPPY_DIR)/conf/ instead of making users copy it to above location, but we may release the ec2 scripts as a separate package, in future, so that the users do not have to download the entire distribution.
I am trying to debug a weird issue with one user's roster in ejabberd.
He is having a roster group "_root" show up in his client (PSI).
The server is using mod_ldap for user authentication.
Things tried so far:
deleting the group from the client -> the group appears again after a while
unregistering the user with /ejabberdctl unregister user domain.com -> the group appears again after a while
Only one user is affected by this on the server, which makes me think it has to be something specific to this one user's settings (or client). But we have a bunch of people also using PSI with no problems.
Is there a way to look at the roster groups defined for a specific user in the database directly?
Thanks,
kaza
That "_root" value must come from the roster module data. You did not say which roster module you use, but I guess the server is configured to use mod_roster_ldap and possibly mod_shared_roster_ldap. Check the configuration of the module and explore the content of the LDAP directory to see if you see that value. I would think that value comes from there.
According to the Node-Webkit wiki the manifest for a program requires a name and this name must be globally unique because it determines the name of the directory that data files for the program are stored in.
I haven't been able to find anything else that this name is used for. Is it safe to just use a UUID as the name listed in the manifest? Or will that be exposed to the user somewhere potentially?
It's more typically related to the common program name that the user sees, but it doesn't have to be. For example on the Mac, the standard location for app specific data is ~/Library/Application Support/. When I look there I see things like GIMP, Skype, XDK &c. If your app happened to have the same name as another app, it would cause problems as they'd both writing to the same location, i.e. if I gave my app the name GIMP, both apps would try to write files to that dir.
Typically a user doesn't have to access this directly, so there's probably no harm in using a UUID here, though I would probably append it to a name related to my app name, just for clarity/simplicity, i.e. instead of making the name foo I'd make it foo-<UUID>.
But I'm no expert . . . .
Question:
How can I get a list of all checked out files per user in Sourcegear Vault?
Use of this functionality:
From time to time we have developers leaving files checked out and although this results in drastic punishment (they owe a coffee to the person who needed the checked out file) we are still left with files checked out and work held up.
We would like to display a list of all current number of files checked out by each developer. This way they can check if they have anything checked out before they go home or out the office.
In the Vault Client app, use the Search tab at the bottom of the window.
Select Search By: "Checked Out By" to see a list of all files checked out by a specific user, or by any user.
You can choose to search a specific sub-folder, or from the root, recursively or not.
To automate this, use the Vault Command-Line client (vault.exe)
vault -host myhost.mydomain -user something -password something -repository myrepo listcheckouts
Will give you a list, in XML, of all checked-out files and their users. You can transform the results, or use the command-line client's source code (provided as an example with the Vault .NET API) as a starting point to write your own version.
The various clients and APIs can be grabbed from http://sourcegear.com/vault/downloads.html - didn't want to link to a specific version that would be outdated after the next release.
mercurial-server manages user database under keys folder. Users and groups are represented by files and folders.
AclExtension relies on linux user group through ssh.
they don't seem to match. or did I miss something?
I have managed to make mercurial-server work. but just don't see how to integrate AclExtension with it so I may have finer grained access control.
Unfortunately, the AclExtension does key its access off of usernames. If you are creating separate UNIX user accounts for each using with hg-ssh you've got everything you need, but if all of your ssh users are using the same Unix user account then the AclExtension isn't going to work for you.
Unless...
I did just look into the acl.py file and it looks like it uses the getpass.py module's getuser which checks the environment for the user name using this code:
for name in ('LOGNAME', 'USER', 'LNAME', 'USERNAME'):
user = os.environ.get(name)
if user:
return user
so it might be possible to fake that out by setting an environment variable in the hg-ssh user's authorized_keys file like this:
command="hg-ssh path/to/repo" environment="LOGNAME=fakeusername" ssh-dss ...
where then you could put fakeusername in ACL rules, and could have a different fakeusername for each key, all running under the same UNIX account.
BTW: Everyone seems to just use hg-ssh alone, I never see the (non-official) mercurial-server app used anymore.
The environment trick doesn't seem to work on my Solaris box; my solution was to pass in the fakeusername as a parameter to hg-ssh and have that set os.environ['LOGNAME'] so that getpass sees it.
command="hg-ssh fakeusername" ssh-dss ...