Language:
switch to room list switch to menu My folders
Go to page: First ... 24 25 26 27 [28] 29 30 31
[#] Fri Nov 13 2020 20:37:41 EST from omatnet @ Uncensored

Subject: Re: Both methods of migration attempts crash within seconds

[Reply] [ReplyQuoted] [Headers] [Print]

Thanks again!

Well, I asked about a database recovery procedure because in my attempt to import the XML, the new server is giving errors like:
"citserver[3758]: db: cdb_store(3): BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery"

I can see the "database_cleanup.sh" utility in the citadel folder, but I can't find the "db_recover". Any idea where I can download the db_recover from?

As for database corruption issues, it happened to me by now both with old and new versions of everything - WebCit 926 (or is it Citadel 929) have enough holes that cause un-savable crashes. With a complete clean install with U20.04 it allowed me to add a room that already exists, and then when I deleted the room, it crashed. For a while, after after a full restart, there was no ability to log on with WebCit and finally when I managed to, it was not possible to log into that user. Tried to delete the user - and it shows as if the user was deleted, but when trying to add the user again - it claims the user already exists (although the user doesn't in the administrator's user window...).

I'll try the "database_cleanup.sh" and if that doesn't work either, I'll go back to manually recreating all users and settings, and then using the IMAP solution to copy all messages from the old server to the new server (and use "MIGR export" every step of the way, to have a backup to fall back to, in case of another corruption...

Thanks!

 

Fri Nov 13 2020 16:23:53 EST from platonov @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

I'll reply in-line...

Fri Nov 13 2020 12:46:10 EST from omatnet @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

Thank you for the detailed reply!

I tried your suggestion, but just the same - it crashed within seconds with the last text line being "Alarm clock", and the Citadel server crashed as well. The XML file created was very small, just as if the creation stopped abruptly. Although there is no other indication, I can only assume that there is some corruption in the data file, or a bad parameter that causes the crash.

This does smell like a database corruption issue. Unfortunately, I am not that much competent on database corruption issues. But "MIGR export/import" should be able to recover what is good there for data. Actually, once you do "MIGR export" part, you can then look at the XML file and see how far did it get. There are several sections in the xml file, such as <config>"</config>,,,,,and

If you got at least some messages, the rest of the xml file is messages, and some could be damaged.

Basically, I'd zipped up your entire citadel/data dir regardless. If you are patient enough to follow and track things, you'll eventually find the best possible solution under the circumstances.

Are you familiar with any utility to check/repair the data files before any migration attemps?

Look at the following post by IGnatius, Da Citadel Master:
===============================================================
Database backup/restore/recover
 Mon Sep 07 2020 18:11:49 EDT from IGnatius T Foobar @ Uncensored

Subject: Re: Database corruption

It isn't common for a Citadel database to simply go bad like that, unless you ran out of disk space, or somehow got two Citadel servers running at the same time (but the software tries to prevent that).

With the server shut down, you can attempt the following repairs:

1. Use "db_recover -c" as per the Berkeley DB supplied directions, to attempt to clean the database files.

2. If that doesn't work, the "database_cleanup.sh" script will often succeed where db_recover fails. Be sure you have plenty of free disk space because this is basically a dump-and-load of your db. 
===============================================================
Does 'sendcommand' have any command that would do that? I can find a detailed list of its commands

Well, sendcommand is what everything goes through eventually, as far as I know. That is the main "entry door" to the citadel. Look at: https://citadel.org/protocol.html

You can execute any protocol command via sendcommand interface.

Is there a way to debug or troubleshoot something like that? If I know what causes the problem, or even if it is a specific user - I could at least delete that user and continue with the full automatic migration.

Well, you are in a tough situation. Too little is known at the moment. All I can suggest is do not get frustrated and try to recover as much as you can. If "MIGR export" produced at least some of your database in XML format, then you may be able to just feed that XML back to citadel via "MIGR export".

That's the advantage and beauty of a pure text data formats. They can be edited in any way you please pretty much and if there is something that is possible to recover, you can use only that part of data which looks good.

 Thank you so much!

I wish I could be more helpful than I am. But I wish you good luck and not to get too frustrated.

Thu Nov 12 2020 17:38:03 EST from platonov @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

Well, migration might work if you do all the steps exactly. Try these steps:

(just make sure you do a backup of your citadel/data dir)

To export/import all Citadel databases do (this was done under Ubuntu 20.04):

  • sudo /usr/local/citadel/sendcommand "MIGR export" > ~/citadel/cit929_exported_2020_11_10_01.xml

This is where you split this list into 2 parts, the export and import. The following lines are for the target machine.

  • sudo service citadel stop
  • su -
  • rm /usr/local/citadel/data/*
  • cd /usr/local/citadel
  • sudo service citadel start
  • ./setup
  • sudo /usr/local/citadel/sendcommand "MIGR import" < ~/citadel/cit929_exported_2020_11_10_01.xml
  • sudo service citadel restart

What is to keep in mind is that you don't do "migr import" to the citadel databases that still exist (meaning citadel/data/* are not removed). There are several reasons why you want to do the import to the virgin citadel databases.

Basically, with "MIGR import" you are rebuilding everything and in order to avoid any kinds of conflicts with the old data and possibly network activity, like RSS feeds or mail runs, causing database updates you do migr import on a virgin system.

This has been done several times and the last one was on Nov 10, 2020.

Hope it works for you.

Thu Nov 12 2020 16:07:25 EST from warbaby @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

We just had a migration thread like this.. and you can probably save lots of time/trouble using the slacker method.  [one guy used it successfully to migrate a 50gb mail db]

Setup a client logged into both systems.. [with perhaps Thunderbird]

give your users instructions and opportunity to drag their messages between accounts into the matching folder on their new .

rooms/llists can be migrated very easily like this.  Just make sure you have a matching room on the new system, drag the messages over imap, drop them in the new folder.

That's about it really.  Line up two webcit windows, check all your system settings before you deep six the old server.

I've done it many times.  It's a good chance to sort, prune and cleanup as you go.

Works perfectly as long as you don't lose network, or power during the process.

There are some thunderbird extensions like "remove duplicate messages" which can help also.

The final step is to cut the DNS.

If you plan ahead, you can probably do this by just updating the single "mail" (mail server) A record.

 

 

Thu Nov 12 2020 03:01:22 PM EST from omatnet @ Uncensored Subject: Both methods of migration attempts crash within seconds

Hi,

I'm trying to migrate our Citadel 8.15 on Ubuntu 12.04 LTS to Citadel 929 on Ubuntu 20.04 however both methods of migration attempts crash within seconds (FYI - I was able to migrate using both methods on other servers).

Explanation: I tried to migrate all data and settings, first using data export/import (sendcommand "ARTV export" > exported.dat) and then using ctdlmigrate (which I used successfully on other servers). In both cases the process crashes within seconds. I can add that 10 days ago I deleted over 130,000 spam messages that were received in the last years but were never actually deleted, and since then action the nightly auto-purge process crashes the citadel server every night, requiring me to restart the Citadel server every morning.

Is there a way to fix the purge process or repair any corrupted files to avoid crashing during a migration attempt? 

If not, is there any other way to migrate the Citadel server, data and settings?

 
Thank you so much for any ideas!


 



 



 



[#] Fri Nov 13 2020 20:41:55 EST from omatnet @ Uncensored

Subject: Re: Both methods of migration attempts crash within seconds

[Reply] [ReplyQuoted] [Headers] [Print]

Actually I just found the db_recover. It is at: /usr/local/ctdlsupport/bin/db_recover

When you run database_cleanup.sh the first text message gives you this information and suggests to run it first.

Fri Nov 13 2020 20:37:41 EST from omatnet @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

Thanks again!

Well, I asked about a database recovery procedure because in my attempt to import the XML, the new server is giving errors like:
"citserver[3758]: db: cdb_store(3): BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery"

I can see the "database_cleanup.sh" utility in the citadel folder, but I can't find the "db_recover". Any idea where I can download the db_recover from?

As for database corruption issues, it happened to me by now both with old and new versions of everything - WebCit 926 (or is it Citadel 929) have enough holes that cause un-savable crashes. With a complete clean install with U20.04 it allowed me to add a room that already exists, and then when I deleted the room, it crashed. For a while, after after a full restart, there was no ability to log on with WebCit and finally when I managed to, it was not possible to log into that user. Tried to delete the user - and it shows as if the user was deleted, but when trying to add the user again - it claims the user already exists (although the user doesn't in the administrator's user window...).

I'll try the "database_cleanup.sh" and if that doesn't work either, I'll go back to manually recreating all users and settings, and then using the IMAP solution to copy all messages from the old server to the new server (and use "MIGR export" every step of the way, to have a backup to fall back to, in case of another corruption...

Thanks!

 

Fri Nov 13 2020 16:23:53 EST from platonov @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

I'll reply in-line...

Fri Nov 13 2020 12:46:10 EST from omatnet @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

Thank you for the detailed reply!

I tried your suggestion, but just the same - it crashed within seconds with the last text line being "Alarm clock", and the Citadel server crashed as well. The XML file created was very small, just as if the creation stopped abruptly. Although there is no other indication, I can only assume that there is some corruption in the data file, or a bad parameter that causes the crash.

This does smell like a database corruption issue. Unfortunately, I am not that much competent on database corruption issues. But "MIGR export/import" should be able to recover what is good there for data. Actually, once you do "MIGR export" part, you can then look at the XML file and see how far did it get. There are several sections in the xml file, such as <config>"</config>,,,,,and

If you got at least some messages, the rest of the xml file is messages, and some could be damaged.

Basically, I'd zipped up your entire citadel/data dir regardless. If you are patient enough to follow and track things, you'll eventually find the best possible solution under the circumstances.

Are you familiar with any utility to check/repair the data files before any migration attemps?

Look at the following post by IGnatius, Da Citadel Master:
===============================================================
Database backup/restore/recover
 Mon Sep 07 2020 18:11:49 EDT from IGnatius T Foobar @ Uncensored

Subject: Re: Database corruption

It isn't common for a Citadel database to simply go bad like that, unless you ran out of disk space, or somehow got two Citadel servers running at the same time (but the software tries to prevent that).

With the server shut down, you can attempt the following repairs:

1. Use "db_recover -c" as per the Berkeley DB supplied directions, to attempt to clean the database files.

2. If that doesn't work, the "database_cleanup.sh" script will often succeed where db_recover fails. Be sure you have plenty of free disk space because this is basically a dump-and-load of your db. 
===============================================================
Does 'sendcommand' have any command that would do that? I can find a detailed list of its commands

Well, sendcommand is what everything goes through eventually, as far as I know. That is the main "entry door" to the citadel. Look at: https://citadel.org/protocol.html

You can execute any protocol command via sendcommand interface.

Is there a way to debug or troubleshoot something like that? If I know what causes the problem, or even if it is a specific user - I could at least delete that user and continue with the full automatic migration.

Well, you are in a tough situation. Too little is known at the moment. All I can suggest is do not get frustrated and try to recover as much as you can. If "MIGR export" produced at least some of your database in XML format, then you may be able to just feed that XML back to citadel via "MIGR export".

That's the advantage and beauty of a pure text data formats. They can be edited in any way you please pretty much and if there is something that is possible to recover, you can use only that part of data which looks good.

 Thank you so much!

I wish I could be more helpful than I am. But I wish you good luck and not to get too frustrated.

Thu Nov 12 2020 17:38:03 EST from platonov @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

Well, migration might work if you do all the steps exactly. Try these steps:

(just make sure you do a backup of your citadel/data dir)

To export/import all Citadel databases do (this was done under Ubuntu 20.04):

  • sudo /usr/local/citadel/sendcommand "MIGR export" > ~/citadel/cit929_exported_2020_11_10_01.xml

This is where you split this list into 2 parts, the export and import. The following lines are for the target machine.

  • sudo service citadel stop
  • su -
  • rm /usr/local/citadel/data/*
  • cd /usr/local/citadel
  • sudo service citadel start
  • ./setup
  • sudo /usr/local/citadel/sendcommand "MIGR import" < ~/citadel/cit929_exported_2020_11_10_01.xml
  • sudo service citadel restart

What is to keep in mind is that you don't do "migr import" to the citadel databases that still exist (meaning citadel/data/* are not removed). There are several reasons why you want to do the import to the virgin citadel databases.

Basically, with "MIGR import" you are rebuilding everything and in order to avoid any kinds of conflicts with the old data and possibly network activity, like RSS feeds or mail runs, causing database updates you do migr import on a virgin system.

This has been done several times and the last one was on Nov 10, 2020.

Hope it works for you.

Thu Nov 12 2020 16:07:25 EST from warbaby @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

We just had a migration thread like this.. and you can probably save lots of time/trouble using the slacker method.  [one guy used it successfully to migrate a 50gb mail db]

Setup a client logged into both systems.. [with perhaps Thunderbird]

give your users instructions and opportunity to drag their messages between accounts into the matching folder on their new .

rooms/llists can be migrated very easily like this.  Just make sure you have a matching room on the new system, drag the messages over imap, drop them in the new folder.

That's about it really.  Line up two webcit windows, check all your system settings before you deep six the old server.

I've done it many times.  It's a good chance to sort, prune and cleanup as you go.

Works perfectly as long as you don't lose network, or power during the process.

There are some thunderbird extensions like "remove duplicate messages" which can help also.

The final step is to cut the DNS.

If you plan ahead, you can probably do this by just updating the single "mail" (mail server) A record.

 

 

Thu Nov 12 2020 03:01:22 PM EST from omatnet @ Uncensored Subject: Both methods of migration attempts crash within seconds

Hi,

I'm trying to migrate our Citadel 8.15 on Ubuntu 12.04 LTS to Citadel 929 on Ubuntu 20.04 however both methods of migration attempts crash within seconds (FYI - I was able to migrate using both methods on other servers).

Explanation: I tried to migrate all data and settings, first using data export/import (sendcommand "ARTV export" > exported.dat) and then using ctdlmigrate (which I used successfully on other servers). In both cases the process crashes within seconds. I can add that 10 days ago I deleted over 130,000 spam messages that were received in the last years but were never actually deleted, and since then action the nightly auto-purge process crashes the citadel server every night, requiring me to restart the Citadel server every morning.

Is there a way to fix the purge process or repair any corrupted files to avoid crashing during a migration attempt? 

If not, is there any other way to migrate the Citadel server, data and settings?

 
Thank you so much for any ideas!


 



 



 



 



[#] Fri Nov 13 2020 20:47:51 EST from omatnet @ Uncensored

Subject: Re: Both methods of migration attempts crash within seconds

[Reply] [ReplyQuoted] [Headers] [Print]

I ran both utilities. On one hand, no more error messages - but Citadel server now wont start... so I cannot even import back the good configuration with "MIGR import". Good thing I do image backups of the server as well, so I have something to fall back to. Well, back to the IMAP solution... (or, simply migrate to a newer mail server)

Fri Nov 13 2020 20:41:55 EST from omatnet @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

Actually I just found the db_recover. It is at: /usr/local/ctdlsupport/bin/db_recover

When you run database_cleanup.sh the first text message gives you this information and suggests to run it first.

Fri Nov 13 2020 20:37:41 EST from omatnet @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

Thanks again!

Well, I asked about a database recovery procedure because in my attempt to import the XML, the new server is giving errors like:
"citserver[3758]: db: cdb_store(3): BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery"

I can see the "database_cleanup.sh" utility in the citadel folder, but I can't find the "db_recover". Any idea where I can download the db_recover from?

As for database corruption issues, it happened to me by now both with old and new versions of everything - WebCit 926 (or is it Citadel 929) have enough holes that cause un-savable crashes. With a complete clean install with U20.04 it allowed me to add a room that already exists, and then when I deleted the room, it crashed. For a while, after after a full restart, there was no ability to log on with WebCit and finally when I managed to, it was not possible to log into that user. Tried to delete the user - and it shows as if the user was deleted, but when trying to add the user again - it claims the user already exists (although the user doesn't in the administrator's user window...).

I'll try the "database_cleanup.sh" and if that doesn't work either, I'll go back to manually recreating all users and settings, and then using the IMAP solution to copy all messages from the old server to the new server (and use "MIGR export" every step of the way, to have a backup to fall back to, in case of another corruption...

Thanks!

 

Fri Nov 13 2020 16:23:53 EST from platonov @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

I'll reply in-line...

Fri Nov 13 2020 12:46:10 EST from omatnet @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

Thank you for the detailed reply!

I tried your suggestion, but just the same - it crashed within seconds with the last text line being "Alarm clock", and the Citadel server crashed as well. The XML file created was very small, just as if the creation stopped abruptly. Although there is no other indication, I can only assume that there is some corruption in the data file, or a bad parameter that causes the crash.

This does smell like a database corruption issue. Unfortunately, I am not that much competent on database corruption issues. But "MIGR export/import" should be able to recover what is good there for data. Actually, once you do "MIGR export" part, you can then look at the XML file and see how far did it get. There are several sections in the xml file, such as <config>"</config>,,,,,and

If you got at least some messages, the rest of the xml file is messages, and some could be damaged.

Basically, I'd zipped up your entire citadel/data dir regardless. If you are patient enough to follow and track things, you'll eventually find the best possible solution under the circumstances.

Are you familiar with any utility to check/repair the data files before any migration attemps?

Look at the following post by IGnatius, Da Citadel Master:
===============================================================
Database backup/restore/recover
 Mon Sep 07 2020 18:11:49 EDT from IGnatius T Foobar @ Uncensored

Subject: Re: Database corruption

It isn't common for a Citadel database to simply go bad like that, unless you ran out of disk space, or somehow got two Citadel servers running at the same time (but the software tries to prevent that).

With the server shut down, you can attempt the following repairs:

1. Use "db_recover -c" as per the Berkeley DB supplied directions, to attempt to clean the database files.

2. If that doesn't work, the "database_cleanup.sh" script will often succeed where db_recover fails. Be sure you have plenty of free disk space because this is basically a dump-and-load of your db. 
===============================================================
Does 'sendcommand' have any command that would do that? I can find a detailed list of its commands

Well, sendcommand is what everything goes through eventually, as far as I know. That is the main "entry door" to the citadel. Look at: https://citadel.org/protocol.html

You can execute any protocol command via sendcommand interface.

Is there a way to debug or troubleshoot something like that? If I know what causes the problem, or even if it is a specific user - I could at least delete that user and continue with the full automatic migration.

Well, you are in a tough situation. Too little is known at the moment. All I can suggest is do not get frustrated and try to recover as much as you can. If "MIGR export" produced at least some of your database in XML format, then you may be able to just feed that XML back to citadel via "MIGR export".

That's the advantage and beauty of a pure text data formats. They can be edited in any way you please pretty much and if there is something that is possible to recover, you can use only that part of data which looks good.

 Thank you so much!

I wish I could be more helpful than I am. But I wish you good luck and not to get too frustrated.

Thu Nov 12 2020 17:38:03 EST from platonov @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

Well, migration might work if you do all the steps exactly. Try these steps:

(just make sure you do a backup of your citadel/data dir)

To export/import all Citadel databases do (this was done under Ubuntu 20.04):

  • sudo /usr/local/citadel/sendcommand "MIGR export" > ~/citadel/cit929_exported_2020_11_10_01.xml

This is where you split this list into 2 parts, the export and import. The following lines are for the target machine.

  • sudo service citadel stop
  • su -
  • rm /usr/local/citadel/data/*
  • cd /usr/local/citadel
  • sudo service citadel start
  • ./setup
  • sudo /usr/local/citadel/sendcommand "MIGR import" < ~/citadel/cit929_exported_2020_11_10_01.xml
  • sudo service citadel restart

What is to keep in mind is that you don't do "migr import" to the citadel databases that still exist (meaning citadel/data/* are not removed). There are several reasons why you want to do the import to the virgin citadel databases.

Basically, with "MIGR import" you are rebuilding everything and in order to avoid any kinds of conflicts with the old data and possibly network activity, like RSS feeds or mail runs, causing database updates you do migr import on a virgin system.

This has been done several times and the last one was on Nov 10, 2020.

Hope it works for you.

Thu Nov 12 2020 16:07:25 EST from warbaby @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

We just had a migration thread like this.. and you can probably save lots of time/trouble using the slacker method.  [one guy used it successfully to migrate a 50gb mail db]

Setup a client logged into both systems.. [with perhaps Thunderbird]

give your users instructions and opportunity to drag their messages between accounts into the matching folder on their new .

rooms/llists can be migrated very easily like this.  Just make sure you have a matching room on the new system, drag the messages over imap, drop them in the new folder.

That's about it really.  Line up two webcit windows, check all your system settings before you deep six the old server.

I've done it many times.  It's a good chance to sort, prune and cleanup as you go.

Works perfectly as long as you don't lose network, or power during the process.

There are some thunderbird extensions like "remove duplicate messages" which can help also.

The final step is to cut the DNS.

If you plan ahead, you can probably do this by just updating the single "mail" (mail server) A record.

 

 

Thu Nov 12 2020 03:01:22 PM EST from omatnet @ Uncensored Subject: Both methods of migration attempts crash within seconds

Hi,

I'm trying to migrate our Citadel 8.15 on Ubuntu 12.04 LTS to Citadel 929 on Ubuntu 20.04 however both methods of migration attempts crash within seconds (FYI - I was able to migrate using both methods on other servers).

Explanation: I tried to migrate all data and settings, first using data export/import (sendcommand "ARTV export" > exported.dat) and then using ctdlmigrate (which I used successfully on other servers). In both cases the process crashes within seconds. I can add that 10 days ago I deleted over 130,000 spam messages that were received in the last years but were never actually deleted, and since then action the nightly auto-purge process crashes the citadel server every night, requiring me to restart the Citadel server every morning.

Is there a way to fix the purge process or repair any corrupted files to avoid crashing during a migration attempt? 

If not, is there any other way to migrate the Citadel server, data and settings?

 
Thank you so much for any ideas!


 



 



 



 



 



[#] Sat Nov 14 2020 08:16:30 EST from platonov @ Uncensored

Subject: MIGR export/import for database recovery/upgrades/selective mods

[Reply] [ReplyQuoted] [Headers] [Print]

I'd like to understand the "MIGR export/import" commands a lil bit deeper than a skin-deep level.
It seems to me that MIGR is a pretty flexible and powerful mechanism
for doing things like database repair and/or modification on either the entire database
or its sections: config, user, room, floor, message.

It seems that it also could be used for restoring just database sections or
even a selected few variables, parameters and so on.

For example if there is a database corruption you may loose
your config parameters, in which case you could simply edit
the last good XML created by MIGR export and copy the config
section to a separate XML file which you could then import and thus
recover your system parameters.

Yes, things get tricky when you start dealing with users,
rooms, floors or messages and if you change some things by editing
the XML file, you may create conflicts or loose the entire sections
of the database if you, for example, change the room number without
changing other related things so it is all remains consistent.

But if you are aware of what you are doing and understand the
consequences then MIGR export/import become a pretty powerful
and flexible tool for taking care of some database damages
and/or reconfiguring some things en-masse, which could be done
in minutes if not seconds, instead of wasting hours by doing it
by hand via either webcit or textclient.

Could someone clarify some of these points and explain why it
is a "no-no" deal to do the database upgrades via MIGR export/import
or why it is not a good idea to rely on this mechanism for restoring
the selected sections?



[#] Sat Nov 14 2020 13:31:01 EST from omatnet @ Uncensored

Subject: Re: MIGR export/import for database recovery/upgrades/selective mods

[Reply] [ReplyQuoted] [Headers] [Print]

Those are very good points. I was never able to find a detailed description of the 'sendcommand' and the commands + parameters it can received (other than the 1-page on the Citadel.org website). If there is some detailed documentation for the 'sendcommand' it could be a good start.

Can anyone direct me/us to a good and detailed 'sendcommand' commands+parameters documentation? 

Sat Nov 14 2020 08:16:30 EST from platonov @ Uncensored Subject: MIGR export/import for database recovery/upgrades/selective mods

I'd like to understand the "MIGR export/import" commands a lil bit deeper than a skin-deep level.
It seems to me that MIGR is a pretty flexible and powerful mechanism
for doing things like database repair and/or modification on either the entire database
or its sections: config, user, room, floor, message.

It seems that it also could be used for restoring just database sections or
even a selected few variables, parameters and so on.

For example if there is a database corruption you may loose
your config parameters, in which case you could simply edit
the last good XML created by MIGR export and copy the config
section to a separate XML file which you could then import and thus
recover your system parameters.

Yes, things get tricky when you start dealing with users,
rooms, floors or messages and if you change some things by editing
the XML file, you may create conflicts or loose the entire sections
of the database if you, for example, change the room number without
changing other related things so it is all remains consistent.

But if you are aware of what you are doing and understand the
consequences then MIGR export/import become a pretty powerful
and flexible tool for taking care of some database damages
and/or reconfiguring some things en-masse, which could be done
in minutes if not seconds, instead of wasting hours by doing it
by hand via either webcit or textclient.

Could someone clarify some of these points and explain why it
is a "no-no" deal to do the database upgrades via MIGR export/import
or why it is not a good idea to rely on this mechanism for restoring
the selected sections?



 



[#] Sat Nov 14 2020 13:37:15 EST from omatnet @ Uncensored

Subject: Re: MIGR export/import for database recovery/upgrades/selective mods

[Reply] [ReplyQuoted] [Headers] [Print]

To be more specific: The link showing in the 'sendcommand' ubuntu manpage (and other online docs I can find for sendcommand) under 'CitadelCommands' parameter is:

  http://www.citadel.org/doku.php/documentation:appproto:start

and this link is broken, as are alll other links I can find for CitadelCommands and sendcommand parameters.

 

Sat Nov 14 2020 13:31:01 EST from omatnet @ Uncensored Subject: Re: MIGR export/import for database recovery/upgrades/selective mods

Those are very good points. I was never able to find a detailed description of the 'sendcommand' and the commands + parameters it can received (other than the 1-page on the Citadel.org website). If there is some detailed documentation for the 'sendcommand' it could be a good start.

Can anyone direct me/us to a good and detailed 'sendcommand' commands+parameters documentation? 

Sat Nov 14 2020 08:16:30 EST from platonov @ Uncensored Subject: MIGR export/import for database recovery/upgrades/selective mods

I'd like to understand the "MIGR export/import" commands a lil bit deeper than a skin-deep level.
It seems to me that MIGR is a pretty flexible and powerful mechanism
for doing things like database repair and/or modification on either the entire database
or its sections: config, user, room, floor, message.

It seems that it also could be used for restoring just database sections or
even a selected few variables, parameters and so on.

For example if there is a database corruption you may loose
your config parameters, in which case you could simply edit
the last good XML created by MIGR export and copy the config
section to a separate XML file which you could then import and thus
recover your system parameters.

Yes, things get tricky when you start dealing with users,
rooms, floors or messages and if you change some things by editing
the XML file, you may create conflicts or loose the entire sections
of the database if you, for example, change the room number without
changing other related things so it is all remains consistent.

But if you are aware of what you are doing and understand the
consequences then MIGR export/import become a pretty powerful
and flexible tool for taking care of some database damages
and/or reconfiguring some things en-masse, which could be done
in minutes if not seconds, instead of wasting hours by doing it
by hand via either webcit or textclient.

Could someone clarify some of these points and explain why it
is a "no-no" deal to do the database upgrades via MIGR export/import
or why it is not a good idea to rely on this mechanism for restoring
the selected sections?



 



 



[#] Sat Nov 14 2020 13:45:26 EST from omatnet @ Uncensored

Subject: Re: MIGR export/import for database recovery/upgrades/selective mods

[Reply] [ReplyQuoted] [Headers] [Print]

...unless the new link is to the Citadel protocol, at: https://www.citadel.org/protocol.html

However, neither MIGR export/import (nor ARTV export/import which I mentioned in a previous post) commands are listed there, while those are the only two commands we discuss here for Citadel server backup and migration... 

Suggestions?

Sat Nov 14 2020 13:37:15 EST from omatnet @ Uncensored Subject: Re: MIGR export/import for database recovery/upgrades/selective mods

To be more specific: The link showing in the 'sendcommand' ubuntu manpage (and other online docs I can find for sendcommand) under 'CitadelCommands' parameter is:

  http://www.citadel.org/doku.php/documentation:appproto:start

and this link is broken, as are alll other links I can find for CitadelCommands and sendcommand parameters.

 

Sat Nov 14 2020 13:31:01 EST from omatnet @ Uncensored Subject: Re: MIGR export/import for database recovery/upgrades/selective mods

Those are very good points. I was never able to find a detailed description of the 'sendcommand' and the commands + parameters it can received (other than the 1-page on the Citadel.org website). If there is some detailed documentation for the 'sendcommand' it could be a good start.

Can anyone direct me/us to a good and detailed 'sendcommand' commands+parameters documentation? 

Sat Nov 14 2020 08:16:30 EST from platonov @ Uncensored Subject: MIGR export/import for database recovery/upgrades/selective mods

I'd like to understand the "MIGR export/import" commands a lil bit deeper than a skin-deep level.
It seems to me that MIGR is a pretty flexible and powerful mechanism
for doing things like database repair and/or modification on either the entire database
or its sections: config, user, room, floor, message.

It seems that it also could be used for restoring just database sections or
even a selected few variables, parameters and so on.

For example if there is a database corruption you may loose
your config parameters, in which case you could simply edit
the last good XML created by MIGR export and copy the config
section to a separate XML file which you could then import and thus
recover your system parameters.

Yes, things get tricky when you start dealing with users,
rooms, floors or messages and if you change some things by editing
the XML file, you may create conflicts or loose the entire sections
of the database if you, for example, change the room number without
changing other related things so it is all remains consistent.

But if you are aware of what you are doing and understand the
consequences then MIGR export/import become a pretty powerful
and flexible tool for taking care of some database damages
and/or reconfiguring some things en-masse, which could be done
in minutes if not seconds, instead of wasting hours by doing it
by hand via either webcit or textclient.

Could someone clarify some of these points and explain why it
is a "no-no" deal to do the database upgrades via MIGR export/import
or why it is not a good idea to rely on this mechanism for restoring
the selected sections?



 



 



 



[#] Sat Nov 14 2020 14:39:50 EST from omatnet @ Uncensored

Subject: Re: Both methods of migration attempts crash within seconds

[Reply] [ReplyQuoted] [Headers] [Print]

I found one reason for MIGR command ending abruptly with an 'Alarm clock' message and have a working solution!

When it happened to me also on a fresh install of the latest Citadel server on U20.04 I researched into it more, and found that the 'sendcommand' has a default timeout that is relatively short, between 30s to 1min (I didn't spend time to measure, sorry). So if the database was large enough so that the MIGR command did not complete within that short timeout, 'sendcommand' would terminate before finishing the migration with an 'Alarm clock' message. The solution is to use the -w parameter of send command, that defines a different timeout, in seconds. So for example, if you want to give it a 5 min timeout (300 seconds) the command would be with using the -w300 (no space between the 'w' and the '300'):

./usr/local/citadel/sendcommand -w300 "MIGR export" > CitadelBackup-YYYY-MM-DD.xml

I checked and it works well! One step forward.

This worked well on the new citadel server with the fresh installation. Now I will have to check the same on the older Citadel server, the one I'm trying to migrate. Will report back

 

Fri Nov 13 2020 12:46:10 EST from omatnet @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

Thank you for the detailed reply!

 

I tried your suggestion, but just the same - it crashed within seconds with the last text line being "Alarm clock", and the Citadel server crashed as well. The XML file created was very small, just as if the creation stopped abruptly. Although there is no other indication, I can only assume that there is some corruption in the data file, or a bad parameter that causes the crash.

Are you familiar with any utility to check/repair the data files before any migration attemps? Does 'sendcommand' have any command that would do that? I can find a detailed list of its commands

Is there a way to debug or troubleshoot something like that? If I know what causes the problem, or even if it is a specific user - I could at least delete that user and continue with the full automatic migration.

 

Thank you so much!

Thu Nov 12 2020 17:38:03 EST from platonov @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

Well, migration might work if you do all the steps exactly. Try these steps:

(just make sure you do a backup of your citadel/data dir)

To export/import all Citadel databases do (this was done under Ubuntu 20.04):

 

  • sudo /usr/local/citadel/sendcommand "MIGR export" > ~/citadel/cit929_exported_2020_11_10_01.xml
  • sudo service citadel stop
  • su -
  • rm /usr/local/citadel/data/*
  • cd /usr/local/citadel
  • sudo service citadel start
  • ./setup
  • sudo /usr/local/citadel/sendcommand "MIGR import" < ~/citadel/cit929_exported_2020_11_10_01.xml
  • sudo service citadel restart

What is to keep in mind is that you don't do "migr import" to the citadel databases that still exist (meaning citadel/data/* are not removed). There are several reasons why you want to do the import to the virgin citadel databases.

Basically, with "MIGR import" you are rebuilding everything and in order to avoid any kinds of conflicts with the old data and possibly network activity, like RSS feeds or mail runs, causing database updates you do migr import on a virgin system.

This has been done several times and the last one was on Nov 10, 2020.

Hope it works for you.

Thu Nov 12 2020 16:07:25 EST from warbaby @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

We just had a migration thread like this.. and you can probably save lots of time/trouble using the slacker method.  [one guy used it successfully to migrate a 50gb mail db]

Setup a client logged into both systems.. [with perhaps Thunderbird]

give your users instructions and opportunity to drag their messages between accounts into the matching folder on their new .

rooms/llists can be migrated very easily like this.  Just make sure you have a matching room on the new system, drag the messages over imap, drop them in the new folder.

That's about it really.  Line up two webcit windows, check all your system settings before you deep six the old server.

I've done it many times.  It's a good chance to sort, prune and cleanup as you go.

Works perfectly as long as you don't lose network, or power during the process.

There are some thunderbird extensions like "remove duplicate messages" which can help also.

The final step is to cut the DNS.

If you plan ahead, you can probably do this by just updating the single "mail" (mail server) A record.

 

 

Thu Nov 12 2020 03:01:22 PM EST from omatnet @ Uncensored Subject: Both methods of migration attempts crash within seconds

Hi,

I'm trying to migrate our Citadel 8.15 on Ubuntu 12.04 LTS to Citadel 929 on Ubuntu 20.04 however both methods of migration attempts crash within seconds (FYI - I was able to migrate using both methods on other servers).

Explanation: I tried to migrate all data and settings, first using data export/import (sendcommand "ARTV export" > exported.dat) and then using ctdlmigrate (which I used successfully on other servers). In both cases the process crashes within seconds. I can add that 10 days ago I deleted over 130,000 spam messages that were received in the last years but were never actually deleted, and since then action the nightly auto-purge process crashes the citadel server every night, requiring me to restart the Citadel server every morning.

Is there a way to fix the purge process or repair any corrupted files to avoid crashing during a migration attempt? 

If not, is there any other way to migrate the Citadel server, data and settings?

 
Thank you so much for any ideas!


 



 



 



 



[#] Sat Nov 14 2020 15:08:18 EST from omatnet @ Uncensored

Subject: Re: Both methods of migration attempts crash within seconds

[Reply] [ReplyQuoted] [Headers] [Print]

Well, no luck there: On the old server (Citadel 8.15 from 2012), the 'sendcommand' simply does not accept the '-w' parameter, and although the text response shows it as part f the syntax, it is simply not accepted and returns as 'error syntax;, no matter if it is placed before the command, after it, with or without a space ('-w300' or '-w 300'). So I guess I have no choice but to give up at this point on actually migrating the old data in a single command... Back to the IMAP manual message copy solution....Oh well

Sat Nov 14 2020 14:39:50 EST from omatnet @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

I found one reason for MIGR command ending abruptly with an 'Alarm clock' message and have a working solution!

When it happened to me also on a fresh install of the latest Citadel server on U20.04 I researched into it more, and found that the 'sendcommand' has a default timeout that is relatively short, between 30s to 1min (I didn't spend time to measure, sorry). So if the database was large enough so that the MIGR command did not complete within that short timeout, 'sendcommand' would terminate before finishing the migration with an 'Alarm clock' message. The solution is to use the -w parameter of send command, that defines a different timeout, in seconds. So for example, if you want to give it a 5 min timeout (300 seconds) the command would be with using the -w300 (no space between the 'w' and the '300'):

./usr/local/citadel/sendcommand -w300 "MIGR export" > CitadelBackup-YYYY-MM-DD.xml

I checked and it works well! One step forward.

This worked well on the new citadel server with the fresh installation. Now I will have to check the same on the older Citadel server, the one I'm trying to migrate. Will report back

 

Fri Nov 13 2020 12:46:10 EST from omatnet @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

Thank you for the detailed reply!

 

I tried your suggestion, but just the same - it crashed within seconds with the last text line being "Alarm clock", and the Citadel server crashed as well. The XML file created was very small, just as if the creation stopped abruptly. Although there is no other indication, I can only assume that there is some corruption in the data file, or a bad parameter that causes the crash.

Are you familiar with any utility to check/repair the data files before any migration attemps? Does 'sendcommand' have any command that would do that? I can find a detailed list of its commands

Is there a way to debug or troubleshoot something like that? If I know what causes the problem, or even if it is a specific user - I could at least delete that user and continue with the full automatic migration.

 

Thank you so much!

Thu Nov 12 2020 17:38:03 EST from platonov @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

Well, migration might work if you do all the steps exactly. Try these steps:

(just make sure you do a backup of your citadel/data dir)

To export/import all Citadel databases do (this was done under Ubuntu 20.04):

 

  • sudo /usr/local/citadel/sendcommand "MIGR export" > ~/citadel/cit929_exported_2020_11_10_01.xml
  • sudo service citadel stop
  • su -
  • rm /usr/local/citadel/data/*
  • cd /usr/local/citadel
  • sudo service citadel start
  • ./setup
  • sudo /usr/local/citadel/sendcommand "MIGR import" < ~/citadel/cit929_exported_2020_11_10_01.xml
  • sudo service citadel restart

What is to keep in mind is that you don't do "migr import" to the citadel databases that still exist (meaning citadel/data/* are not removed). There are several reasons why you want to do the import to the virgin citadel databases.

Basically, with "MIGR import" you are rebuilding everything and in order to avoid any kinds of conflicts with the old data and possibly network activity, like RSS feeds or mail runs, causing database updates you do migr import on a virgin system.

This has been done several times and the last one was on Nov 10, 2020.

Hope it works for you.

Thu Nov 12 2020 16:07:25 EST from warbaby @ Uncensored Subject: Re: Both methods of migration attempts crash within seconds

We just had a migration thread like this.. and you can probably save lots of time/trouble using the slacker method.  [one guy used it successfully to migrate a 50gb mail db]

Setup a client logged into both systems.. [with perhaps Thunderbird]

give your users instructions and opportunity to drag their messages between accounts into the matching folder on their new .

rooms/llists can be migrated very easily like this.  Just make sure you have a matching room on the new system, drag the messages over imap, drop them in the new folder.

That's about it really.  Line up two webcit windows, check all your system settings before you deep six the old server.

I've done it many times.  It's a good chance to sort, prune and cleanup as you go.

Works perfectly as long as you don't lose network, or power during the process.

There are some thunderbird extensions like "remove duplicate messages" which can help also.

The final step is to cut the DNS.

If you plan ahead, you can probably do this by just updating the single "mail" (mail server) A record.

 

 

Thu Nov 12 2020 03:01:22 PM EST from omatnet @ Uncensored Subject: Both methods of migration attempts crash within seconds

Hi,

I'm trying to migrate our Citadel 8.15 on Ubuntu 12.04 LTS to Citadel 929 on Ubuntu 20.04 however both methods of migration attempts crash within seconds (FYI - I was able to migrate using both methods on other servers).

Explanation: I tried to migrate all data and settings, first using data export/import (sendcommand "ARTV export" > exported.dat) and then using ctdlmigrate (which I used successfully on other servers). In both cases the process crashes within seconds. I can add that 10 days ago I deleted over 130,000 spam messages that were received in the last years but were never actually deleted, and since then action the nightly auto-purge process crashes the citadel server every night, requiring me to restart the Citadel server every morning.

Is there a way to fix the purge process or repair any corrupted files to avoid crashing during a migration attempt? 

If not, is there any other way to migrate the Citadel server, data and settings?

 
Thank you so much for any ideas!


 



 



 



 



 



[#] Sat Nov 14 2020 15:58:11 EST from platonov @ Uncensored

Subject: Re: MIGR export/import for database recovery/upgrades/selective mods

[Reply] [ReplyQuoted] [Headers] [Print]

Well, I can offer you a couple of key Citadel documents (see attachments here).

They are based on protocol and system_administration_manual. But they have been redone to include the extensive TOC and all sorts of formatting has been changed to make it all look the way I like to see things. Just unzip it and make sure css/main.css is present for the styles to work they way it was intended.

Protocol is actually that "good and detailed 'sendcommand' commands+parameters documentation".

So...

Sat Nov 14 2020 13:31:01 EST from omatnet @ Uncensored Subject: Re: MIGR export/import for database recovery/upgrades/selective mods

Those are very good points. I was never able to find a detailed description of the 'sendcommand' and the commands + parameters it can received (other than the 1-page on the Citadel.org website). If there is some detailed documentation for the 'sendcommand' it could be a good start.

Can anyone direct me/us to a good and detailed 'sendcommand' commands+parameters documentation? 

Sat Nov 14 2020 08:16:30 EST from platonov @ Uncensored Subject: MIGR export/import for database recovery/upgrades/selective mods

I'd like to understand the "MIGR export/import" commands a lil bit deeper than a skin-deep level.
It seems to me that MIGR is a pretty flexible and powerful mechanism
for doing things like database repair and/or modification on either the entire database
or its sections: config, user, room, floor, message.

It seems that it also could be used for restoring just database sections or
even a selected few variables, parameters and so on.

For example if there is a database corruption you may loose
your config parameters, in which case you could simply edit
the last good XML created by MIGR export and copy the config
section to a separate XML file which you could then import and thus
recover your system parameters.

Yes, things get tricky when you start dealing with users,
rooms, floors or messages and if you change some things by editing
the XML file, you may create conflicts or loose the entire sections
of the database if you, for example, change the room number without
changing other related things so it is all remains consistent.

But if you are aware of what you are doing and understand the
consequences then MIGR export/import become a pretty powerful
and flexible tool for taking care of some database damages
and/or reconfiguring some things en-masse, which could be done
in minutes if not seconds, instead of wasting hours by doing it
by hand via either webcit or textclient.

Could someone clarify some of these points and explain why it
is a "no-no" deal to do the database upgrades via MIGR export/import
or why it is not a good idea to rely on this mechanism for restoring
the selected sections?



cit_docs_01.zip (application/zip, 180583 bytes) [ View | Download ]
[#] Sat Nov 14 2020 20:54:16 EST from ParanoidDelusions @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

So, I'm reading the documentation and FAQ over at citadel.org. I see the documentation on what is required to migrate an existing installation to new hardware - but I don't see anything that describes how to upgrade from one version of Citadel to the most recent. Is there any documentation available for this? 

Of course, I'm on Raspbian, so everything is already kind of outside the bounds of a regular instance of Citadel on Linux. 




[#] Sun Nov 15 2020 04:42:01 EST from platonov @ Uncensored

Subject: System Administration Manual needs fixing

[Reply] [ReplyQuoted] [Headers] [Print]

There is an error in System Administration Manual:

https://citadel.org/system_administration_manual.html
in section Defining neighbor nodes, (lines 1728-1750) inside the <code> section. It has to do with unescaped angle brackets <> creating problems for web browser.

As a result all the rest of the document is displayed with strikethrough/strikeout text and it might look like it is a deliberate attempt to comment out an older version of document, no longer current and, therefore, not correct.

So, all the angle brackets better be properly escaped so that they are not mistakenly interpreted as valid code.

Also, the code needs to be placed inside the <pre>...</pre>



[#] Sun Nov 15 2020 10:11:29 EST from warbaby @ Uncensored

Subject: Re: System Administration Manual needs fixing

[Reply] [ReplyQuoted] [Headers] [Print]

Logged, I'll get to this as soon as I can.

Sun Nov 15 2020 04:42:01 AM EST from platonov @ Uncensored Subject: System Administration Manual needs fixing

There is an error in System Administration Manual:

https://citadel.org/system_administration_manual.html
in section Defining neighbor nodes, (lines 1728-1750) inside the <code> section. It has to do with unescaped angle brackets <> creating problems for web browser.

As a result all the rest of the document is displayed with strikethrough/strikeout text and it might look like it is a deliberate attempt to comment out an older version of document, no longer current and, therefore, not correct.

So, all the angle brackets better be properly escaped so that they are not mistakenly interpreted as valid code.

Also, the code needs to be placed inside the <pre>...</pre>



 



[#] Sun Nov 15 2020 10:24:01 EST from warbaby @ Uncensored

Subject: Documentation, sendcommand, etc...

[Reply] [ReplyQuoted] [Headers] [Print]

The work of updating is already in progress..some pages are currently missing, or have artifacts from the old docuwiki, but it is under way.

Documentation of various commands can be found through the Wayback Machine

https://web.archive.org/web/20170615021003/http://www.citadel.org/doku.php/documentation:appproto:start

Updating documentation is a big issue, and could use everyone's help. I'll make a room for it. 

For the time being, please feel free to post your updates here.

 

 



[#] Sun Nov 15 2020 10:33:44 EST from warbaby @ Uncensored

Subject: A New Citadel Documenation Room is Born!

[Reply] [ReplyQuoted] [Headers] [Print]

Please post your corrections and contributions here.....

http://uncensored.citadel.org/dotgoto?room=Citadel%20Documentation



[#] Sun Nov 15 2020 17:37:25 EST from omatnet @ Uncensored

Subject: Re: MIGR export/import for database recovery/upgrades/selective mods

[Reply] [ReplyQuoted] [Headers] [Print]

Wow, that you so much! This is a great resource and should be on the Citadel website...! I can't believe I've been using Citadel for 8 years now, researching for info and learning to tweak it, and this is the first time I see such a good and comprehensive reference for using the 'sendcommand'

Thank you so much!!!

Sat Nov 14 2020 15:58:11 EST from platonov @ Uncensored Subject: Re: MIGR export/import for database recovery/upgrades/selective mods

Well, I can offer you a couple of key Citadel documents (see attachments here).

They are based on protocol and system_administration_manual. But they have been redone to include the extensive TOC and all sorts of formatting has been changed to make it all look the way I like to see things. Just unzip it and make sure css/main.css is present for the styles to work they way it was intended.

Protocol is actually that "good and detailed 'sendcommand' commands+parameters documentation".

So...

Sat Nov 14 2020 13:31:01 EST from omatnet @ Uncensored Subject: Re: MIGR export/import for database recovery/upgrades/selective mods

Those are very good points. I was never able to find a detailed description of the 'sendcommand' and the commands + parameters it can received (other than the 1-page on the Citadel.org website). If there is some detailed documentation for the 'sendcommand' it could be a good start.

Can anyone direct me/us to a good and detailed 'sendcommand' commands+parameters documentation? 

Sat Nov 14 2020 08:16:30 EST from platonov @ Uncensored Subject: MIGR export/import for database recovery/upgrades/selective mods

I'd like to understand the "MIGR export/import" commands a lil bit deeper than a skin-deep level.
It seems to me that MIGR is a pretty flexible and powerful mechanism
for doing things like database repair and/or modification on either the entire database
or its sections: config, user, room, floor, message.

It seems that it also could be used for restoring just database sections or
even a selected few variables, parameters and so on.

For example if there is a database corruption you may loose
your config parameters, in which case you could simply edit
the last good XML created by MIGR export and copy the config
section to a separate XML file which you could then import and thus
recover your system parameters.

Yes, things get tricky when you start dealing with users,
rooms, floors or messages and if you change some things by editing
the XML file, you may create conflicts or loose the entire sections
of the database if you, for example, change the room number without
changing other related things so it is all remains consistent.

But if you are aware of what you are doing and understand the
consequences then MIGR export/import become a pretty powerful
and flexible tool for taking care of some database damages
and/or reconfiguring some things en-masse, which could be done
in minutes if not seconds, instead of wasting hours by doing it
by hand via either webcit or textclient.

Could someone clarify some of these points and explain why it
is a "no-no" deal to do the database upgrades via MIGR export/import
or why it is not a good idea to rely on this mechanism for restoring
the selected sections?



 



cit_docs_01.zip (application/zip, 180583 bytes) [ View | Download ]
[#] Mon Nov 16 2020 12:23:40 EST from platonov @ Uncensored

Subject: Re: MIGR export/import for database recovery/upgrades/selective mods

[Reply] [ReplyQuoted] [Headers] [Print]

Its a pleasure to hear such a valuation.

I'll follow up on this in some detail in the Citadel Documentation room.

Sun Nov 15 2020 17:37:25 EST from omatnet @ Uncensored Subject: Re: MIGR export/import for database recovery/upgrades/selective mods

Wow, that you so much! This is a great resource and should be on the Citadel website...! I can't believe I've been using Citadel for 8 years now, researching for info and learning to tweak it, and this is the first time I see such a good and comprehensive reference for using the 'sendcommand'

Thank you so much!!!

Sat Nov 14 2020 15:58:11 EST from platonov @ Uncensored Subject: Re: MIGR export/import for database recovery/upgrades/selective mods

Well, I can offer you a couple of key Citadel documents (see attachments here).

They are based on protocol and system_administration_manual. But they have been redone to include the extensive TOC and all sorts of formatting has been changed to make it all look the way I like to see things. Just unzip it and make sure css/main.css is present for the styles to work they way it was intended.

Protocol is actually that "good and detailed 'sendcommand' commands+parameters documentation".

So...

Sat Nov 14 2020 13:31:01 EST from omatnet @ Uncensored Subject: Re: MIGR export/import for database recovery/upgrades/selective mods

Those are very good points. I was never able to find a detailed description of the 'sendcommand' and the commands + parameters it can received (other than the 1-page on the Citadel.org website). If there is some detailed documentation for the 'sendcommand' it could be a good start.

Can anyone direct me/us to a good and detailed 'sendcommand' commands+parameters documentation? 

Sat Nov 14 2020 08:16:30 EST from platonov @ Uncensored Subject: MIGR export/import for database recovery/upgrades/selective mods

I'd like to understand the "MIGR export/import" commands a lil bit deeper than a skin-deep level.
It seems to me that MIGR is a pretty flexible and powerful mechanism
for doing things like database repair and/or modification on either the entire database
or its sections: config, user, room, floor, message.

It seems that it also could be used for restoring just database sections or
even a selected few variables, parameters and so on.

For example if there is a database corruption you may loose
your config parameters, in which case you could simply edit
the last good XML created by MIGR export and copy the config
section to a separate XML file which you could then import and thus
recover your system parameters.

Yes, things get tricky when you start dealing with users,
rooms, floors or messages and if you change some things by editing
the XML file, you may create conflicts or loose the entire sections
of the database if you, for example, change the room number without
changing other related things so it is all remains consistent.

But if you are aware of what you are doing and understand the
consequences then MIGR export/import become a pretty powerful
and flexible tool for taking care of some database damages
and/or reconfiguring some things en-masse, which could be done
in minutes if not seconds, instead of wasting hours by doing it
by hand via either webcit or textclient.

Could someone clarify some of these points and explain why it
is a "no-no" deal to do the database upgrades via MIGR export/import
or why it is not a good idea to rely on this mechanism for restoring
the selected sections?



 



 



cit_docs_01.zip (application/zip, 180583 bytes) [ View | Download ]
[#] Tue Nov 17 2020 15:12:45 EST from platonov @ Uncensored

Subject: email accounts and aliases

[Reply] [ReplyQuoted] [Headers] [Print]

I am trying to setup some email aliases for main account so that the email sent to these alias accounts would also all be copied to one account.

In the article:
How do I create two public email addresses with same recipient but in different domains?
it says:

..."Internet e-mail aliases" will contain all other email addresses for the user. These addresses may be in any domain that is valid for your site.

The issues I have:

1. Some of my accounts can not be entered  as "Internet e-mail aliases". When you enter them and push "Save changes" and then do "Edit configuration" again to verify the data, the fields are blank.

Or, if you enter several comma separated email addresses into aliases field, it removes most of them. But it consistently allows postmaster@my-domain.

And some of the accounts can not be entered even as "Primary Internet e-mail address" and some worked yesterday, but today you can't enter them as aliases any more.

2. What happens in terms of mail delivery to alias addresses? Does mail get copied to all of them or only to the primary account which has all these aliases?

 



[#] Tue Nov 17 2020 17:02:24 EST from jtbreazeoutlook.com @ Uncensored

Subject: E-Mail Attachemnts

[Reply] [ReplyQuoted] [Headers] [Print]

Good day,

I recently set up a Raspberry Pi server running citadel for my local volunteer fire department, switching them over from GoDaddy. This process took me 3 days, and I thought I had everything set, but today I learned that they can't download and open any attachments, or view any attachments sent to them. Any and all attachments say they are corrupted. This has been tested on multiple devices, OS's, and browsers. I looked in the advanced settings and couldn't find anything about attachments. I have removed the spam filter and antivirus, thinking that maybe when they got scanned they became corrupted, but that didn't help. 

What's the fix here? Anything I can do?



[#] Tue Nov 17 2020 17:08:51 EST from jtbreazeoutlook.com @ Uncensored

Subject: Re: E-Mail Attachemnts

[Reply] [ReplyQuoted] [Headers] [Print]

And I just tested that attachments can leave the server, and be ok, but anything coming in gets corrupted. 



Go to page: First ... 24 25 26 27 [28] 29 30 31