Attila Csipak's questions

I know that this is a valid systemd unit configuration file syntax:

[Unit]
RequiresMountsFor=/mnt/foo /mnt/bar
...

Recently, I've seen a multiline variant of the above:

[Unit]
RequiresMountsFor=/mnt/foo
RequiresMountsFor=/mnt/bar
...

Are these two syntaxes semantically equivalent?

I checked the RequiresMountsFor option in the systemd.unit manpage, which explicitly states: "Takes a space-separated list of absolute paths." Also there's a hint on similarities with Requires and After options. The Requires option's documentation explicitly states that the single-line and multi-line syntaxes are equivalent (for the Requires option): "This option may be specified more than once or multiple space-separated units may be specified in one option in which case requirement dependencies for all listed names will be created." So I'd guess that the same applies to RequiresMountsFor.

We encountered this problem with different versions of OS & Subversion on the server side, the following details being the same:

• We used https protocol to access the SVN repositories.
• We used Apache HTTPD + mod_dav_svn + mod_authz_svn. We also used either mod_auth_kerb or mod_auth_gssapi.
• The users authenticated with Windows Integrated Authentication. Members of a certain group were allowed to access the SVN repos.
• The clients were Windows workstations, with fairly recent SVN versions (1.13-1.14).

Some clients worked OK, others got a HTTP 400 Bad Request error on accessing the SVN repository. On the server side the error manifested in a "NO AUTH DATA Client did not send any authentication headers" message in the SSL error log.

Some users consistently succeeded, others consistently failed to access the SVN repos.

We plan to change the default server options of an SQL2k5 server instance by enabling data access.

The reason is that we want to run SELECT * FROM OPENQUERY(LOCALSERVER, '...') - like statements on the server.

What are the possible disadvantages of enabling server option "data access" (alias sys.servers.is_data_access_enabled) for the local server (sys.servers.server_id = 0)?

(There must be a reason for MS setting this option to disabled by default...)

EDIT: it turns out that I'm not the first person to ask this question:

http://sqlblogcasts.com/blogs/piotr_rodak/archive/2009/11/22/data-access-setting-on-local-server.aspx

The DATA ACCESS server option is not very well documented in my opinion - the Books On Line say it is a property of linked servers. It doesn't mention at all that you actually can have it enabled on your local server to enable OPENQUERY calls. I noticed that when you disable DATA ACCESS on a linked server, you can't query any table located on it (I tested it on my loopback server) neither using OPENQUERY nor four-part naming convention. You can still call procedures (with four-part naming) that return rowsets. Well, the interesting question is why it is disabled by default on local server - I suppose to discourage users from using OPENQUERY against it.

It also seems that the author of the post is a Stack Overflow user :-)

UPDATE: Another tech blogger ran into the same issue in 2014. Also a Stackoverflow user.