Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID
On 03/07/2013 01:25 PM, Tornóci László wrote:
On 03/07/2013 11:49 AM, Dirk Kastens wrote:
Hi,
seems that this was the wrong place.
Why? Did you truncate the oc_ldap_user_mapping table?
Could have been that something was left in the Cache, too.
Owncloud still used the UUID for
the user directory. Meanwhile I have changed line 431 in
user_ldap/lib/connection.php from
if(!in_array($this-config['ldapUuidAttribute'], array('auto',
'entryuuid', 'nsuniqueid', 'objectguid'))
to
if(!in_array($this-config['ldapUuidAttribute'], array('uid'))
and line 895 in user_ldap/lib/connection.php from
$testAttributes = array('entryuuid', 'nsuniqueid', 'objectguid');
to
$testAttributes = array('uid');
Now OC only uses the uid for the users and the directories.
Not only, but also to recognize users. If you want that, OK.
[Now some copy mess from the other mails, sorry]
Your problem was that from OC5 the LDAP entryUUID was used for #2,
right? For this you need to change the source for sure (perhaps at more
than one place).
Exactly.
Exactly this should have been achieved with my suggestion.
With the changes that I made, OC behaves like OC4, where users and directories
are named after the users UIDs.
This was also the case with OC4.5 (depending on your config). However,
those names always have been sanitized. Other characters but a-zA-z0-9
and four other chars have been replaced or thrown away, because of
username limitiations in ownCloud.
Since OC 4.5 LDAP users are identified/recognized with their UUID
attribute. This was necessary as anything else did not prove to be
reliable enough and caused problems.
Now we switched to generally use the UUID also for the internal name,
because displayed will only be the display name.
It would be great if this could be made configurable through the admin
interface. You just need to add a field like unique attribute. Then
it's up to the admin if he chooses the uid, the entryuuid, the uidnumber
or whatever.
These are two things
1) customizable attribute for display name (will be sanitizied to meet
ownCloud limitations). I think we can get it into 5.0.1, although I do
not see it as a bug, but I understand that some are not so happy with
this behaviour.
2) customizable UUID attribute to identify and recognize users.
Honestly, I really love to keep it as it is, to avoid configuration
disasters. But I agree it may be handy when there really is another
unique attribute and it would solve migration headaches. Here we would
also need to implement a mechanism, that updates all mapped users and
groups. Since we have this policy since 4.5 and there were no complaints
so far and it is another feature, this can be done only for OC 6.
Cheers
Arthur
Hi,
If I understand your problem correctly, you don't need to change the
source at so many places. There are many things here that can be easily
mixed up:
1. uid to login
2. internal ID for OC
3. user home dir path
4. display name
Your problem was that from OC5 the LDAP entryUUID was used for #2,
right? For this you need to change the source for sure (perhaps at more
than one place).
For #1 you can use any ldap attribute you like in User login filter of
the basic ldap setup
For #3 you can use Group display name field in the advanced setup
For #4 you can use User home folder naming rule in the advanced setup
Yours: Laszlo
You can patch it yourself by replacing
the line
https://github.com/owncloud/core/blob/master/apps/user_ldap/lib/access.php#L317
with
$intname = $isUser ? $this-sanitizeUsername($this-readAttribute($dn,
'uid')) : $this-sanitizeUsername($ldapname);
Great! I didn't know that this is that simple. I'll give it a try.
Dirk
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID
Hi,
seems that this was the wrong place. Owncloud still used the UUID for
the user directory. Meanwhile I have changed line 431 in
user_ldap/lib/connection.php from
if(!in_array($this-config['ldapUuidAttribute'], array('auto',
'entryuuid', 'nsuniqueid', 'objectguid'))
to
if(!in_array($this-config['ldapUuidAttribute'], array('uid'))
and line 895 in user_ldap/lib/connection.php from
$testAttributes = array('entryuuid', 'nsuniqueid', 'objectguid');
to
$testAttributes = array('uid');
Now OC only uses the uid for the users and the directories.
You can patch it yourself by replacing
the line
https://github.com/owncloud/core/blob/master/apps/user_ldap/lib/access.php#L317
with
$intname = $isUser ? $this-sanitizeUsername($this-readAttribute($dn,
'uid')) : $this-sanitizeUsername($ldapname);
Great! I didn't know that this is that simple. I'll give it a try.
Dirk
smime.p7s
Description: S/MIME Kryptografische Unterschrift
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID
On 03/07/2013 11:49 AM, Dirk Kastens wrote:
Hi,
seems that this was the wrong place. Owncloud still used the UUID for
the user directory. Meanwhile I have changed line 431 in
user_ldap/lib/connection.php from
if(!in_array($this-config['ldapUuidAttribute'], array('auto',
'entryuuid', 'nsuniqueid', 'objectguid'))
to
if(!in_array($this-config['ldapUuidAttribute'], array('uid'))
and line 895 in user_ldap/lib/connection.php from
$testAttributes = array('entryuuid', 'nsuniqueid', 'objectguid');
to
$testAttributes = array('uid');
Now OC only uses the uid for the users and the directories.
Hi,
If I understand your problem correctly, you don't need to change the
source at so many places. There are many things here that can be easily
mixed up:
1. uid to login
2. internal ID for OC
3. user home dir path
4. display name
Your problem was that from OC5 the LDAP entryUUID was used for #2,
right? For this you need to change the source for sure (perhaps at more
than one place).
For #1 you can use any ldap attribute you like in User login filter of
the basic ldap setup
For #3 you can use Group display name field in the advanced setup
For #4 you can use User home folder naming rule in the advanced setup
Yours: Laszlo
You can patch it yourself by replacing
the line
https://github.com/owncloud/core/blob/master/apps/user_ldap/lib/access.php#L317
with
$intname = $isUser ? $this-sanitizeUsername($this-readAttribute($dn,
'uid')) : $this-sanitizeUsername($ldapname);
Great! I didn't know that this is that simple. I'll give it a try.
Dirk
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID
Hi, If I understand your problem correctly, you don't need to change the source at so many places. There are many things here that can be easily mixed up: 1. uid to login 2. internal ID for OC 3. user home dir path 4. display name Your problem was that from OC5 the LDAP entryUUID was used for #2, right? For this you need to change the source for sure (perhaps at more than one place). Exactly. With the changes that I made, OC behaves like OC4, where users and directories are named after the users UIDs. It would be great if this could be made configurable through the admin interface. You just need to add a field like unique attribute. Then it's up to the admin if he chooses the uid, the entryuuid, the uidnumber or whatever. Dirk smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID
On 02/27/2013 08:56 AM, Dirk Kastens wrote: Hi Arthur, The problem is, that all other attributes may change (and may be not unique) in the directory server. At least, in our user management the uid is unique and never changes. It is the same across all databases, be it LDAP, AD, or SQL. So I did prefer the old owncloud configuration. The UUID is required to identify a user anyway. And we need a solution that works everywhere. For ownCloud 5 it too late to get enhancements into it, [showstopper] bugs only, because we are about to release. You can patch it yourself by replacing the line https://github.com/owncloud/core/blob/master/apps/user_ldap/lib/access.php#L317 with $intname = $isUser ? $this-sanitizeUsername($this-readAttribute($dn, 'uid')) : $this-sanitizeUsername($ldapname); and file a feature request on https://github.com/owncloud/core/issues so we can get it into OC 6 (or maybe even in a maintenance release of the 5 series) Hope this helps, Cheers Arthur Dirk ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID
Hi Arthur, You can patch it yourself by replacing the line https://github.com/owncloud/core/blob/master/apps/user_ldap/lib/access.php#L317 with $intname = $isUser ? $this-sanitizeUsername($this-readAttribute($dn, 'uid')) : $this-sanitizeUsername($ldapname); Great! I didn't know that this is that simple. I'll give it a try. Thanks, Dirk smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID
Hi Arthur, The problem is, that all other attributes may change (and may be not unique) in the directory server. At least, in our user management the uid is unique and never changes. It is the same across all databases, be it LDAP, AD, or SQL. So I did prefer the old owncloud configuration. Dirk smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID
Hi, the LDAP backend is now using the entyUUID attribute to store users. (tech detail: the uuid attribute will be autodetected, e.g. AD uses a different one) This could be a problem if you change your ldap server, maybe from openldap to AD or to Novell. Although the user data are the same (uid, mail, etc.), no user will have access to his owncloud data, because the UUID, that is internal to the LDAP server, has changed. The same happens, if you want to restore a deleted user from an LDIF file. Unless you are using slapadd (this only works if you stop the openldap server), an ldapadd will recreate the user with a new UUID, so that he also loses all his data. Dirk smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID
On Tuesday, February 19, 2013 20:35 CET, Arthur Schiwon bli...@owncloud.com wrote: Depends on where you tackle it. If you ensure uniqueness on LDAP side, you are not getting a problem on ownCloud as long as you don't use other user backends (which may have other problems). In some cases it is necessary that display names can be modified, for instance when family names change, titles needs to be added, or if job positions, departments or likes are included in the display name. When you take a step back and look at a bigger picture, some backends do not provide user lists (IMAP, WebDAV) so you cannot see which names are already in use. Shifting it all to ownCloud core means drawbacks as stated above. The LDAP backend really takes care that _internal_ names stay unique. As it was up to 4.5 they also were used as display names which did not make all people happy, because of the limitations. Note that not every available user backend takes care of unique names (ownCloud's internal does, IMAP or WebDAV don't afaik). Okay, I am beginning to understand your reasoning. Let's say we try to base this identifier on the email address (e.g. John Doe (j@gmail.com), then we replace the requirement of unique display names by the requirement that every user backend must be able to provide an email address for its users. I believe this might not always be possible. A couple of months ago I wrote a user backend that retrieved its user information from a database which enforced neither the presence, nor the correctness, nor the uniqueness of the email addresses. For other authentication mechanisms there might be technical reasons why the email address isn't available. In such cases we might fall back to the login name as unique attribute. This doesn't solve the (admittedly remote) problem of trying to hook up two user databases which contain identical [display name, email] entry tuples, but I think I can live with that. Andreas ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID
On 02/19/2013 09:19 AM, Dirk Kastens wrote: Hi, the LDAP backend is now using the entyUUID attribute to store users. (tech detail: the uuid attribute will be autodetected, e.g. AD uses a different one) I don't know if this is such a good idea. Now, if you share a file, the entryUUID is displayed instead of the uid (see attached picture). I believe it has already been fixed in master with https://github.com/owncloud/core/commit/bef48bad8b83b2826d6eb3397e3f22e8d20ba5f3 And in the user list of the admin interface you see the entryUUIDs as the loginnames. The label is ambiguous. The ownCloud user management uses the internal username as login name. For LDAP users the internal ownCloud name will be shown. Also, LDAP users do not have a unique or permanent login name, depending on the configuration (e.g. login via username and email adress). Worth a bug report. I configure CN as the display name attribute. But display names are not unique. So it's not possible to find the right user. It's true that display names are not unique. But would it help to number them? You would end up with John Doe John Doe (2) John Doe (3) → i see the problem, but forcing unqiueness for display names does not look like a solution for me A way would be to add an (optional) second attribute that may be displayed in brackets, e.g. displayName + mail John Doe (j...@doe.net) John Doe (john@example.biz) I am open for ideas and suggestions on this. Helpful to have this as a bug report, too. Thanks for pointing at it! Cheers Arthur Dirk ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID
On Tuesday, February 19, 2013 12:36 CET, Arthur Schiwon bli...@owncloud.com wrote: I configure CN as the display name attribute. But display names are not unique. So it's not possible to find the right user. It's true that display names are not unique. But would it help to number them? You would end up with John Doe John Doe (2) John Doe (3) → i see the problem, but forcing unqiueness for display names does not look like a solution for me A way would be to add an (optional) second attribute that may be displayed in brackets, e.g. displayName + mail John Doe (j...@doe.net) John Doe (john@example.biz) I am open for ideas and suggestions on this. I can understand the desire to keeps things simple and general by not enforcing uniqueness of display names, but your own example illustrates the need for human-readable, unique identifiers. If all users data is coming from the same source, e.g. a single LDAP server, then it is possible to guarantee uniqueness by selecting an appropriate attribute. In such a scenario, the email address is probably the best choice for the display name. The problems start once you combine different user bases with duplicate attributes values, or once you permit users to change their display names, because either one can lead to name clashes. Editable display names are especially problematic from a security standpoint, since some users may intentionally try to change their display name, in the hope of being mistakenly granted access to private data. I used to think that just checking for existing display names would be enough to prevent problems, but users may try to grab the default display name (e.g. the email address) of a potential user who does not have an OC account, yet, creating trouble down the road. So, for highest security, display names should be globally unique and unchangeable. If that is not the case, then we have to rely on the suggested displayName + mail, which effectively creates a third user identifier, let's call this the unique display name (UDN). Due to the mentioned security issues, the UDN should be used pretty much everywhere instead of the simple display name, which makes the non-unique display name superfluous. Considering the display name just as the editable part of the UDN, without ever using it on its own, would require extensive code changes but seems like a reasonable compromise. BTW thank you Arthur for answering my other mail. Cheers Andreas ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID
On 19.02.2013, at 08:55, Andreas Ergenzinger andreas.ergenzin...@uni-konstanz.de wrote: On Tuesday, February 19, 2013 12:36 CET, Arthur Schiwon bli...@owncloud.com wrote: I configure CN as the display name attribute. But display names are not unique. So it's not possible to find the right user. It's true that display names are not unique. But would it help to number them? You would end up with John Doe John Doe (2) John Doe (3) → i see the problem, but forcing unqiueness for display names does not look like a solution for me A way would be to add an (optional) second attribute that may be displayed in brackets, e.g. displayName + mail John Doe (j...@doe.net) John Doe (john@example.biz) I am open for ideas and suggestions on this. I can understand the desire to keeps things simple and general by not enforcing uniqueness of display names, but your own example illustrates the need for human-readable, unique identifiers. If all users data is coming from the same source, e.g. a single LDAP server, then it is possible to guarantee uniqueness by selecting an appropriate attribute. In such a scenario, the email address is probably the best choice for the display name. The problems start once you combine different user bases with duplicate attributes values, or once you permit users to change their display names, because either one can lead to name clashes. Editable display names are especially problematic from a security standpoint, since some users may intentionally try to change their display name, in the hope of being mistakenly granted access to private data. I used to think that just checking for existing display names would be enough to prevent problems, but users may try to grab the default display name (e.g. the email address) of a potential user who does not have an OC account, yet, creating trouble down the road. So, for highest security, display names should be globally unique and unchangeable. If that is not the case, then we have to rely on the suggested displayName + mail, which effectively creates a third user identifier, let's call this the unique display name (UDN). Due to the mentioned security issues, the UDN should be used pretty much everywhere instead of the simple display name, which makes the non-unique display name superfluous. Considering the display name just as the editable part of the UDN, without ever using it on its own, would require extensive code changes but seems like a reasonable compromise. BTW thank you Arthur for answering my other mail. Cheers Andreas An admin can disable the option for users to change the display name. I depends on the user scenario if this is useful and save or not. In case you use a directory like LDAP then we rely on a properly configured useraccounts in it including unique and understandable display names. The scenario of different LDAP servers is interesting but I'm not sure if it is in the scope of ownCloud to resolve naming collisions in his case. This can and should be solved in the LDAP configuration. Frank ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID
On 02/19/2013 04:38 PM, Andreas Ergenzinger wrote: On Tuesday, February 19, 2013 15:09 CET, Frank Karlitschek fr...@owncloud.com wrote: An admin can disable the option for users to change the display name. I depends on the user scenario if this is useful and save or Very good. I agree that editable display names can be a source of all kinds of problems. not. In case you use a directory like LDAP then we rely on a properly configured useraccounts in it including unique and understandable display names. The scenario of different LDAP servers is interesting but I'm not sure if it is in the scope of ownCloud to resolve naming collisions in his case. This can and should be solved in the LDAP configuration. Frank I completely agree with you there. In such an environment naming collisions can only be prevented by a prudent configuration. However, I still don't see the point of non-unique display names. Due to the potential for confusion, we need a different way to distinguish users on the screen. Unfortunately the only standardized option available at the moment is the login name which may be pop55307, d41d8cd98f00b204e9800998ecf8427e, or something equally opaque. I think we need a better alternative and requiring display names to be unique is the most simple solution I can think of. If I understand correctly, you can set any attribute in LDAP as display name. So you can set it up any way you like. E.g. I plan to create a new LDAP attribute like this: LDAP display name + LDAP department name. You only have a problem, if you don't have write access to LDAP. Yours: Laszlo ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID
On 02/19/2013 02:55 PM, Andreas Ergenzinger wrote: On Tuesday, February 19, 2013 12:36 CET, Arthur Schiwon bli...@owncloud.com wrote: I configure CN as the display name attribute. But display names are not unique. So it's not possible to find the right user. It's true that display names are not unique. But would it help to number them? You would end up with John Doe John Doe (2) John Doe (3) → i see the problem, but forcing unqiueness for display names does not look like a solution for me A way would be to add an (optional) second attribute that may be displayed in brackets, e.g. displayName + mail John Doe (j...@doe.net) John Doe (john@example.biz) I am open for ideas and suggestions on this. I can understand the desire to keeps things simple and general by not enforcing uniqueness of display names, but your own example illustrates the need for human-readable, unique identifiers. If all users data is coming from the same source, e.g. a single LDAP server, then it is possible to guarantee uniqueness by selecting an appropriate attribute. In such a scenario, the email address is probably the best choice for the display name. The problems start once you combine different user bases with duplicate attributes values, or once you permit users to change their display names, because either one can lead to name clashes. Editable display names are especially problematic from a security standpoint, since some users may intentionally try to change their display name, in the hope of being mistakenly granted access to private data. I used to think that just checking for existing display names would be enough to prevent problems, but users may try to grab the default display name (e.g. the email address) of a potential user who does not have an OC account, yet, creating trouble down the road. So, for highest security, display names should be globally unique and unchangeable. Depends on where you tackle it. If you ensure uniqueness on LDAP side, you are not getting a problem on ownCloud as long as you don't use other user backends (which may have other problems). In some cases it is necessary that display names can be modified, for instance when family names change, titles needs to be added, or if job positions, departments or likes are included in the display name. When you take a step back and look at a bigger picture, some backends do not provide user lists (IMAP, WebDAV) so you cannot see which names are already in use. Shifting it all to ownCloud core means drawbacks as stated above. The LDAP backend really takes care that _internal_ names stay unique. As it was up to 4.5 they also were used as display names which did not make all people happy, because of the limitations. Note that not every available user backend takes care of unique names (ownCloud's internal does, IMAP or WebDAV don't afaik). Also note that display names of LDAP users cannot be changed from within ownCloud as we do not write to LDAP. If that is not the case, then we have to rely on the suggested displayName + mail, which effectively creates a third user identifier, let's call this the unique display name (UDN). Due to the mentioned security issues, the UDN should be used pretty much everywhere instead of the simple display name, which makes the non-unique display name superfluous. Considering the display name just as the editable part of the UDN, without ever using it on its own, would require extensive code changes but seems like a reasonable compromise. The LDAP configuration gives you pretty much free hand of what you define as display name. Take an exisiting attribute of your choice or extend you directory with one. It gives you a lot of power and flexibility. BTW thank you Arthur for answering my other mail. Welcome Cheers Arthur Cheers Andreas ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] ownCloud alpha 1 Installation Issue.
On Wednesday 13 February 2013 16:43 Patrick Heller wrote: Get an Error that my Web Server is not properly set it up. Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken. Please double check the installation guides http://doc.owncloud.org/server/5.0/admin_manual/installation.html . If I look in the guides I can't figure out where the problem is. Could anybody help? It doesn't seem you got any other answers? My best bet it this part: You don’t need any WebDAV support of your webserver (i.e. apache’s mod_webdav) to access your ownCloud data via WebDAV, ownCloud has a WebDAV server built in. In fact, you should make sure that any built-in WebDAV module of your webserver is disabled (at least for the ownCloud directory), as it can interfere with ownCloud’s built-in WebDAV support. -- Med venlig hilsen / Best Regards Thomas Tanghus ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] ownCloud alpha 1
On Wednesday 13 February 2013 11:37 Frank Karlitschek wrote: I'm very happy to announce the alpha 1 of ownCloud 5 Shouldn't we also announce pre-releases on http://owncloud.org/news/ ? The more testers, the merrier ;) -- Med venlig hilsen / Best Regards Thomas Tanghus ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] ownCloud alpha 1
Agreed. But owncloud.org/news/ is just a blog aggregator. So all that is needed is someone writing a blog post. Everybody can help with that ;-) Frank On 17.02.2013, at 12:58, Thomas Tanghus tho...@tanghus.net wrote: On Wednesday 13 February 2013 11:37 Frank Karlitschek wrote: I'm very happy to announce the alpha 1 of ownCloud 5 Shouldn't we also announce pre-releases on http://owncloud.org/news/ ? The more testers, the merrier ;) -- Med venlig hilsen / Best Regards Thomas Tanghus ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
[Owncloud] ownCloud alpha 1 Installation Issue.
Hi All, I tried to install the own cloud Alpha Version on my QNAP. Get an Error that my Web Server is not properly set it up. Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken. Please double check the installation guides http://doc.owncloud.org/server/5.0/admin_manual/installation.html . If I look in the guides I can't figure out where the problem is. Could anybody help? INFO: Owncloud 4.5.6 works fine on the same server. Best Regards Patrick Heller ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] ownCloud alpha 1
Am 13.02.2013 20:18, schrieb Arthur Schiwon: On 02/13/2013 03:58 PM, Holger Angenent wrote: - LDAP does still work:) (I only had to insert objectClass=group in the group filter. OC4.5 did not really need this) Oh, what happened with an empty group filter? Could you file a bug report, please? After the upgrade of my OC4.5.6 installation, the LDAP users did not appear and I couldn't login with them. When I delete the objectClass=group string now, nothing changes. The users are still valid. So maybe this wasn't a bug, but the system just needed a bit time? If I find something reproducible, I will file a bug report. Cheers Arthur Cheers, Holger smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] ownCloud alpha 1
On 02/14/2013 01:01 PM, Holger Angenent wrote: Am 13.02.2013 20:18, schrieb Arthur Schiwon: On 02/13/2013 03:58 PM, Holger Angenent wrote: - LDAP does still work:) (I only had to insert objectClass=group in the group filter. OC4.5 did not really need this) Oh, what happened with an empty group filter? Could you file a bug report, please? After the upgrade of my OC4.5.6 installation, the LDAP users did not appear and I couldn't login with them. When I delete the objectClass=group string now, nothing changes. The users are still valid. So maybe this wasn't a bug, but the system just needed a bit time? If I find something reproducible, I will file a bug report. Might be cache related. Saving settings clears the cache (as well as waiting the amount of seconds given in Cache TTL). It could be worth to automatically clear the cache on upgrade. Cheers Arthur Cheers Arthur Cheers, Holger ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
[Owncloud] ownCloud alpha 1
Hi everybody, I'm very happy to announce the alpha 1 of ownCloud 5 You can download it here: http://owncloud.org/releases/owncloud-5.0.0-alpha1.tar.bz2 This is alpha quality and it is not recommended to use this in a production environment. But if you want to help with testing and QA please download it and give feedback on the bugtracker: https://github.com/owncloud/core/issues Let's give it a hard test. The new encryption system is not yet part of this release but it will be included in the beta. An improved UI for the external filesystem mounting will also come with the next beta. Thanks to everybody who contributed and especially the people who worked super hard on fixing bugs in the last few weeks and during the developer sprint last weekend. You guys rock!!! Frank ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] ownCloud alpha 1
Hi, thank you for this new (test-)version of ownCloud. I made some first observations: - the new GUI looks pretty cool - LDAP does still work :) (I only had to insert objectClass=group in the group filter. OC4.5 did not really need this) - I synced my /lib dir (as an example for a folder with many files) via the 1.2.0 Linux client which took approximetely 35 minutes. Under same conditions with OC 4.5.5 and the 1.1.4 client, it took 40 minutes. I have monitored this with Ganglia. While uploading, the amount of used memory (I am not talking of the caches and buffers) went up for approx 800 MB. Fortunately, another 15 minutes later, it was freed again. Cheers, Holger Am 13.02.2013 11:37, schrieb Frank Karlitschek: Hi everybody, I'm very happy to announce the alpha 1 of ownCloud 5 You can download it here: http://owncloud.org/releases/owncloud-5.0.0-alpha1.tar.bz2 This is alpha quality and it is not recommended to use this in a production environment. But if you want to help with testing and QA please download it and give feedback on the bugtracker: https://github.com/owncloud/core/issues Let's give it a hard test. The new encryption system is not yet part of this release but it will be included in the beta. An improved UI for the external filesystem mounting will also come with the next beta. Thanks to everybody who contributed and especially the people who worked super hard on fixing bugs in the last few weeks and during the developer sprint last weekend. You guys rock!!! Frank ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] ownCloud alpha 1
Hi, - LDAP does still work :) (I only had to insert objectClass=group in the group filter. OC4.5 did not really need this) Did you make an upgrade installation? I installed OC5 from scratch. LDAP authentication seems to work but there's a problem with accessing the user directories. I opened an issue on github: https://github.com/owncloud/core/issues/1664 Dirk smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] ownCloud alpha 1
I just upgraded my Windows 2008 R2 test server and after the upgrade I am not able to see the Group Admin tab for all users. and I also have the following error: Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken. I upgraded from 4.5.6 . On Wed, Feb 13, 2013 at 10:15 AM, Holger Angenent h_zim...@uni-muenster.dewrote: Am 13.02.2013 16:09, schrieb Dirk Kastens: Hi, Hi, - LDAP does still work :) (I only had to insert objectClass=group in the group filter. OC4.5 did not really need this) Did you make an upgrade installation? I installed OC5 from scratch. LDAP authentication seems to work but there's a problem with accessing the user directories. I opened an issue on github: Yes, I upgraded my working 4.5.6 (test-)installation. After logging in with a LDAP account, everything seems to be working. https://github.com/owncloud/core/issues/1664 Dirk Cheers, Holger ___ Owncloud mailing listOwncloud@kde.orghttps://mail.kde.org/mailman/listinfo/owncloud ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] ownCloud alpha 1
On Wed, 2013-02-13 at 11:16 -0500, Jimmy Liranzo wrote: and I also have the following error: Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken. I upgraded from 4.5.6 . I upgraded from 4.5.6 too and get the same error even though connecting via WebDAV works just fine, but that's so far the only problem with oC5, great work. -- Marcel Kühlhorn freenode: tux93 Have a lot of fun! signature.asc Description: This is a digitally signed message part ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] ownCloud alpha 1
On 02/13/2013 03:58 PM, Holger Angenent wrote: - LDAP does still work:) (I only had to insert objectClass=group in the group filter. OC4.5 did not really need this) Oh, what happened with an empty group filter? Could you file a bug report, please? Cheers Arthur ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] ownCloud alpha 1
On 02/13/2013 04:09 PM, Dirk Kastens wrote: Hi, - LDAP does still work :) (I only had to insert objectClass=group in the group filter. OC4.5 did not really need this) Did you make an upgrade installation? I installed OC5 from scratch. LDAP authentication seems to work but there's a problem with accessing the user directories. I opened an issue on github: https://github.com/owncloud/core/issues/1664 Thanks – it's a none problem but we will have fixed it until the final release. Please find more details as comment in the report. Cheers Arthur Dirk ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud ___ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] ownCloud alpha 1
Hi,
for some reason I get a blank page after the installer finished. This
happens in every browser. Here are somne logs:
{app:PHP,message:SQLSTATE[23000]: Integrity constraint
violation: 1062 Duplicate entry
'local::\/home\/www\/htdocs\/owncloudtest\/da' for key 2 at
\/home\/www\/owncloudtest\/lib\/db.php#847,level:4,time:1360824596}
{app:PHP,message:mysql_close(): 47 is not a valid MySQL-Link
resource at
\/home\/www\/owncloudtest\/lib\/setup.php#246,level:2,time:1360824738}
{app:PHP,message:SQLSTATE[23000]: Integrity constraint
violation: 1062 Duplicate entry 'local::\/home\/www\/owncloudtest\/da'
for key 2 at
\/home\/www\/owncloudtest\/lib\/db.php#847,level:4,time:1360824743}
Thx,
Chris
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud
