Hi,

the transferred bytes are just to small, but I cannot find the problem...

output of migration tool looks like this:

Testing a command over the connection...

Remote commands are executing successfully.


Locating the remote 'sendcommand' and Citadel installation...
bash: /usr/local/citadel/sendcommand: Datei oder Verzeichnis nicht gefunden
sendcommand: started (pid=7287) connecting to Citadel server at /var/run/citadel/citadel-admin.socket
200 mail Citadel server ADMIN CONNECTION ready.
NOOP
200 ok
sendcommand: processing ended.

ctdlmigrate will now begin a database migration...
  if the system doesn't start working,
  have a look at the syslog for pending jobs needing to be terminated.
sendcommand: started (pid=1867) connecting to Citadel server at /usr/local/citadel/citadel-admin.socket
200 VG-JAN-CITADEL Citadel server ADMIN CONNECTION ready.
MIGR import
400 sock it to me
sendcommand: usage: sendcommand [-h server_dir] [-w watchdog_timeout]
sendcommand: processing ended.
sendcommand: started (pid=7289) connecting to Citadel server at /var/run/citadel/citadel-admin.socket
200 mail Citadel server ADMIN CONNECTION ready.
MIGR listdirs
100 Don't forget these:
sendcommand: processing ended.
false
rsync -va --rsh='ssh -S /tmp/ctdl.073a.579478fe' root@dgh:/var/lib/citadel/files// /usr/local/citadel/files//
receiving incremental file list
./
Dateien/

sent 18 bytes  received 74 bytes  184.00 bytes/sec
total size is 0  speedup is 0.00
false
rsync -va --rsh='ssh -S /tmp/ctdl.073a.579478fe' root@dgh:/etc/citadel/messages// /usr/local/citadel/messages//
receiving incremental file list
./
aideopt
changepw
dotopt
entermsg
entopt
goodbye
hello
help
mainmenu
newuser
readopt
register
roomaccess
unlisted

sent 382 bytes  received 1,670 bytes  4,104.00 bytes/sec
total size is 5,325  speedup is 2.60
false
rsync -va --rsh='ssh -S /tmp/ctdl.073a.579478fe' root@dgh:/etc/ssl/citadel// /usr/local/citadel/keys/
receiving incremental file list
./
citadel.cer
citadel.csr
citadel.key

sent 101 bytes  received 2,411 bytes  5,024.00 bytes/sec
total size is 2,211  speedup is 0.88
false
false


 *** Citadel migration was unsuccessful. ***

Hey guys! I just installed Citadel for the first time and I set it up using LDAP with Active Directory and I can't login with the admin credentials I provided during setup.. Would I need to reinstall Citadel or is there a way to add an admin user or change the information for the current one?

Which install method did you use? Easy Install or packages from the distro?

Fri Jun 16 2017 08:00:08 PM EDT from ghostwolf1228 @ Uncensored

Hey guys! I just installed Citadel for the first time and I set it up using LDAP with Active Directory and I can't login with the admin credentials I provided during setup.. Would I need to reinstall Citadel or is there a way to add an admin user or change the information for the current one?

I went away for a weekend and found that my database size has quintupled, and my /usr/local/citadel/data folder is now full log.<number> files. Is there a way of clearing out those log files without damaging data, and finding out which account(s) are the culprits in this massive growth?

<singsong> Never mind....

I found the perp (um, friend) and deleted his account. I'll wait for the scheduled purge to run for those log files.

The purge cleaned up the log files, but I'm still seeing a really large database; is there a way to clean it up?

That would be a worthy thing to look into....

Wed Jun 21 2017 01:19:22 PM EDT from IGnatius T Foobar @ Uncensored

Unfortunately you are seeing the natural way that Berkeley DB allocates disk space. The files never shrink; instead, empty space is marked for re-use later on. As a result, the size of the file isn't actually the size of the data; it's more like a "high water mark."

See also: http://www.citadel.org/doku.php/faq:systemadmin:disk_space

If this is highly undesirable for some reason, you can (after taking a backup, of course) shut down Citadel server and run database_cleanup.sh to dump-and-load your database. Keep in mind, however, that database_cleanup.sh requires enough free space on your disk to hold both the dump and the database itself, so if you're doing this because of a disk space crunch, make sure there's an amount of free space on the filesystem containing /tmp that is *at least* double the size of your database.

Hmm. Now I'm seeing there's a function called db->compact()
https://docs.oracle.com/cd/E17275_01/html/api_reference/C/dbcompact.html

Maybe that can be worked into the code, but I don't see a command line utility to do that.

Specifically, this portion makes for a hopeful appearance...

flags

The flags parameter must be set to 0 or one of the following values:

 

• DB_FREELIST_ONLY

  Do no page compaction, only returning pages to the filesystem that are already free and at the end of the file. This flag must be set if the database is a Hash access method database.

• DB_FREE_SPACE

  Return pages to the filesystem when possible. If this flag is not specified, pages emptied as a result of compaction will be placed on the free list for re-use, but never returned to the filesystem.

  Note that only pages at the end of a file can be returned to the filesystem. Because of the one-pass nature of the compaction algorithm, any unemptied page near the end of the file inhibits returning pages to the file system. A repeated call to the DB->compact() method with a low compact_fillpercent may be used to return pages in this case.

Wed Jun 21 2017 01:19:22 PM EDT from IGnatius T Foobar @ Uncensored

Unfortunately you are seeing the natural way that Berkeley DB allocates disk space. The files never shrink; instead, empty space is marked for re-use later on. As a result, the size of the file isn't actually the size of the data; it's more like a "high water mark."

See also: http://www.citadel.org/doku.php/faq:systemadmin:disk_space

If this is highly undesirable for some reason, you can (after taking a backup, of course) shut down Citadel server and run database_cleanup.sh to dump-and-load your database. Keep in mind, however, that database_cleanup.sh requires enough free space on your disk to hold both the dump and the database itself, so if you're doing this because of a disk space crunch, make sure there's an amount of free space on the filesystem containing /tmp that is *at least* double the size of your database.

Hmm. Now I'm seeing there's a function called db->compact()
https://docs.oracle.com/cd/E17275_01/html/api_reference/C/dbcompact.html

Maybe that can be worked into the code, but I don't see a command line utility to do that.

So I'm trying to sync with my Android phone. Citadel ought to support one of the CalDav sync tools per the docs, but I don't have a lot of luck. Some tools work one way, others work another. Anywho, the one I'd like to use is DAVDroid, but it cannot list the calendar entries. Strangely, it seems to be able to sync up new entries from my phone. I've provided a lot of details to DavDroid here:

https://forums.bitfire.at/topic/1467/sync-errors-with-citadel-groupware-server-calendar

but the response from them per debug output is it's a Citadel / Server problem because:

The server sends an 500 Internal server error on a CalDAV request. Please contact server support.

In that thread I provide a lot of details so I'll copy the rest of my post here:

I have been running the Citadel groupware server from www.citadel.org for years. Recently I needed a calendar to share with others, and as it claims to support that as well as ical/caldav I figured I use the same system. The Calendar works fine from Thunderbird. DavDroid seems to be able to sync changes from my phone up to the calendar, but not entries from the server down to the phone. So currently I end up using 2 products, iCal Import/Export 3.1 to sync down entries (if I try and use it to upload entries it seems to wipe the server's calendar), and DavDroid to sync changes back up. I'd of course like to get down to one product, and DavDroid seems more simple in the UI if I could get it fully functional.

Citadel is a bit wonky on versioning now. I'm running on Scientific Linux 6.8 (RHEL derivative) and Citadel 907. I have DavDroid 1.6.2-ose from F-Droid repo on a Samsung Note 5 phone running Android 7 Security patch level May 1,2017 kernel version 3.10.61-10809541. Debug info here:
https://pastebin.com/R1NM0pAb

So on the Citadel side - any ideas?