[Citadel Development] (no subject)
Ok, I think this has something to do with the fact that the screen dimensions are not detected until after the user logs in. Perhaps I can move that since we are no longer tracrecording manually configured screen dimensions on a per-user basis.
[Citadel Development] (no subject)
Yup, that was it. Fixed in revision fa5cd0e6595d211591cc8eebfa81874b03b6162d.
[Citadel Development] Re: TXT client ignores fullscreen=yes and local_screen_dimensions opts
What if you read the userlist? That's guaranteed to go to multiple screenfuls.
[Citadel Development] ALL PACKAGERS PLEASE PUSH CITADEL 8.03 IMMEDIATELY
Attention all Citadel packagers! Please push the current contents of git master as Citadel 8.03 release IMMEDIATELY. The code contains a fix to a VERY SERIOUS bug that is causing upgrades to fail and email aliases to be lost, causing incoming mail to bounce. There is no risk of data corruption and no security vulnerabilities; however due to the issue of bounced mail I am considering this to be a HIGH PRIORITY update. cc: Citadel Development room, Citadel Packaging room.
[Citadel Development] (no subject)
I've finally finished the implementation of OpenID 2.0 authentication (relying party) support. There are only two places where we go to the web using libcurl. I was happy to discover that there were no changes required to the Citadel server protocol, and therefore no changes required in WebCit. I will, however, follow up with WebCit changes that allow a user to sign in using Google, Yahoo, and AOL without even knowing that they're using OpenID. The only thing missing right now is the Simple Registration extension. This is the piece that allows OpenID providers to provide a screen name, location, gender, date of birth, etc. to Citadel, further simplifying the login process. That should be a *fairly* quick thing to do since we did it in OpenID 1.1 and it hasn't changed by a whole lot (I don't think it did anyway). As soon as Simple Registration is completed I will be merging it into git master. Only one file (serv_openid_rp.c) has changed.
[Citadel Development] Re: Warnings
The Free Software Foundation address in this file seems to be outdated or Ok, that's fixed. I see that they now want you to publish their web address instead of their street address, and that's fine. I've switched to the new suggested declaration, except the words free software have once again been replaced with open source software because this is software designed to actually be used instead of to have people like RMS sit around and talk about freedom
[Citadel Development] (no subject)
I've started my own implementation of OpenID 2.0 Relying Party support. After re-reading the specification for the protocol, I've decided that it's doable, it's just going to take some time -- but it's worth doing, far more so than trying to link in libopkele and add C++ dependencies. For those of you following along at home, a couple of years ago (more than a couple of years ago?) I looked at OpenID 2.0 and noticed that there were a half dozen specifications competing to be the one used in the new version of the protocol, so they did a design by committee type thing and ended up mashing them all together. Yuck. OpenID 2.0 requires XRI support, but it appears *nobody* is using XRI. Nobody wants it, nobody is asking for it, and none of the OpenID providers out there seem to be offering it, so we can safely skip this part of the protocol. It also requires Yadis. There doesn't seem to be any way around this. Google, AOL, and others are using the Yadis discovery protocol and generating XRDS documents. Fortunately we can implement Yadis discovery using libcurl and expat, and a bunch of our own code wrapped around that. I'm sure there will be other pitfalls as we go along, but right now I'm just working on implementing the discovery part of the protocol. The good news is that once we have this in place, we'll be able to support not only OpenID on its own, but lots of other single sign ons. OpenID is used by Google, Yahoo, AOL, Microsoft ... pretty much every major service except Facebook. When you see a login box that offers lots of different login options, most of them nowadays are just using OpenID but the site knows the discovery URL to use for that service and fills it in for you.
[Citadel Development] (no subject)
IG: What about citserver's -t trace_file option? Should it still work? Not anymore. It is a vestige of the old logging system which has been completely replaced with syslog. I do see that if you specify the -t option it will create the file and then do nothing with it; this has been fixed as of today.
[Citadel Development] Re: systemd
I'm looking into systemd stuff right now. I'm not sure if citadel is systemd ready (I haven't tested it yet), but this document (http://0pointer.de/public/systemd-man/daemon.html) describes systemd's requirements on a daemon. May be it's of interest for someone. Irrespective of what systemd wants, that looks like a pretty good checklist of things a program ought to be doing when running as a daemon. I'll make a note of it and run through the list when I'm done squashing this ONE LAST BUG that's been holding up the 8.02 release. (I did make a lot of progress on it and we're almost there!!)
[Citadel Development] Re: webcit logging questions
Ooops. Gotta remove those command line options. citserver and webcit both use syslog() now. Each program is also set up so that if run in the foreground, it will log to stderr as well.
[Citadel Development] (no subject)
I sure wish I was coding, but there's so much else to work on right now... I spent the evening redesigining the front page of http://www.citadel.org The page looks a little more modern now. It's tough, as a hacker, for me to reduce the amount of information on that front page. I want to give everyone as much as I can right away. But, business sense and a review of what others are doing seem to dictate that the front page should just capture viewers' attention and then lead them to more information. So, that big banner which takes up most of the screen will eventually rotate between three or four different banners, each highlighting a different reason why you should use Citadel. One of them might even jump on the cloud computing hypewagon and point out that Citadel integrates perfectly with infrastructure as a service architectures. The tag line will of course be Castle on a Cloud big stupid grin
[Citadel Development] (no subject)
Hey everyone, sorry for my relative silence for the last week or so ... I've been building a new version of the Citadel virtual appliance, using a scripted installation this time so that the appliance itself can be regenerated at any time, on any hypervisor. I'm just about done and will initially publish downloadable versions for VMware and KVM. If I can get an OpenVZ one running (which shouldn't be too hard because the new appliance is based on Debian) then I'd like to try to get into the ProxMox VE template library too. After that's done I'm going to update the screenshots on the web site. They need to not only reflect the new look of Citadel 8, but also they need to be bigger and they should slide around and highlight different reasons to look around the web site, which seems to be the trend now. Citadel 8.01 is still in soft launch mode right now. Easy Install and tar.gz both offer 8.01 at this time, and no one seems to be having any big problems, which is good news. Are the .deb and .rpm packages of 8.01 built yet?
[Citadel Development] (no subject)
I'm still not sure how it happened. We're pretty careful about having all of the release scripts track a stable branch of the code. I think something got backported that shouldn't have. Anyway, the Easy Install site is now tracking git master. I have a couple of little things to do and then we'll tag 8.01 and build tarballs etc etc.
[Citadel Development] (no subject)
Listen up, folks: since parts of the 8.00 code seem to have accidentally been released (and I still can't figure out why, but I'm assuming it is my fault) we will release Citadel 8.01 *TODAY*. This will be a soft launch like we did last time: the code will go gold but we won't do a big announcement until after our first bugfix release. This will also give us some time to update the web site with new screenshots, etc. git master will continue to be in deep freeze (serious bugfixes only) until after the release.
[Citadel Development] (no subject)
Well, it looks like networking broke sometime around the beginning of May. I'm posting this message to dogpound2, so I guess when I see it on Uncensored we'll know we fixed it.
[Citadel Development] (no subject)
not that clever. The lack of cleverness comes from having dumbed it down -- a lot. We went through a number of incidents where the IGnet config was being completely lost on some systems, causing all networking to stop.
[Citadel Development] (no subject)
I believe we set our limit to 1024 characters in order to match other protocols such as SMTP/POP which have their line limits set in the same place. (No strbuf here please; doing so would create a cascading set of bugs that would set us back by a year or more.)
[Citadel Development] (no subject)
I don't think so ... are you sure you aren't running up against the limit of a server command length in Citadel?
[Citadel Development] Re: undefined reference to `XML_StopParser'
You can comment out that line. Really. See http://www.cygwin.com/ml/gdb-patches/2007-01/msg00258.html for more information.
[Citadel Development] Re: undefined reference to `XML_StopParser'
Aha! In fact, we did XML_StopParser() specifically to handle that vulnerability. (The guy who sent out the alert was a real asshole about it too.) So we just need to change the XML_MAJOR_VERSION we're looking for from 0 to 1 and that will take care of it, as your patch demonstrates. Thanks!
[Citadel Development] Commit logs now going to a different room
Attention please: Due to the excessive volume of commit logs being posted to this room, all commit logs will now go to a different room called Citadel Commits . It is a hidden room but it is accessible to everyone. Please go there if you wish to view commits. You can also subscribe to it as a mailing list.
[Citadel Development] (no subject)
attachments uploading doesn't work with iceweasel7 ok with chromium though... Tested with Firefox 6, and it works. There is no Firefox 7. Is IceWeasel 7 a production browser?
[Citadel Development] Re: [SCM] citadel.org branch, libevent, updated. 2d65a22caf6157e3a4759e5e17cb2bbd1d5934a9
lib/stringbuf.c: In function 'StrECMAEscAppend': lib/stringbuf.c:2216: error: 'IsUtf8Sequence' undeclared (first use in this function) lib/stringbuf.c:2216: error: (Each undeclared identifier is reported only once lib/stringbuf.c:2216: error: for each function it appears in.) make: *** [lib/stringbuf.lo] Error 1 The build is broken, please help --
[Citadel Development] Re: CONF GETSYS
Well, the form of those commands is fairly straightforward; the trick is in knowing the format of the system configurations that are to be loaded and saved.
[Citadel Development] (no subject)
should this just list rooms which are public subscribeable or our new public rooms too? else maybe the documentation needs to be altered imho? I don't think there is any difference? If you are running an open system then the public rooms are the ones reachable without a login.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. ceffa8fd6967b780a9e74d97a2e49d375d64a4a4
Those last couple of commits I made seem to have improved things a bit. More later.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 0ff2052c39dd1229a93f6d72424275908e203669
I've been working with valgrind extensively and have been doing a lot of make clean. This is a tough one.
[Citadel Development] (no subject)
I noticed about a week or two ago that Uncensored has stopped auto-purging users other than SYS_Citadel. It could theoretically be Eagle eye there. :) But it's no cause for concern -- I increased the user purge time so it'll be a while before DAP kills anyone. Good catch though.
[Citadel Development] (no subject)
IG, please note, that if Hdr-HR.DontNeedAuth is set, no server connection or session is needed, so that name might be a little misleading and you might want to change it. I was wondering what that was about. So it doesn't mean no login is required, it means that no connection to Citadel is needed?
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 9a890c12b27110a519bda6b3c80b812e611be6cf
templatize the summary (half baked) I think you mean not baked. It's totally broken right now.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 7bfc9ea85ba1146f09982b9616eaf82b54321ea4
No, we just pull the top-level headers and we do not fetch the message body.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 7bfc9ea85ba1146f09982b9616eaf82b54321ea4
Good question, and the answer is yes. This is all done within webcit, so it is incapable of bypassing the citadel server's security model.
[Citadel Development] Re:
Actually, I'm in the process of ripping out the *new* way too. The buttons for Reply, ReplyQuoted, and Forward need to carry a whole lot of information (subject, references, recipients) out to the browser and then back in through a URL submission, and because those buttons are passed through the GetLoggedInFirst() framework, their URL's need to be double-escaped. As a result, there are a number of special characters which can break the whole thing if they appear anywhere. Instead of trying to tweak this fragile and ugly situation, I am rewriting it to have the browser simply tell WebCit the number of the message being replied to (or forwarded), and WebCit can fetch all of that information on its own. We already do this for the quoted/forwarded message text, so it should be fairly straightforward to get all the other info too. (I said straightforward rather than easy because the tricky part will be to do it without fetching the message three or four times.)
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 7bfc9ea85ba1146f09982b9616eaf82b54321ea4
This turned out to be nice and clean. It's going to eliminate a lot of potential (and existing) bugs.
[Citadel Development] (no subject)
Yikes. We're being Googled to death.
[Citadel Development] Re: Replacing TinyMCE by CKEditor
After a very short comparison of usability, I propose we give ckeditor.com a try (again?). dothebart mentioned we might have used that one before. This is a short list of reasons why I prefer ckeditor: If it seems better, then I have no particular attachment to TinyMCE and would be willing to try CKeditor instead. I do have one requirement coming up soon: in the not too distant future I would like to add the ability to embed images into messages directly. Presumably this would take the form of first uploading them as attachments, and then the editor would need to know about them so it could offer them to the user. The editor will probably need to know their CID's. I'm not asking you to implement this (unless you're feeling ambitious) but merely to ensure that the possibility to implement it exists.
[Citadel Development] Re: setup bug
modules/blog/serv_blog.c: In function 'blog_upload_beforesave': modules/blog/serv_blog.c:77:13: error: 'BLOG_EUIDBUF_SIZE' undeclared Update your libcitadel.
[Citadel Development] (no subject)
stable broken? gcc -I/var/lib/citadel -Wall -g -Werror=format-security -O2 -Wall -Wcast-qual -Wcast-align -Wstrict-prototypes -D_REENTRANT -pthread -I ./include/ -I. -I ./include/ -DHAVE_CONFIG_H -c modules/wiki/serv_wiki.c -o modules/wiki/serv_wiki.o modules/wiki/serv_wiki.c: In function âwiki_revâ: modules/wiki/serv_wiki.c:593: error: âCitContextâ has no member named âcached_msglistâ modules/wiki/serv_wiki.c:593: error: âCitContextâ has no member named âcached_msglistâ modules/wiki/serv_wiki.c:594: error: âCitContextâ has no member named âcached_num_msgsâ modules/wiki/serv_wiki.c:595: error: âCitContextâ has no member named âcached_msglistâ modules/wiki/serv_wiki.c:596: error: âCitContextâ has no member named âcached_msglistâ Oops. That means I backported a patch to fix a bug that didn't exist in that version. :(
[Citadel Development] Re: Citadel RPM repository
If it is your intention to keep these RPM's up to date, I would love to designate your repo as the official one. Can we name you as the official maintainer on an ongoing basis?
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. dd31b4fd8b79ae81d966ecb923586153c4af966c
Fair enough -- I'm not satisfied with what I did, though. I'm going to change it around a little more. Right now the feed generator is spitting out every line as a CDATA block while it reads those lines from the Citadel server. I need to buffer the whole thing and then output it as a single CDATA block, which sounds like a job for StrBuf.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. dd31b4fd8b79ae81d966ecb923586153c4af966c
- wrap this into subst.c:StrBufAppendTemplate() with a new escaper char? (maybe 'C'?) We can't use CDATA blocks in templates. CDATA is only valid in XML, not HTML (unless you're using XHTML, which we are not...)
[Citadel Development] Re: [SCM] citadel.org branch, stable-78x, updated. v7.86-13-g3f0e1c3
Please don't! We have some functions in our automation framework that do a similar check to allow our scripts to access external files in place of a DUT command and it's ended up causing issues when some of the commands contain a / character. Despite the fact that I don't understand what you just said, I have to point out that the reason I did that ended up becoming somewhat irrelevant anyway. I was hoping to allow Citadel to connect to ClamAV via a unix domain socket, but it turns out the protocol sucks and needs a second channel on the network anyway, so that won't work out. Blah.
[Citadel Development] Re: screenshots showing latest commits: Calendar and Chatroom
Microsoft will always find new ways to suck. Fortunately their reign seems just about over and hopefully in a decade or so we will not have to worry about them. By the way, I applied the git commit-filter you requested.
[Citadel Development] Re: screenshots showing latest commits: Calendar and Chatroom
I know this is an unpleasant thing, but have you been testing these commits with Internet Explorer? Unfortunately we do have to support IE7+
[Citadel Development] Re: bugs and inconsistencies
The command ARTV is not documented on http://www.citadel.org/doku.php/documentation:appproto:start ARTV is deprecated. It has been replaced by MIGR.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 69d7c37613081132e8476550c9810d7633d23fde
array be the smarter solution? I wasn't planning to make the setting persistent across logins.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 69d7c37613081132e8476550c9810d7633d23fde
This update makes a change to struct wcsession; make clean if you're crashing...
[Citadel Development] Re: Embargoed: multiple jabber servers vulnerable to denial of service
I'm willing to hold off on releasing our own security alert, and even perhaps waiting until 0 Day to release an updated version of the software. What I'm *not* willing to do, is to stop using our source code repository the way it was intended because some tinfoil-hat thinks that someone's going to monitor it for potential abuses.
[Citadel Development] Re: Embargoed: multiple jabber servers vulnerable to denial of service
You know what, I am not really interested in working with people who feel the need to tell me exactly what they want me to do, so it's ok. I would much rather accept security alerts from people who do it the normal way.
[Citadel Development] Re: Embargoed: multiple jabber servers vulnerable to denial of service
oops. gotta fix that. We're going to hold off on any releases for now, though. The guy chose some weird non-standard disclosure method and then got his panties in a bunch when I misunderstood it. Normally a coordinated disclosure means that everyone's got a patched version available for download at the time of disclosure. These morons want to have everyone hold off on any patches (including public source code repos) until the disclosure date. I'll hold off on a release until then but I'm not going to stop using git the way it was intended.
[Citadel Development] Re: Embargoed: multiple jabber servers vulnerable to denial of service
I think that method is stupid and I'm not going to follow it. In the real world, coordinated public disclosures include an advisory that says upgrade to version x.yy in order to protect your server against this vulnerability.
[Citadel Development] Re: Embargoed: multiple jabber servers vulnerable to denial of service
Thanks for ignoring what it means to do a coordinated release between different products and vendors... I guess that was the first and last advanced notice for citadel, at least from my side. You were expecting something different? 100% of the security advisories to which we have responded in the past have involved coordinated disclosures in which a published security advisory is able to indicate to end users exactly which versions of various applications are invulnerable at the same time as they are advised of the vulnerability in earlier versions. If you were expecting to operate by some other protocol then perhaps you should have outlined that in advance instead of being sarcastic when you are misunderstood. We have the fix in our tree. There has not been a new version of the software published, nor has there been an advisory posted to our user community. What is it specifically that you are expecting us to do at this time? -- A
[Citadel Development] (no subject)
Interesting observations. It's definitely a work in progress but I'll make a note of those observations as we tune it. Admittedly I'm not all that great a UI designer, so every little bit of feedback helps. I do like having the icons but I think it's beginning to become a problem that we use the same icons over and over again. Fortunately, the quantity, quality, and variety of freely available icons is much better now than it was half a decade ago, so if we added some more we wouldn't have to spend money on this a second time. Thankfully, we are at a point now where the code is stable enough that I can deploy the good builds to Uncensored so everyone can see the development progress.
[Citadel Development] Re: [SCM] citadel.org branch, stable-78x, updated. c08adcea52e85d6139ad158c17eb3d1941df2eb5
Ok, we're good to go with 7.86
[Citadel Development] Re: [SCM] citadel.org branch, stable-78x, updated. 3d8a628f35f644af871e19d9b6a2a30fb66d88a7
Works for me. Can we go right away or do we need to get anything else in there?
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 98077cf98a82f673c2bc0486e32187c30c267eb4
I really do *not* see a need to rewrite the main loop of WebCit. It works fine just the way it is.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 2063519eeba1e97c13732f061faea42556e9488b
According to what I'm reading it doesn't work on Solaris (with Sun's compiler, not gcc).
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 2063519eeba1e97c13732f061faea42556e9488b
I'm probably the wrong person to ask. I think everyone should be running Linux.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 98077cf98a82f673c2bc0486e32187c30c267eb4
For a post-8.00 design, would it make sense to use libev as the housekeeping loop? Then it could take care of SMTP delivery along with everything else the server needs to do in the background, and we can dedicate a thread to it (either the supervisor thread or a different one) -- and then the ordinary worker threads can be used for interactive sessions.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 842319fa33527c94e5ea7dc60e3b4942ad4c7ecc
Looks good so far. I also think that getting rid of all the extra complexity has fixed the RSS reader crashes.
[Citadel Development] Re:
Ok, here's more info on the problem: When the problem starts to happen (again, right after TDAP runs) -- CC-redirect_buffer no longer works for housekeeping threads (bound to masterCC). This means that the fulltext indexer is coming up with blanks too, which I've tentatively verified.
[Citadel Development] Re:
Perhaps I can run tests on a *clone* of Uncensored's db. Over the last two days I've seen the problem begin after the 04:00 hour; this happens to be when we run TDAP so it's definitely possible that we're looking at a memory issue of some sort. It might even be a massive memory leak triggered by TDAP, but I'm really suspicious as to why the only thing it seems to be affecting is outbound mail delivery.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 842319fa33527c94e5ea7dc60e3b4942ad4c7ecc
Removed spurious calls to CtdlClearSystemContext() Hopefully that's what was causing the problem. We'll know by tomorrow morning.
[Citadel Development] Re:
I don't think we have the horsepower to run Uncensored under valgrind. It was bad enough when I constrained its I/O speed a little bit during the last migration -- the system was practically unusable. For the time being I have added a check to see whether msg_size is 0, and if it is, we syslog the problem and then 4XX defer the delivery instead of attempting delivery and losing the message. We can work on this problem in a bit more relaxed fashion as long as I know we're not throwing away mail.
[Citadel Development] Re:
There does seem to be a problem. When citserver is first started there is no problem, but after it runs for a little while, messages are getting corrupted as they are read into the buffer for sending. The symptoms showing up in the log are that the From: address is not extractable (so it's sent to the recipient as MAIL FROM: some...@somewhere.org ) and that we get the warning that the message did not end with a 0x10. I've temporarily added a diagnostic that dumps the buffer to /tmp/badmail.x.x when this condition is detected.
[Citadel Development] Re: [SCM] citadel.org branch, libevent, updated. 1472e247d25c64dd52a1e0d8166946c003b74581
libev in webcit? Why? The main loop of webcit is simple enough. It doesn't need libev.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. d8e37b83842f3724e21da6d191a86d91cd3f3f80
And maybe it's my imagination but I could swear it's faster this way. At the moment I'm using a fixed size thread pool. There are eight worker threads, one master socket listening thread, and one supervisor thread. I haven't decided yet whether I want to move the master socket listener back into the worker pool. What I can tell you is that I intend to make citserver's thread pool expansion algorithm identical to webcit's: start with a very small number of threads, and spawn a new thread whenever it is determined that there is 100% utilization, up to a fixed limit. There is no reduction of the pool size. I think any further architecture decisions will be based upon a discussion of how libev will eventually work. I am hoping that libev could eventually become the main loop for all worker threads.
[Citadel Development] (no subject)
If it were just me, I'd still be quite happy using CVS. I didn't see the point of switching to svn and I really didn't see the point of switching to git either, when CVS was doing the job.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 51a3c9712abdd33ec5871c40a7ae0354110b1883
There's gonna be a huge update coming up as soon as I get things running smoothly again. This is mainly intended to reflect the future migration to a libev-based architecture. The Citadel server is built as a state machine, so the libev move does make sense. This is fundamentally incompatible with the davew thread system, unfortunately -- it's brilliant code but it basically implements an entire multitasking operating system inside the application, which we really don't need. Since it's currently causing stability problems I am removing it. Step 1 will be to go back to the old threading architecture. Step 2 will be to migrate to libev. Then the server will be even *more* of a state machine.
[Citadel Development] (no subject)
A source code management system approved by Ford -- that's a big deal :) According to the logs we switched on 2010-aug-31.
[Citadel Development] (no subject)
This might be a race condition of some sort. If I put a one second sleep between each connection in the second script, it doesn't cause the first script to drop anymore.
[Citadel Development] (no subject)
The problem uncensored is having appears to be reproducible on any Citadel server running the current code. Here's how to reproduce it: 1. Start your Citadel server 2. Run several copies of this script, which will show you exactly when your connection dropped: #!/bin/bash ( while true do echo 'time' sleep 1 done ) |nc my.citadel.server 504 3. Run one or more copies of this script, which rapidly builds and breaks connections: while true; do echo '1 NOOP' | nc my.citadel.server 143 ; done 4. Let it run for a few minutes and you should see everyone drop at the same time.
[Citadel Development] (no subject)
Ok, a quick update: So far I've been able to reduce the crashes, at least, by reducing the load on the system a bit: 1. I've taken the IP addresses of all the hosts that are trying to email room_citadel_stats 5-6 times each minute and firewalled them out, so they can't do that anymore. 2. serv_rssclient was running once every minute. I've changed this to no more than once every 15 minutes. In the last 8 hours or so it hasn't crashed. We are still experiencing the problem, however, where client sessions are occasionally disconnected without any reason. I don't know why and this is the #1 priority to fix.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. cc9210c238de95ad2005ef023897dbf5acecc31d
I'm a little hesitant to put that into 7.xx because I don't know how we fixed it. Somewhere along the line we did something to the I/O layer that made it stable enough for XMPP over TLS to work, but I don't know where or what.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. e432540ab02282396bf87eafde6a1698819912ff
This may all be true. What I'm *not* willing to do is go to disk to check the msglist for the current room before each and every message fetch. I'm sure the tree will be quite unbalanced after the user visits one room, since it is loaded linearly. As other rooms are visited it should theoretically begin to even out. I tried a different approach at first, where we cached the msglist loaded during any CtdlForEachMessage() operation, and then checked it later. It worked *most* of the time, but there were some edge cases where it simply didn't work. For example, when saving a calendar event, we were heading over to the My Citadel Config room, which burned the cache for the calendar room, and then going back to the calendar room and requesting a specific message number we already knew. That would fail every time. There is the possibility of caching the msglist when we first arrive in a room, but that could have an effect on interactive performance as well.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. e432540ab02282396bf87eafde6a1698819912ff
Ok. This solves the problem of I can request arbitrary msgnums and the server will give them to me whether or not they exist in a room to which I have access -- which was only a minor nuisance before, but with Citadel sites being exposed to the public Internet with anonymous guest mode enabled, that would have become quite a large problem. Imagine how lovely it would be if Google indexed it all. :) Unfortunately it takes a little more memory than I wanted it to.
[Citadel Development] Re:
Ok, I've built a VM on an IPv6 connected network for you to test with. Check your email for the login.
[Citadel Development] (no subject)
so, first site with the libev based smtp client has just gone live... Do you need a machine on an IPv6 network to test it with?
[Citadel Development] Re: 303 Status response
This would work quite nicely with my current efforts to remove all of the round-trip form submissions in the system. For example, in the message editor, we no longer submit the form when adding attachments. It is my intention to validate recipients before sending the form as well. And in the calendar view, I would like to do free/busy checking without a submit.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. fb433069aa46d253afbb19dbd358c0d3c0636272
Yes, the chat window uses that API as well, and I believe I've fixed it.
[Citadel Development] Re: [SCM] citadel.org branch, libevent, updated. c12b418a64b44be9d08cae0e5dd25c988a522b90
The conversion of the existing Citadel code to dual-stack actually was far easier than I thought it would be.
[Citadel Development] Re: Message security
Even after you explicitly log out of one of the accounts? What does logout mean in such a case? Is the message requested in the context of the logged-out account, or the new logged in account? Try it again now; it *should* theoretically act like any other web site at this point. If you log out from one window, the session should be logged out and the other window should reflect that as well.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. fb433069aa46d253afbb19dbd358c0d3c0636272
That was kind of nasty. I thought that it was me who broke the ajax stuff, but it was actually the Prototype 1.7 upgrade. Everyone take note of this please, particularly when using ajax_servcmd. The parameters must be wrapped up inside EncodeURI() otherwise they will be truncated.
[Citadel Development] Re: Message security
There was, however, a problem with sessions not being *fully* logged out. I have just fixed that. I doubt we will ever have the ability to log in two different users at the same time from the same browser. On the other hand, I have been adding go= url components to a lot of the stuff I've been touching, so that if a user has two different windows open in two different rooms it'll try to keep each window in the correct room.
[Citadel Development] (no subject)
Getting more REST-like would probably fit in nicely with the anonymous login feature. Any HTTP GET request received by webcit would require webcit to ask citserver if the requested resource required authentication, but then webcit wouldn't need to carry around much, if any, state information. We're solving that problem by obfuscating URL's so you can't tell whether they're REST or not. (It's an SEO feature)
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 12eef2e90231a57d2a436cb885ee2fed657747ea
That'll be quite useful -- I usually have to add temporary logging for just that purpose while debugging various things.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. e396526ea63700bee599f96fc03e72fc8ea503c2
It's been a productive evening. :) Wiki now works and looks good, even in guest mode.
[Citadel Development] Re: wiki still does nothing
If I select edit, and save the page, I still see the same message. No home page is ever created. Any advice here? Sam I can confirm that it's definitely broken and I will fix it.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 2b54d172dce8b1b30dc9cc616edfab531dfeb207
I am a staunch supporter of the GPL. On the other hand, the rhetoric from RMS/FSF gets kind of tiring. I think ESR said it best in this editorial: http://www.linuxtoday.com/news_story.php3?ltsn=1999-06-28-023-10-NW-SM
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 2b54d172dce8b1b30dc9cc616edfab531dfeb207
(Oops ... the canonical location of this essay is: http://www.catb.org/~esr/writings/shut-up-and-show-them.html )
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 17f85f4eeb3f90bf584b483bb4d356f87271bf63
My intention is to completely remove the traditional login screen. All authentication will be performed through the modal dialog and ajax calls. Even on a closed system that does not have guest mode enabled, the login screen will just be a dumb banner with the login modal superimposed on top.
[Citadel Development] (no subject)
I haven't looked at this yet -- I've only isolated the problem message and performed a backtrace. The message in question has been quarantined in the Test Messages room (the subject is CAVE...). When this message is read using webcit stable-78x, webcit dies in an active loop. The looping thread was interrupted and produced the following backtrace: GET /mimepart/2840436/2/101_0091.JPG HTTP/1.1 (gdb) thread 7 [Switching to thread 7 (Thread 0xb6d20b90 (LWP 28843))]#0 0x008d3402 in __kernel_vsyscall () (gdb) bt #0 0x008d3402 in __kernel_vsyscall () #1 0x006a1afb in read () from /lib/libpthread.so.0 #2 0x0011c389 in StrBufReadBLOB (Buf=0x8297f68, fd=0x8296724, append=1, nBytes=1168502, Error=0xb6d20208) at lib/stringbuf.c:3676 #3 0x08056baf in serv_read_binary (Ret=0x8297f68, total_len=1168502, Buf=0x829fdd8) at tcp_sockets.c:370 #4 0x08067043 in mimepart (force_download=0) at messages.c:1572 #5 0x080671b2 in view_mimepart () at messages.c:1662 #6 0x08052159 in session_loop () at webcit.c:726 #7 0x080501f4 in context_loop (Hdr=0xb6d20324) at context_loop.c:611 #8 0x080a2d3c in worker_entry () at sysdep.c:246 #9 0x0069a832 in start_thread () from /lib/libpthread.so.0 #10 0x00605e0e in clone () from /lib/libc.so.6
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. fdb030b497950239b2b7db63b3953f6a6f425f1e
I thought this was going to be done in a separate branch?
[Citadel Development] Re: [SCM] citadel.org branch, stable-78x, updated. c973c74dd07b010e70477d31ca325a8d7ba28190
Last call for bugfixes, otherwise I'm going to release 7.85 tomorrow in order to get the networking fix into people's hands.
[Citadel Development] Re: [SCM] citadel.org branch, stable-78x, updated. ecdc9e87a3ac4a50299291550c775cfcca783f34
The dialog is built in such a way that we can probably re-use most of it for other upload tasks. At the moment, I would like to focus on message entry. Rewriting the upload dialog wasn't actually what I started out trying to do. My goal was to eliminate all of the round-trips to the server during message composition. Originally I wanted to just add 'attach' fields to the form as they were needed, like GMail does, but it ended up looking very bad so I got the idea to do the popup dialog. Where I am going with this: The next step will be to perform a final validation on the message using ajax before submitting the entire message. If there are bad recipients or an access control problem, I want it to pop up an error. Only when everything is validated will the full message form finally be submitted to the server. The final goal is for the entire system to be usable without logging in. That's the main reason I added the modal dialog code last week.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. a70ac03ebc6c5de716f6ff71c1663fffe66c4fbe
Qte! realy Qute. I'd like to add one todo... could you add a throbber to the screen while its uploading the files on send? The one we also show while loading the messages list in the mbox view? Yes, that's definitely something for the TODO list. Right now the problem is that I don't have a low-bandwidth connection to test it. 25 Mbps via fiber to my house, uploads finish instantly no matter how big :)
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 4ba859fe5bed361aa7aa3b5a8c0b7c57d8ada1f4
have a look at that IG, its mostly what you did, plus wrap cunit around it... I wasn't familiar with CUnit so it's going to take me some time to figure everything out, but it looks like you simply changed my assert() calls to CUnit's equivalents, so yes, that's fine. I will use test_stripallbut.c as a template if I write any more unit tests. I like the idea of adding unit tests; perhaps in the future we can write some more that connect to citserver and do things like testing the IMAP service for accuracy etc.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. f7a17f83336a84d369f93fde2f164457a40616d9
I try to re-use localizations when I can. The string Attachments: was already in there.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 82a955f8397a6622d2e4ee11e0df8e83ddf44cfd
its supposed to find the last left boundary? The behavior of stripallbut() when multiple boundaries are found is *undefined*. However, my goal with this rewrite, aside from simplicity (and not crashing) was to attempt to find the innermost string, so we don't end up extracting a string that still has boundary characters in it. While repairing this function I wrote a test program that gave it every possible problem string I could think of. Since that work was already done, I took the liberty of adding it to the tests/ directory. I don't know how to integrate it into CUnit, though. So, how's the MIME parser fix coming along?
[Citadel Development] Re: MIME parser is broken
where do you see QP exactly? All I have to do is use WebCit to post a message in any room, and then read it. QP-encoding all over the place.
