So, I seem to remember that you use Ubuntu to develop Citadel;
Then... Should I use a VM with Ubuntu server to use Docker + Citadel?
I don't really know which is the right distribution for Docker.
2021 https://kuberty.io/blog/best-os-for-docker/
2021 https://medium.com/nerd-for-tech/look-docker
Lots of great progress tonight on the Docker container. As expected, much
of the work that went into the AppImage was reusable in Docker, and the Docker
version is running quite well already. It doesn't feel as "fragile" as the
AppImage did, and I think it's going to serve us better in the lo
>So, do I stop my tests with the AppImage and wait for the thingy* in Docker?
Let's put it on hold for now. The goal is the same, but the package format
is different.
We've learned a lot over the last few months, and in developing the AppImage
we solved a LOT of problems that were maki
So, do I stop my tests with the AppImage and wait for the thingy* in Docker?
*No disrespect intended.
On 8/3/21 4:29 PM, noreply wrote:
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project
The "series of messages" leads to a sad unraveling.
Well, to a more complex one, I had stopped studying Docker as soon as I
saw the AppImage, I will have to resume its study and use it.
To date, I had barely played with Docker; and like a good Alzheimer's
trainee, I forgot about it in a mat
The only good thing about not seeing your emails for 3 weeks is that I
am binge reading them.
WOW!
On 7/28/21 3:56 PM, IGnatius T Foobar wrote:
s3cr3to: this is all towards your use case, so hold tight, it'll be ready
soon!
Thank you Art, I will be looking forward to it.
At the moment, I am working from home on a rather complex project; but
as soon as I know I will do my best to try it.
P.S. My Thunderbird client is not notifying me of these emails, I'm
barely seeing them, and only because I found it very stra
s3cr3to: this is all towards your use case, so hold tight, it'll be ready
soon!
Ok, with the AppImage release now completed, my next task will be to add
the global email alias table. It won't be pretty, but it'll be accessible
for those who need it.
Sorry I was not very clear.
Currently on the server in production (deb install), I have several
accounts with many aliases.
So, if I would really like to have the version that preserves all these
aliases (from the old style) as in the V-card.
But, if they are going to be lost; then I will
>I assume that restoring the backup will preserve the ones that are
>currently there, am I correct?
What do you mean by "currently there"?
If you're talking about aliases that were in the user account already, with
the limited amount of space, then yes, those will be preserved acros
Good day Art
I was out of the office last week. I could not see the mails in
"Development", something happens with my Thunderbird at home.
Yes the global alias table works for me if with that I manage to place
all the aliases we handle.
I assume that restoring the backup will preserve the ones
The absence of the text client is definitely still something that is missing from the appimage. I'm trying to figure out what happens when the same AppImage is called multiple times on the same host. Does it consume more memory or does it share? If it shares, I could add a calling mode that si
Greetings Art, hope you are well.
Although I have not been able to do much testing, I have a couple of
questions:
1. Do you plan to increase the amount of aliases to support per mail
account? This is so far the only detail that stops me from migrating my
server to the current one.
2. How w
Tell you what ... since your bug reports tend to be good quality and well
triaged, I'm going to just give you access to the "Citadel Issue Tracker"
wiki room. In the distant past we had general bug reporting, but it quickly
filled up with poorly researched/reported bugs, and with feature requests,
Congratulations!
So, now I can test it and report bugs or missing features in Citadel?
(and what may be wrong with the App).
I'm too chatty when reporting bugs, do you have a special bug report
form to use to make it easier for you to follow up?
On 5/21/21 12:31 PM, IGnatius T Foobar wro
Good day,
Just a small observation with the year 2020.
May 21 10:18:55 em2 webcit[27474]: *WebCit 931*
May 21 10:18:55 em2 *webcit*[27474]: Copyright (C) 1996-_*2020*_ by
the citadel.org team
...
May 21 10:18:55 em2 citserver: *** Citadel server engine ***
May 21 10:18:55 em2 c
>Is there any way to list the size of the mailboxes of each account and
>maybe including the size of their folders?
Not inside of Citadel. You could probably find an IMAP tool that does that.
Greetings Art.
Is there any way to list the size of the mailboxes of each account and
maybe including the size of their folders?
I can't figure out where there is 71GB of space, of course it is
possible that there are huge junk files. And in most of the mailboxes I
set a time in months to de
Excellent. It's too bad that Berkeley DB needs that kind of tuning. Perhaps
someday when 32-bit systems are a distant memory we will move to LMDB.
It works!
Compacted from 91G to 71G
From 4PM to 6:26pm
May 19 15:00:08 em2 citserver[1694]: db: compacting database 8
...
May 19 18:26:13 em2 citserver[1694]: housekeeping: WARNING:
housekeeping loop has not run for 206 minutes. Is something stuck?
May 19 18:26:14 em2 citserve
OK, I'll try with this values.
The *first 3* are from my server in production.
And I will try with the *double* in "set_cachesize" of what is suggested
in the document.
# cat /usr/local/citadel/data/DB_CONFIG
*set_lk_max_locks 4000**
**set_lk_max_lockers 4000**
**set_lk_max_object
>*May 17 14:21:06 em2 citserver[25444]: db: BDB3017 unable to
>allocate space from the buffer cache*
>*May 17 14:21:06 em2 citserver[25444]: db: compact: Cannot allocate
>memory*
You didn't recover any disk space because it crashed. This means we have
to put some li
The process is finished, but I don't see any improvement in space.
Sorry for the storm of messages I send; where I write the results that
showed the progress.
In the last messages, I document how it marks a memory error:
May 17 13:28:38 em2 citserver[25444]: db: compacting database 7
*Ma
>I'll let it run another +4 hours, which is about how long it took to do
>the cleanup process.
Did it finish? The warning about the housekeeping loop is normal if you're
doing a big purge, because the purge runs inside the housekeeping loop so
it won't start another one.
It seems that the 4GB of RAM in the VM was insufficient?
May 17 13:28:37 em2 citserver[25444]: housekeeping: WARNING:
housekeeping loop has not run for 42 minutes. Is something stuck?
*May 17 13:28:37 em2 citserver[25444]: db: BDB3017 unable to
allocate space from the buffer cache*
I'll let it run another +4 hours, which is about how long it took to do
the cleanup process.
Or is really something stuck? I just hope the syslog file doesn't grow
too large.
Done. Now I will wait for the auto-purger process, I already set it up
at 12pm.
One more question:
Is it possible to get a listing with the size of each mailbox/account?
It would be very useful to know this information.
On 5/15/21 2:33 PM, IGnatius T Foobar wrote:
>*Question #1*. How can I
I'm wondering if the process of moving from an already fully allocated VM to one on a local thinpool, if you'll be able to step that VM back from full allocation to dynamic.
Sun May 16 2021 15:45:01 EDT from s3cr3to Subject: Re: citadel-1620778956-x86_64.appimage -- looks like it's working?
On
On 5/15/21 2:39 PM, IGnatius T Foobar wrote:
You *could* use database_cleanup.sh to recover disk space on an older server.
I seem to remember a post where you mentioned that it was not possible
to do this in my current version.
I'm not sure what your VM storage looks like, but on my VMs we
According to Proxmox, just because you've returned freed blocks back to the host system doesn't mean you'll see an increase in your available space in your thinpool. I think it has to do with "largest contiguous blocks" of free space. But I think the bottom line is that you may free space, but no
>*Question #2*: Will the reduced DB still be compatible with my current
>8.17 version in production? It would be great to have the downsized DB
>for future migration.
No. Citadel databases are never backward compatible. Once you start up
thew new version of the server with the old
>*Question #1*. How can I configure that option using the AppImage?
>I'm very curious to see what size the DB will be at when I do a big
>purge on some mailboxes that I'm sure are no longer checked.
You can telnet to port 504 and log in as an administrator.
The command you want i
On 5/15/21 12:03 PM, IGnatius T Foobar wrote:
But right now we are looking for problems specific to the AppImage
distribution. Can
you confirm that the AppImage is running properly, and it isn't showing any
problems that aren't problems with Citadel in general?
Like these two things?
Wit
Thank you Art
you can set the hidden server configuration key called "c_shrink_db_files"
to any value other than 0. This will cause the nightly auto-purger run to
shrink the database files on disk after it has completed its work.
*Question #1*. How can I configure that option using the AppImag
>I remembered database_cleanup and wanted to try it after copying my
>backup to the corresponding directory.
Are you running database_cleanup because your db is corrupted? Or are you
running it in an attempt to recover unused disk space?
Please read this knowledge base entry:
> * In the alias section, I don't think I can place all my aliases, it
>seems to be limited to 512 characters, currently I have 779 and
>increasing, of course, I need to debug some aliases.
If I am reading this correctly, you need more space for an account's aliases
than the s
As I commented in private messages.
Everything seems to indicate that the amount of characters in the
aliases causes my password to fail.
And it seems that using too many characters when recording the aliases
causes the App to crash.
Regards
I remembered database_cleanup and wanted to try it after copying my
backup to the corresponding directory.
(This is before testing with the "run" parameter)
I did what warning #3 says to do first.
WARNING #3:
Please try "cd /usr/local/citadel/data;
/tmp/.mount_citadehub75P/usr/bin/d
>Yes! it's working: Sending and receiving external mail.
>
>Can I delete the /usr/local/citadel folder to copy my backup and test
>the migration?
Awesome! Yes, go ahead and delete anything you want. I am finished testing
on your system. Thank you for making it available.
Art
Yes! it's working: Sending and receiving external mail.
Can I delete the /usr/local/citadel folder to copy my backup and test
the migration?
I guess I will have to re-edit my production domain and in the
configuration to be able to do tests
I guess, after restoring I will have to edit
I'm away on business travel this week, so there won't be a lot going on with
Citadel for a few days. Keep that VM running if you are able, and I will
poke in and test things when I can.
We have determined that the main problem, as suspected, is that the server
crashes whenever it makes a
Oh ... I should have thought of that. Instead of sending the VM, you can
just let me log in to it remotely. Why didn't I think of that?
That will be fine, and I will make an effort to give it a try this weekend.
I will probably do something like this: mount the AppImage by hand, jump
in
Hi Art
In a following private mail, I will send you the data of this VM so you
can try it (of course, it is with "run") for sure if you try to send
mails from it it will fail.
If you let me know, I could leave it installed (with install) for
further testing.
I managed to get the DMZ working
Thank you Paranoid!
Actually my problem is that I made the VM very large (500Gb); and
although I cloned it I expected it to reduce in size when cloning, it
did not.
I have previously pulled the VM from Proxmox as an emergency backup.
I will have to make the VM again with a smaller size and le
This is pretty trivial to do... I was able to clone the whole VM to a NAS, then copy it to a different PVE node - and I'm sure I'm not as good at this as you are. I can figure out exactly how I did it, if you run into problems, and document it here.
I need to learn how to clone the VM the current snapshot and see if I
can get it out of storage (NAS).
I guess it would work for you with the selected Format.
I would also have to try to upload it where you indicate at night.
Or devise some way to do so, due to certain restrictions on my side.
Dammit. It's showing the backtrace of an idle thread, not the thread that
crashed.
I don't suppose you have enough bandwidth to simply upload the entire VM?
I don't know if it is useful:
# ls -l /lib/x86_64-linux-gnu/libc.so.6
lrwxrwxrwx 1 root root 12 May 1 2019
/lib/x86_64-linux-gnu/libc.so.6 -> libc-2.28.so
On 5/5/21 8:58 AM, s3cr3to wrote:
*citserver-backtrace.487*:
/lib/x86_64-linux-gnu/libc.so.6(+0x37840) [0x7f88a4c77840]
*citserver-backtrace.487*:
/lib/x86_64-linux-gnu/libc.so.6(+0x37840) [0x7f88a4c77840]
/lib/x86_64-linux-gnu/libc.so.6(nanosleep+0x40) [0x7f88a4d06720]
/lib/x86_64-linux-gnu/libc.so.6(usleep+0x44) [0x7f88a4d31874]
citserver(go_threading+0x3a) [0x43267a]
citserver(main+0x500) [0x417
Ok, good. Now look in /tmp and see if there are any files in /tmp that begin
with "citserver-backtrace". Please post their contents or upload them
somewhere.
After a reboot it can't run
As root:
# uptime
12:25:29 up 0 min, 2 users, load average: 0.00, 0.00, 0.00
# ls -l
total 10392
-rwxr-xr-x 1 root root 10641384 May 2 15:05
citadel-1619988875-x86_64.appimage
# ./citadel-1619988875-x86_64.appimage run
ctdlvisor: Welcome
When trying to send an external mail the app crashes.; then I try to run
the app again and it does not start.
./citadel-1619988875-x86_64.appimage run
ctdlvisor: Welcome to the Citadel System, brought to you using AppImage.
ctdlvisor: LD_LIBRARY_PATH = /tmp/.mount_citadee2euCe/usr/lib
Thank you for the heads up.
I am also setting up my virtualization environment so I can do full testing.
On 4/30/21 8:41 AM, IGnatius T Foobar wrote:
Just a heads up to mention that crash reporting (particularly in AppImage
builds) is still the #1 priority. The previous bunch of commits were
Just a heads up to mention that crash reporting (particularly in AppImage
builds) is still the #1 priority. The previous bunch of commits were just
some brainless sweeping of the floor to keep me occupied while multitasking.
All right, exit code 139 means the server exited on signal 11, which means
that the AppImage supervisor did the wrong thing. It should have restarted
the server instead of exiting.
I will correct the restart-on-crash problem, but since we also need to find
out *where* yours is crashing, we ha
Good day
This is the network configuration of the VM, I need to give myself time
to install a second interface (dmz):
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug ens18
if
>And yes, when trying to send messages it fails; I can send messages to
>the "admin" account itself.
Damn. I did a fresh install of Debian 10, minimal with no extra software
added, on the exact virtual hardware you described in your last post. I still
can't get it to fail.
Can you
Hi Art.
The results I reported a couple of days ago are with the DB itself that
creates the test.
At this time I have not backed up the DB in production for use. I will
do it these days in the evening, as I have to stop my server to be able
to copy it.
# uname -a
Linux em2 4.19.0-16-*a
Ok, so you're using stock Debian 10 (64-bit x86, I assume) and the AppImage
declares that it is compatible. You are attaching it to a copy of an existing
database. Local mail works fine, but any attempt to deliver Internet mail
results in a server crash.
Do I have it clear now?
The appimage is compatible
# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
# ./citadel-1617821022-x64.appimage test
/tmp/.mount_citadeSJ4RAB/usr/local/citadel/citserver: *binary
>And although I discovered my mistake and now this VM works as I know it
>should, in my test it still fails to use the "test" of the AppImage, if
>I try to send some mail it just closes the App.
That's progress. :)
So let me see if I understand correctly. If you run the appi
I misread the message about missing commands in Debian (that was during
installation, not after installation).
And although I discovered my mistake and now this VM works as I know it
should, in my test it still fails to use the "test" of the AppImage, if
I try to send some mail it just closes
Thank you. This got me sorted out on that. As described in Linux> I'm still having some issues... but, that is to be expected, I suppose. :)
Wed Apr 14 2021 17:59:12 EDT from s3cr3to Subject: Re: Citadel app image install
If you try
./citadel-nn-xxx.appimage --help
As an unrecognize op
If you try
./citadel-/nn-xxx/.appimage --help
As an unrecognize option, it will show you the supported parameters and
command: run, test, install, database_cleanup
To install you need:
./citadel-/nn-xxx/.appimage install
Greetings Art
The results of your tests continue to baffle me.
I agree with you, this VM is really weird.
I have reinstalled the VM with debian-10.7.0-amd64-DVD.iso and the
problems are still occurring, I think I found a post (I didn't save it)
where people report similar problems where com
Thanks Art.
I'm going to have to reinstall this VM, for some reason I don't know;
it's showing strange behavior; things that should work don't: I don't
have fdisks, lvm2 commands, and things that a fresh install should have.
Regards
On 4/13/21 12:08 PM, IGnatius T Foobar wrote:
>So, it won
>So, it won't help if I add another virtual disk with more storage if I
>can't change the /tmp dump path. Rigth?
Correct. I've removed the misleading guidance from the help text. The
intermediate
dumps must be on /tmp and this cannot be changed.
If you add another virtual disk it
So, it won't help if I add another virtual disk with more storage if I
can't change the /tmp dump path. Rigth?
On 4/12/21 2:55 PM, IGnatius T Foobar wrote:
>For the latter, how should I run the database_cleanup to get it to take
>the working path?
database_cleanup always stores it
>For the latter, how should I run the database_cleanup to get it to take
>the working path?
database_cleanup always stores its intermediate dumps to /tmp.
I really should change the help text which suggests otherwise.
That's fine with me, let me finish with a good workload that has piled up.
I will restore the "clean" snapshot (with the old data backup intact
from the production server.), update it and try to put an extra disk in it:
For the latter, how should I run the database_cleanup to get it to take
the
The results of your tests continue to baffle me. But I am happy to see it,
because if I can fix it for you, that means there are others who would have
had the same result, and we are preventing all those support requests from
happening.
If you have the patience, I would be VERY grateful t
Hi Art. I answer each point.
1. I need to add another disk because I don't have enough space to run
the database_cleanup. *But how I should specify a location*? The usage
lacks of that info:
*usage*: /home/sys1/citadel-1617821022-x64.appimage [-h
data_directory] [-p http_port] [-s https
>1. What effect would it have if I run *database_cleanup* with my
>backup+data in the DB?
Yes, I'd try database_cleanup just to see what it does.
Also, I have to ask: is the copy of your database actually in
/usr/local/citadel
or is it somewhere else?
You should also try loggi
Greetings Art
I manage to run the AppImage, but I can't login
* Using my correct username and password, it does not show any message
and does not change the page.
* If I try to use invalid credentials, an error message tells me that
the user does not exist or the password is invalid.
T
I'm happy to hear your feedback. One of the reasons I post these internal
updates is to give you (and others who are following the conversation) an
idea of the progress being made. This is how you know what is being worked
on and how close to completion each element has progressed.
Building
Hi Art
I started reading daily since the promise of the container in Docker,
and now with the AppImage, I check daily especially your updates; but I
almost don't comment so as not to invade the thread of your messages.
About the SSH connection freezing, an anecdote:
If I try to work remotely
Finally ... got a working clone of Uncensored. It took eight hours to copy.
When I do it for real I will have to schedule some actual downtime. :(
I am going through the clone system and so far it appears to be a clean replica
of its source (but running in 64-bit of course). New messag
For anyone following the drama:
No matter what I tried, the SSH connection would eventually choke and die.
Small data, big data, keepalives, whatever I tried it would still die during
the replication. So I removed SSH from the data path. Trying it now using
a direct connection to the so
Geez. It's amazing how badly broken the migration tool was. Thankfully
I am running it against a clone of Uncensored and not the real Uncensored
(btrfs is teh r0x0r) because you folks would be miserable getting on here
:)
Right now I'm dealing with a problem where both ends get a SIGPIP
This sucks and blows. I know people hate it when we deprecate the export
format, but as the commit says, it wasn't working anyway.
I've been procrastinating for years on upgrading Uncensored to 64-bit. It
needs to be done, because I want to use the AppImage on my production system.
This wil
If you have to install any dependencies, then the AppImage has failed to live up to its promise.
Hang tight for now. For the past couple of months I've been getting occasional crashes on my production system (this one) and a stack trace shows that it's happening inside of OpenSSL, which is frust
Hi
Maybe I need to install some package or library beforehand.
I'm tempted to reinstall from scratch the VM, just to be sure it's not a
problem on my side.
This new version of Debian has a lot of changes that even I haven't got
to know yet; it is very different from Debian 6 which was when
Ever since moving my hosting operation back home, about once a day I would enter my office and find my computer fans screaming like a jet engine, with WebCit on the production system being the culprit. I finally tracked down the problem. Someone "optimized" a function some number of years ago t
I'm less concerned with the hostname stuff because that's largely just configuration and has less to do with the AppImage.
The service crashing on outbound email is more concerning. Are there core files left behind? We need to figure out where the crash is happening. I may have to just try to
Hi Art.
Using Chrome/Linux Manjaro and the "Feb 25 22:21
citadel-1614316873-x64.appimage" with install.
* I change the password of the admin user, and the email address (it
works)
* I made a new user, assigned him an email and an alias.
* If I check the "Global Address Book", it shows an
Interesting. It sounds like we're making progress. I haven't tried it on the public Internet yet, but I have a couple of extra public IP addresses so I'll give that a try next.
Have you considered that the AppImage can update the DB version of my current server?
Can the installation with easy
Good day Art.
Note: I don't have this VM connected directly to the Internet, it is
using a gateway with static IP to test only the mail sending. Will it be
enough for testing?
With this version. Things that worked:
* login in webcit
* I changed the admin password and it worked
* create a
>You are connected to a Citadel server running Citadel 930.00.
>In order to run this version of WebCit you must also have Citadel 931.00
or newer.
Ok, I believe I have this fixed, but I definitely need to get my builds in
order.
For 64-bit AMD/Intel, try this one:
https:
wtf? How did it build 930 from a version 931 repo?
Time to build a few more test machines :(
I got this message in Firefox
You are connected to a Citadel server running Citadel 930.00.
In order to run this version of WebCit you must also have Citadel 931.00 or
newer.
Process are:
# ps -eaf|grep cit
root 611 1 2 08:50 ? 00:00:00 ./citadel-1613953314-x64.appimage
run -
> I'm looking at the complaints in the Citadel Support room from some
>users who are noting the wrong addresses appearing in the to/from
>headers on Internet mail under certain conditions. That looks like
>something that needs to be addressed sooner than later, so I'll be
>looking
(heart)
Fri Feb 12 2021 19:59:45 EST from IGnatius T Foobar Subject: Re: Yak shaving!
Yeah. It isn't glamorous but time spent on stability and consistency is time well spent.
Yeah. It isn't glamorous but time spent on stability and consistency is time
well spent.
Glad it is happening. I haven't done much testing other than the initial install of it. Had other fish frying myself. But I've been checking in and watching.
Wed Feb 10 2021 10:06:00 EST from IGnatius T Foobar Subject: Yak shaving!
So ... lots of stuff going on, as you can see in the commits,
>Regarding item 4. What will be the mechanism to stop the service using
>the AppImage, just Ctrl-C?
>
>I wonder if it will be with another switch:
># AppImage *stop*
If you're running the AppImage in the foreground, Ctrl-C will still be the
correct way to terminate it. citserve
@Art
Regarding item 4. What will be the mechanism to stop the service using
the AppImage, just Ctrl-C?
I wonder if it will be with another switch:
# AppImage *stop*
or a separate App/command that generates a 'stop flag file' inside the
directory and when the service detects it, it stops clea
>ctdlvisor: pid=449 exited, status=26880, exitcode=105
Hmm. Exit code 105 means it couldn't open the database.
What version of Berkeley DB is running on the production system you cloned?
If it is an Easy Install system, it's probably 6.2.32? That could be the
problem. Your datab
Snapshot restored, running as root: it starts, but it ends soon.
# md5sum Citadel-x86_64.AppImage
51d5fe3e8274b9b004d846fa1a473b34 Citadel-x86_64.AppImage
# ./Citadel-x86_64.AppImage run -h/usr/local/citadel
ctdlvisor: Welcome to the Citadel System, brought to you using AppImage.
The correct way to run it would be
./Citadel-86_64.AppImage run -h/usr/local/citadel
Do not specify "/data". That will be added by the program.
201 - 300 of 1873 matches
Mail list logo
