Language:
switch to room list switch to menu My folders
Go to page: First ... 24 25 26 27 [28] 29 30 31
[#] 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. 



[#] Tue Nov 17 2020 17:54:13 EST from jtbreazeoutlook.com @ Uncensored

Subject: Re: Corrupted attachments

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

I'm encountering this issue now too. Sorry for adding an extra post with the same exact issue, it took me a while to figure out how to search this thread. I'm using a Pi 4, brand new, new SD card, and new install it Citadel, used the easy install. Everything else is working great, and email attachments leave the server OK, but coming in is when they get corrupted. I did that text file thing to view, and I got similar results. When it left, it was 115 bytes, and when it arrived it was 162 bytes. 

File contents when sent: The quick brown fox jumps over the lazy dog. Now is the time for all good men to come to the aid of their country.

File contents when arrived: The quick brown fox jumps over the lazy dog. Now is the tÿö–ÖRf÷"ÆÂvööBÖVâFò6öÖRFòF†R–BöbF†V—"6÷VçG'’ïÿ

Ÿÿ

So, what can we do about this? I've got some users that need their PDF files pronto, and I need a fix asap.
Tue Aug 25 2020 09:21:21 EDT from alex007 @ Uncensored Subject: Re: Corrupted attachments

it has something to do with character encoding I think.

My editor gedit says, that the original file I sent ist UTF-8 encoded, the file I downloaded with webcit is ISO 8859-15 encoded. See the files attached.

Does this only occur for German installations ?

 

Mon Aug 24 2020 10:22:18 EDT from phaake37 @ Uncensored Subject: Re: Corrupted attachments

All,

 

Did this ever get resolved?  I just tried this on my Citadel Server (Raspberry PI 3B+) and my text file produced:

 

TEXT
TEXT
TEXT
TEXT
TEXT
1234
1234
1234
1234
123ÿó@Ð

 

the Original:

TEXT
TEXT
TEXT
TEXT
TEXT
1234
1234
1234
1234
1234

So it appears to be something with appending to the file or? 

 

Any ideas?

Thanks!

 

 

Sat May 09 2020 23:13:54 EDT from warbaby @ Uncensored Subject: Re: Corrupted attachments

You might try a few more text uploads with various strings and see if there is any consistency with the char length.  

You might try creating some new files with a text editor and see how they look after a reboot.

I predict it is going to be failing Chink SD card writes, rather than a problem with Citadel. 

Or at least, replacing the Chink SD card would be my first approach, since that's a more widely known problem. 

Who knows all the various ways they fail? It might not be a total failure, just not writing properly.

Sometimes you can edit and save a file, it looks okay if you cat it out, but shows garbage after rebooting.

 

Sat May 09 2020 06:58:25 PM EDT from MAS3 @ Uncensored Subject: Re: Corrupted attachments

Thanks for the suggestion.

I created a small file, containing this text:

 

This is a text file created by the standard windows text editor.
It is not a large file, but i'm sure it will be corrupted once it's sent.

So let's see what will happen to it.

 

And this was what was received in the attachment (i'm not sure it will show exactly as i received due to the corruption)
Hmm seems there's more to it, as the font size has changed after copy / paste, and indentation was added:

 

This is a text file created by the standard windowsüÑ•áЁ•‘¥Ñ½È¸4)%Ё¥Ì¹½Ð„±…ɝ”™¥±”°‰ÕЁ¤´ÍÕÉ—ò—Bv–ÆÂ&R6÷''WFVBöæ6R—Bw26VçBàРХ6òÆWBw2?ÙYHÚ]Ú[\[ˆÈ]ƒBþ¾



 



 



 



(, 0 bytes) [View| Download]
(, 0 bytes) [View| Download]

 



blub2webcit.txt (text/plain, 99 bytes) [View| Download]
blub2.txt (text/plain, 95 bytes) [View| Download]
[#] Tue Nov 17 2020 22:45:20 EST from redw @ Uncensored

Subject: Where are the keys stored

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

hi- silly question

referring to: https://www.citadel.org/how_to_install_a_certificate_signed_by_a_recognized_certificate_authority.html

 

Where is the Keys/ directory?

 

thanks,

red



[#] Wed Nov 18 2020 12:04:48 EST from platonov @ Uncensored

Subject: Re: email accounts and aliases

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

The issue of not being able to add aliases to some account has been resolved.

This issue has been resolved.
In order for Administration -> Add, change, delete user accounts -> User name to be able to add aliases, the "Primary Internet e-mail address" on those aliases should be left blank. If it is filled with some address, that address can not be added as alias, since it IS specified.

Tue Nov 17 2020 15:12:45 EST from platonov @ Uncensored Subject: email accounts and aliases

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?

 



 



[#] Wed Nov 18 2020 19:01:29 EST from hamiltra @ Uncensored

Subject: Corrupted Images As Email Attachments

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

Hi Support,

I’m running Citadel version 929, Webcit 926 and server 929 on Raspbian. When i use the web portal to initiate an email with a 465KB image file attached, the image shows blank when clicking the View link in the email from the we portal. A forwarded email outside of Citadel is fine.  Is the web portal corrupting the image on retrieval from the backend?  Please advise.

-roger



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