[Citadel Development] (no subject)
Wed Sep 03 2014 07:51:50 EDT from Freakdog @ Dog Pound BBS II Tue Sep 02 2014 05:20:32 PM EDT from dothebart @ Uncensored I don't have any troubles with spool files, probably due to the single coredness of my server. If you have, you will have to provide more information so that we can fix this.WFM YMMV ;-) Hmm...I'm running my Citadel in a VirtualBox VM which has been allocated a single core. The underlying server is running a quad core CPU.I find that if I remove the offending spool file, the issue goes away...I can always identify the offending spool file, easily, as it's the largest spool file in the spoolout directory..continuing to grow but never sent/picked up. I haven't encountered it in quite a while, though. so if you re-sync a room this may happen to you? where does it break? in collectding? or sending? or does it break while collecting the spoolfiles with large attachments to the spoolfile to transmit?
[Citadel Development] (no subject)
Mon Sep 01 2014 03:20:13 AM EDT from dothebart @ Uncensored hm,the disk is full on startup case isn't caught at all in the db-layer... some pointers become NULL and we crash. Is this in response to my question about spool files? If so, the disk isn't full when the spool file issue crops up. If not, please ignore this message and carry on.
[Citadel Development] (no subject)
Tue Sep 02 2014 09:33:37 AM EDT from Freakdog @ Dog Pound BBS II Mon Sep 01 2014 03:20:13 AM EDT from dothebart @ Uncensored hm,the disk is full on startup case isn't caught at all in the db-layer... some pointers become NULL and we crash. Is this in response to my question about spool files? If so, the disk isn't full when the spool file issue crops up. If not, please ignore this message and carry on. Just read the Citadel Support room...so no, that was not in response to my question about spool files. D'oh!
[Citadel Development] (no subject)
Tue Sep 02 2014 09:33:37 EDT from Freakdog @ Dog Pound BBS II Mon Sep 01 2014 03:20:13 AM EDT from dothebart @ Uncensored hm,the disk is full on startup case isn't caught at all in the db-layer... some pointers become NULL and we crash. Is this in response to my question about spool files? If so, the disk isn't full when the spool file issue crops up. If not, please ignore this message and carry on. no, neither was. I don't have any troubles with spool files, probably due to the single coredness of my server. If you have, you will have to provide more information so that we can fix this.WFM YMMV ;-)
[Citadel Development] (no subject)
hm,the disk is full on startup case isn't caught at all in the db-layer... some pointers become NULL and we crash.
[Citadel Development] (no subject)
Wed Aug 06 2014 09:50:33 AM EDT from IGnatius T Foobar @ Uncensored Have I mentioned lately how wonderful it is that our Berkeley DB layer is so stable? How it almost never breaks because it's well tested, well tuned, and nobody's in there messing with it? Let's keep it that way. Silly question...will a fix for the "shutting down database" due to network spool files issue be seen in an upcoming release?
[Citadel Development] (no subject)
8.25? Now?
[Citadel Development] (no subject)
Ok folks, same question again -- What's unstable in git master right now? I would really like to get a major release done so I can start ripping out some of IGnet's guts.
[Citadel Development] (no subject)
Playing around on my phone right now and I just noticed that the browser in Android now works with WebCit. Nice!
[Citadel Development] (no subject)
btw, currently the xkcd room shows what happenes if any link is translated into a room name - the session is redirected to the lobby, messages are never marked read.
[Citadel Development] (no subject)
We currently would like to work towards either having two domains which are only able to send to each other (basically for the use that if one is down, the other will work). (Adding bennabiy to the access list for the room, for this discussion.) This is an interesting approach. I've never seen anyone use two separate domains for backup purposes. One of the reasons I want to abandon the federated global address book is because it's the source of the vast majority of addressability and reachability problems. Here are a few of the problems I've seen it create, in no particular order: * Changing the node name makes the entire address book invalid * People set up their local domains incorrectly * Changing a user's display name invalidates their address book entry If and when we abandon IGnet and the federated GAB, we can really really simplify the data model. Here's what I'm thinking: * All networking of Citadel-to-Citadel gets done with SMTP (for mail), NNTP (for rooms), and fully qualified domain names * Abandon IGnet, and abandon the short node name entirely * Now there's no need for any routing table; everything is done with DNS and NNTP * Global Address Book still exists, but the database built from it references users by number, not name Then -- we take everything still sitting in flat files, and move them into the database: * netconfigs (if we still need them at all) * citadel.config and citadel.control * room info files * user profiles (both text and photos) Once *everything* is in the database -- and unfortunately we may have to flag-day our XML export format once we do that -- it becomes a simple matter of database replication to run a pair of Citadel servers in active/standby failover configuration. From what I've seen, it seems that this is what most people *really* want.
[Citadel Development] (no subject)
Hello, Where are storage the mail that is sended? If the response is in the BBDD,¿How can you acces to this BBDD? Thank you very much.
[Citadel Development] (no subject)
Please phrase your question in the form of a question.
[Citadel Development] (no subject)
Ok folks, is there anything left in git master that would prevent us from moving towards a release on that track? I'm going to need to start working on some data model changes and would really like to get a new stable going.
[Citadel Development] (no subject)
Wed Feb 05 2014 09:52:52 EST from IGnatius T Foobar @ Uncensored Ok folks, is there anything left in git master that would prevent us from moving towards a release on that track? I'm going to need to start working on some data model changes and would really like to get a new stable going. I didn't have time yet to finalize work on xmpp (currently broken), and zlib streaming may be desired. however, thats not a big change which I don't give a huge chance to conflict with your changes, so we could cherrypick that over once its done.
[Citadel Development] (no subject)
Wait a minute -- xmpp is broken?
[Citadel Development] (no subject)
in master - yes. at least incomplete.
[Citadel Development] (no subject)
More broken than in stable, or incomplete as in there were things you wanted to add?
[Citadel Development] (no subject)
more broken than in stable.
[Citadel Development] (no subject)
Ok, fix pls :)
[Citadel Development] (no subject)
Wed Jan 22 2014 02:50:32 EST from dothebart @ Uncensored found fineuploader.com - GPLv3 if you build it yourself. that way I found out about nodejs, npm, grunt and all its tiny plugins they include minification and other stuff. Maybe we should add the ability for minification during building the dist-tarballs for webcit too. first files uploaded using that, seems nice. OK, Fineuploader fixes my upload issues and works nice. I hope to resolve one tiny issue, then we can cherrypick that over do a 8.24 release.
[Citadel Development] (no subject)
found fineuploader.com - GPLv3 if you build it yourself. that way I found out about nodejs, npm, grunt and all its tiny plugins they include minification and other stuff. Maybe we should add the ability for minification during building the dist-tarballs for webcit too. first files uploaded using that, seems nice.
[Citadel Development] (no subject)
so we have some troubles with our attachment uploading facility. if one has an nginx proxy, the upload will get interrupted after roughly 8k; regardless of https or not. This behaviour seems to be portable amongst chromium iceweasel Its even broken if one tries to upload files to uncensored, files no bigger 160k fail silently. i've tried http://paste.debian.net/76064/ as static.local/test.html do_template?template=test and tada, upload working. any ideas?
[Citadel Development] (no subject)
its still some work left to do - but not that much. I guess its forward-cherry-pickeable. 9.0 - yes that was also my Idea. or... start an 8.xx branch, where we will fork 8.3x from, and if needed maybe an 8.4x; depending on how fast you progress on the nntp hacking.
[Citadel Development] (no subject)
Ok then, let's consider 8.3X to be frozen. Please get in any remaining fixes that are needed, and let me know when we can begin doing the final QA for a release. I want to get the stable_83x branch going as soon as possible. But I don't want to have multiple stable branches open at the same time.
[Citadel Development] (no subject)
Mon Dec 30 2013 10:17:07 EST from IGnatius T Foobar @ Uncensored Our UI is starting to look dated again. I have some ideas, but I won't want to do anything that will conflict with the_mgt's rewrite. What's the status of that and how can we work around conflicts? It is a branch in git, just try it, it is called layout_rework. It works nice in the larger resolutions, but I have hit some quirks with Firefox, yes. Also, the small portrait mode resolutions on mobiles and my _javascript_ skills conflicted. I stopped when I dared to approach the minefield of Calendar, which still is so damn hardcoded html-in-C that it is a pain. We need template functions to call a week view, a day view, a tiny month view, etc etc. I guess the rest is merely just a exercise in tightening the html pages. The amazium (pure css) framework I use for the layout_rework branch does fit for 98% of our current way of doing things, but we would need to rethink some other parts to better fit into a grid idea. There are problems with the #content div and how it is created from C code in some cases. Give the current branch a quick glance, if you absolutely do not like what you see, I need to start over anyway.
[Citadel Development] (no subject)
By "it works nice" I mean: It is a partially working proof of concept for my ideas to unclutter the ui and make it responsive. There are lots of places were it simply is buggy and ugly, but I can use it to post to regular rooms, read the blogs, etc. the "Rooms" view is currently an epic fail, because I wanted to rip the tables out. We need to have the Rooms screen to adapt to small screensizes, therefore I wanted to read up on floating grids of variable heights. Seems there are more than 5 ways to do it and I got distracted then.
[Citadel Development] (no subject)
IG, I sugest you create 8.3x branch now if you start working on nntp - I need some stabilization work, then this would be due to a release.
[Citadel Development] (no subject)
dothebart: the more I think about it the more I want to go 9.00 for the emergence of NNTP (both for inter-Citadel networking and for Citadel-to-other networking) and the removal of IGnet. It's a big data model change. So my question is: how stable is git master right now? Can we freeze for an 8.3X track?
[Citadel Development] (no subject)
So took care of the migrate import scenario. Performance of old (buggy) version with my test data (some but not many big messages): time /usr/sbin/sendcommand -h /test migr import /var/tmp/*xmlsendcommand: started (pid=24356) connecting to Citadel server at /test/var/run/citadel/citadel-admin.socket200 potzblitz Citadel server ADMIN CONNECTION ready.migr import400 sock it to mesendcommand: processing ended.real 3m2.986suser 0m1.886ssys 0m15.951s Whether one uses Splice or not doesn't seem to be so important time ./citadel/sendcommand -w 5000 -h /test migr import /var/tmp/*xmlsendcommand: started (pid=7682) connecting to Citadel server at /test/var/run/citadel/citadel-admin.socket200 potzblitz Citadel server ADMIN CONNECTION ready.migr import400 sock it to mesendcommand: processing ended.real 2m14.315suser 0m0.010ssys 0m0.350s So we roughly save 25% real time. the sendcommand enhancement accounts from 17.8s - 0.36s it seems not to be so important whether one uses zerocopy (splice) or blockbuffered read/writing in our scenario.
[Citadel Development] (no subject)
hm, it seems as if after re-importing sieve scripts are not detected anymore - while still present so, somehow CtdlForEachMessage(MSGS_LAST, 1, NULL, SIEVECONFIG, NULL, get_sieve_config_backend, (void *)u );doesn't grab it anymore. currently sendcommand import is broken (by me) need more hacking on that.
[Citadel Development] (no subject)
Mon Dec 30 2013 10:17:07 EST from IGnatius T Foobar @ Uncensored Sun Dec 29 2013 06:14:53 AM EST from dothebart @ Uncensored To allow admins to fuzz with webcits renderers (i.e. for hardcore mailq maintenance, or inspecting user settings like sieve scripts) i've created this faq to hand out to those in citadel support http://www.citadel.org/doku.php/faq:troubleshooting:viewhack Our UI is starting to look dated again. I have some ideas, but I won't want to do anything that will conflict with the_mgt's rewrite. What's the status of that and how can we work around conflicts? maybe start fixing the_mgts firefox quirks?
[Citadel Development] (no subject)
Wow, that's an incredible speed improvement. Good job!
[Citadel Development] (no subject)
Sun Dec 29 2013 06:14:53 AM EST from dothebart @ Uncensored To allow admins to fuzz with webcits renderers (i.e. for hardcore mailq maintenance, or inspecting user settings like sieve scripts) i've created this faq to hand out to those in citadel support http://www.citadel.org/doku.php/faq:troubleshooting:viewhack Our UI is starting to look dated again. I have some ideas, but I won't want to do anything that will conflict with the_mgt's rewrite. What's the status of that and how can we work around conflicts?
[Citadel Development] (no subject)
To allow admins to fuzz with webcits renderers (i.e. for hardcore mailq maintenance, or inspecting user settings like sieve scripts) i've created this faq to hand out to those in citadel support http://www.citadel.org/doku.php/faq:troubleshooting:viewhack
[Citadel Development] (no subject)
Tue Dec 24 2013 07:03:27 EST from dothebart @ Uncensored
hm, it seems as somewhere in the migrate chain is a 4k limit which can be hit by the seen-records.
my hot guess right now is sendcommand.
Before:
time /usr/sbin/sendcommand migr export /tmp/blarg.dmp sendcommand: started (pid=29199) connecting to Citadel server at /var/run/citadel/citadel-admin.socket200 potzblitz Citadel server ADMIN CONNECTION ready.migr export100 Exporting all Citadel databases.sendcommand: processing ended.real 2m35.401suser 0m21.811ssys 2m5.756s
After:
time ./sendcommand MIGR export /tmp/out.dmpsendcommand: started (pid=29014) connecting to Citadel server at /var/run/citadel/citadel-admin.socket200 potzblitz Citadel server ADMIN CONNECTION ready.MIGR export100 Exporting all Citadel databases.sendcommand: processing ended.real 0m10.288suser 0m2.417ssys 0m1.823s
Plus it now doesn't cut overlong lines anymore.
The second place cutting overlong lines:
/* * Import begins here */void migr_do_import(void) { StrBuf *Buf; XML_Parser xp; int linelen; unbuffer_output(); Buf = NewStrBufPlain(NULL, SIZ); xp = XML_ParserCreate(NULL); if (!xp) { cprintf("%d Failed to create XML parser instance\n", ERROR+INTERNAL_ERROR); return; } XML_SetElementHandler(xp, migr_xml_start, migr_xml_end); XML_SetCharacterDataHandler(xp, migr_xml_chardata); CC-dont_term = 1; cprintf("%d sock it to me\n", SEND_LISTING); unbuffer_output(); while (CtdlClientGetLine(Buf) = 0 strcmp(ChrPtr(Buf), "000")) { linelen = StrLength(Buf); StrBufAppendBufPlain(Buf, HKEY("\n"), 0); if (server_shutting_down) break; // Should we break or return? if (linelen == 0) continue; XML_Parse(xp, ChrPtr(Buf), linelen, 0); } XML_Parse(xp, "", 0, 1); XML_ParserFree(xp); FreeStrBuf(Buf); rebuild_euid_index(); rebuild_usersbynumber(); CC-dont_term = 0;}
probably also gained speed next to being non-4k limited anymore.
[Citadel Development] (no subject)
hm, it seems as somewhere in the migrate chain is a 4k limit which can be hit by the seen-records. my hot guess right now is sendcommand.
[Citadel Development] (no subject)
Please take note: The tag 'v8.23' does contain 8.23, but due to an error on my part, it contains a version number of 8.22. I have deleted this tag. The tag 'v8.23-new' (1cc036dfd97eb78144040b27ade8662ea82a56cc) is the correctly numbered 8.23 release. Sorry for the inconvenience.
[Citadel Development] (no subject)
there are those of us, who believe that a 'byzantine syntax' is core concept of a wiki. while fancy html may offer the plethora of format options, this is advantage and disadvantage at once: - documents can wysiwyg look like the user wants it to - each document ends up looking individual, you end up with something looking like a turkish bazar. 'byzantine syntax' solves this; all documents have the same style. so, from now on, citadel will offer the choice; you may choose the roomtype 'wiki' as before to get the old behaviour Next to this, there is a new roomtype, which offers the very same wiki engine with a different document type: Markdown: http://daringfireball.net/projects/markdown/ while this is not a classic wiki syntax as i.e. known under wiki-creole, its a syntax gaining more and more ground due to the use on Github, Stack Overflow and various blog softwares. It also doesn't need any downmix for the textclient, since its pretty well plaintext readable. We display this by introducing a new mimetype renderer in msg_renderers.c for all documents of the type 'text/x-markdown'. While this would classicaly mean iso-8859-1 text, we assume this to be UTF-8. To make it clear, we add the proper encoding on saving. It however introduces two new dependencies: - Epic Editor http://epiceditor.com/ to aid the users during creation.( an alternative may be: http://code.google.com/p/pagedown/ ) - https://github.com/Orc/discount offers libmarkdown2, which seems to be pretty marture since its already available in debian oldstable. More about Markdown: http://en.wikipedia.org/wiki/Markdown
[Citadel Development] (no subject)
That being said, it is possible to actually use layout_rework, this message is posted from my webcit at home, running layout_rework. And I loove the looks. I also accidently made it flat uiish... The fonts alone make it more lovable for me.
[Citadel Development] (no subject)
I once wondered exactly the same, there was some odd rule on how to test pages with names not currently present in webcit. In any case, you need to restart webcit before it will read a new html file. There was something else about it, but I forgot. :( Be aware that hiding the options from the displayed html does not really disable them, they could be used with a correct url-
[Citadel Development] (no subject)
https://datatracker.ietf.org/doc/draft-saintandre-xmpp-tls/ xmpp tls to become mandatory? and.. http over xmpp? WTF? plus, seems they want to make xmpp the next gen mail transport layer?
[Citadel Development] (no subject)
a little hacking and wiresharking later, one can use http://camendesign.com/code/video_for_everybody/test.html to download videos with range request from the files store and play them in the browser. (download the html file, edit it, enter the room in another window, load the file from disk - video plays and is fastforwardeable) lets see whether this is able to work with attachments too, and how one could have transparent decrompression too.
[Citadel Development] (no subject)
Reading a little about HTTP 2.0 and SPDY, which seems destined to be a part of HTTP 2.0 [ http://www.chromium.org/spdy/spdy-whitepaper ] I'm not sure I want to implement this. We haven't even implemented all of the features of HTTP 1.1 in their entirety. It would seem that a more sensible implementation might be to do the following: 1. Regardless of operating mode, *always* use the /webcit (or perhaps /wc) prefix for every transaction (exceptions would be things like /dav of course) 2. Increase the number of protocol modes to three: HTTP, HTTPS, and FastCGI. This would give administrators a choice of running WebCit as a standalone web server (using HTTP 1.1 forever), or plugging it into any FastCGI-enabled web server. I know already that dothebart will be super happy about this idea. :) what do y'all think?
[Citadel Development] (no subject)
I like fastcgi. I don't know whether spdy will be worth the effort. it would realy be more important to be to be able to understand REST alike URL-schemes the like... DAV/floor/toplevel_room/subroom/messageid/attachmentID or something like that; plus being able to access files to download like that for using it in blogs; and... display GPS-Tracks on maps, and maybe being able to do Pseudo streaming with range requests (which would pe pretty easy for me right now, since I just did that at $company) which is usefull for HTML-5 video streaming. I started out on that a while ago, but got distracted. right now mobile IMAP-client support in the means of IMAP-Idle would be most important to me. Another thing hot on my todo list is finding out how to do nonblocking / libev supported client side SSL for the pop3 aggregator. Currently I'm doing a bunch of refactoring: - separating citadel protocol handlers from core message/room/etc. functionality into modules/ctdlproto/serv_*.c - reducing the includes to the minimum - replaced cm_fields['A'] by enums alike cm_fields[eAuthor] where eAuthor is defined to be 'A' - By that I found the bug that bouncing messages are being sent to the bounce message text instead of the author. It also enables one to read source code without cross-reading techdoc/hacktxt all the time to revalidate what it actualy does. As mentioned, backwards compatibility is ensured by defining the Enum values to their letters. - only use msgbase.c:CM_* functions to manipulate message fields (free'ing if already allocated, copying etc) makes the code more compact and better readable - since the CM_* migration now is finished, and was done with the idea in mind to supplement cm_fields[] with cm_lengths[] we now should gain performance by no more needing to strlen() the fields all over the place. - message saving to [network|mailque|notifyqueue] is done via api calls now once this stabilizes, we could release this as 8.30; it needs some more testing before I put it to outgesourced, but already is in pretty good shape.
[Citadel Development] (no subject)
but... again... HOW do you configure the floor expire policy using webcit? Hm, did the floor expire policy go missing during templatization? It's definitely configurable from the text client.
[Citadel Development] (no subject)
Tue Sep 17 2013 16:21:52 EDT from IGnatius T Foobar @ Uncensored but... again... HOW do you configure the floor expire policy using webcit? Hm, did the floor expire policy go missing during templatization? It's definitely configurable from the text client. either that, or was never implemented... however trying documenting it uncovered that the way the strings sugest it should work it can be made to work using webcit alone (imho) If I missed it, please point me to how it was implemented then - else I guess we'll have to implement it then.
[Citadel Development] (no subject)
Setting an expire policy for a floor full of RSS feeds is good; that's how we do it here. No sense in preserving that stuff for a long time. Until of course I forgot about that when we started *originating* blogs from here and I put my first one on that floor ... oops! That's why the Member Blogs floor has *no* expire policy.
[Citadel Development] (no subject)
Wed Sep 11 2013 07:35:07 EDT from IGnatius T Foobar @ Uncensored Setting an expire policy for a floor full of RSS feeds is good; that's how we do it here. No sense in preserving that stuff for a long time. Until of course I forgot about that when we started *originating* blogs from here and I put my first one on that floor ... oops! That's why the "Member Blogs" floor has *no* expire policy. but... again... HOW do you configure the floor expire policy using webcit?
[Citadel Development] (no subject)
Wed Sep 11 2013 09:14:06 AM EDT from dothebart @ Uncensored Wed Sep 11 2013 07:35:07 EDT from IGnatius T Foobar @ Uncensored Setting an expire policy for a floor full of RSS feeds is good; that's how we do it here. No sense in preserving that stuff for a long time. Until of course I forgot about that when we started *originating* blogs from here and I put my first one on that floor ... oops! That's why the "Member Blogs" floor has *no* expire policy. but... again... HOW do you configure the floor expire policy using webcit? I am not sure, but I think the floor expire policy gets set at creation time for the new floor. Not sure how you change it in Webcit (I think I usually do it in the text client - but I am not sure as I don't do it often).
[Citadel Development] (no subject)
so, I've written some faqs... http://www.citadel.org/doku.php/faq:everydayuse:rss_aggregation (since we've been ommitted with the RSS reader replacements for Google Reader in the latest linux Mag, I think we need to advertize the rss reader a little more?) and since message expiry is a usecase in there i've created and linked: http://www.citadel.org/doku.php/faq:systemadmin:how_do_i_expire_messages which put a big question mark on my head - how do I configure the floor message expiry? or is this just [personal folder / public folde] ? Or is some configuration interface missing in webcit here?
[Citadel Development] (no subject)
Tue Sep 10 2013 04:40:40 PM EDT from dothebart @ Uncensored so, I've written some faqs... http://www.citadel.org/doku.php/faq:everydayuse:rss_aggregation (since we've been ommitted with the RSS reader replacements for Google Reader in the latest linux Mag, I think we need to advertize the rss reader a little more?) and since message expiry is a usecase in there i've created and linked: http://www.citadel.org/doku.php/faq:systemadmin:how_do_i_expire_messages which put a big question mark on my head - how do I configure the floor message expiry? or is this just [personal folder / public folde] ? Or is some configuration interface missing in webcit here? Nope, I think you have it covered: Use the default policy for this floor Never automatically expire messages Expire by message count Expire by message age Number of messages or days: I have tweaked (not edge cases), the use floor policy vs expire count (not age), and it seems to work just fine (current easy install release). Ax25 P.S. I use the hell out of that thing as I pull in blog posts from many sources and even made a floor for rss feeds. One of my users did not like the sort order for the floor I named RSS feeds, so I re-named it XRSS feeds to keep it low on the list alphabetically.
[Citadel Development] (no subject)
Tue Sep 10 2013 22:24:10 EDT from ax25 @ Uncensored Ax25 P.S. I use the hell out of that thing as I pull in blog posts from many sources and even made a floor for rss feeds. One of my users did not like the sort order for the floor I named RSS feeds, so I re-named it XRSS feeds to keep it low on the list alphabetically. you can make them zap the rss rooms - I have similar problems. Imap on elderly wintendo tends to take ages with many rooms - even more if one isn't interested in the content. Question was - again - is there a way to configure a floor policy for each floor which webcit hasn't wrapped?
[Citadel Development] (no subject)
This weekend (in between stretches of the last frantic push to get my house ready to sell) I'm building a demo/test Exchange environment that I need in order to test the integration of third party spam filtering tools. To be sure, this is not a Citadel related project, but read on. Yes, I have an MCSE on my staff, but he only works on high visibility projects that make him look good to at least the next two levels of management. But this provided an opportunity for me to update my knowledge set, and my strength is as a tech-heavy manager who hasn't become ignorant of the inner workings of a technology infrastructure. And what I discovered is interesting. I've helped out with Exchange maintenance over the years but this was the first time I've done an Exchange install from scratch in more than a few years now. One of the inspirations for turning Citadel into a groupware/collaboration platform was that in the late 1990's when I was doing field service work, I was frustrated that the Unix world still provided a solid mail system but you had to be a genius to put it together, while Exchange 5.5 was a piece of garbage but it was easy to install -- you just popped the disc in, ran the install, and typed your domain name, and you were basically up and running. I knew we could do better than that, which is why my vision of Citadel being the easiest to install has always been a driving force behind the project. I didn't realize that at some point we not only achieved parity with Exchange on this, but that Exchange then took GIANT STEPS BACKWARDS in ease of installation. There's no such thing as an easy Exchange installation anymore. There's a giant list of prerequisites to put together in Active Directory. The installation has dozens of places where it can fail because you didn't prepare the system properly. Then it simply completes and gives you no instruction on what to do next. When you find the System Manager application, more often than not it fails to initialize and doesn't tell you why it couldn't connect to your organization. You have to go digging through the event log to figure out what went wrong. Then once you do connect, you have to manually create recipient policies, mailbox policies, send/receive connectors, and a bunch of other stuff that Citadel has ready for you right out of the box. Microsoft's attitude seems to be that if you're a large organization you should make use of an MC$E that paid megabucks for training, and if you're a small organization you should be using their cloud service instead of an on-premises (or on-private-cloud) server. So here we are, just as I suspected we were: we've got the small organization space available for takeover with very little effort. Keep up the good work, guys -- and let's dominate this.
[Citadel Development] (no subject)
afaik they discontinued their small business server line for the cloud services, which they put in place to stop linux invading the server rooms. I guess this was the easiest way to get a running exchange - and the other ones are only for big coorperations which need clusters etc. I guess a missing feature we currently have is the pgp integration..
[Citadel Development] (no subject)
You should see the way they've trained MCSE's to think. There's no longer any such thing as the Exchange server. They've trained MCSE's to push no fewer than *two* mailbox servers (in a redundant group) *plus* at least one dedicated front end (client access) server. Even if the organization has 100 users.
[Citadel Development] (no subject)
Jus tupgraded...will let you all know how I make out.
[Citadel Development] (no subject)
Ok, the tag v8.20 is now in the repository for the official 8.20 release, and source code tarballs are on the download site.
[Citadel Development] (no subject)
some try to get a hold on it...
however, it seems as if ld_preload changes offsets, need to find a way around this - so I can get usefull backtraces :-(
/*
* gcc -Wall -nostartfiles -fpic -shared -olibbacktrace.so backtrace_open.c
*/
#define _GNU_SOURCE
#define _FILE_OFFSET_BITS 64
#define _LARGEFILE_SOURCE
#include dlfcn.h
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
#include sys/types.h
#include sys/stat.h
#include assert.h
#include sys/mman.h
#include fcntl.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include errno.h
#include time.h
#include execinfo.h
/* XXX: do parallel support for open AND open64 by #undef open etc .. */
#define RESOLVE(x) if (!o_##x !(o_##x = dlsym(RTLD_NEXT, #x))) { fprintf(stderr, #x() not found!\n); exit(-1); }
#define min(x,y) ( (x)(y)?(x):(y) )
#define max(x,y) ( (x)(y)?(x):(y) )
#define N_FRAMES 16
/* XXX: need to handle this differently .. linked list? */
#define HIGHEST_FD 256
#define FEAT_RANGE_SUPPORT 1
static int (*o_open64)(const char *, int, ...);
static int (*o_close)(int);
static FILE *(*o_fopen64)(const char *, const char *);
static int (*o_fclose)(FILE *);
static int (*o_socket)(int domain, int type, int protocol);
static int (*o_connect)(int sockfd, const struct sockaddr *addr, socklen_t addrlen);
FILE *myfd = NULL;
void _init(void)
{
RESOLVE(fopen64);
/* CRASH! if you load us uninitialized, your process deserves to die! */
myfd = o_fopen64(getenv(DEBUG_FILENAME), w+);
fprintf(myfd, %d: my filedescriptor.\n, fileno(myfd));
}
void oneline_backtrace(const char* CallName, const char *str1, long nFD)
{
const long sizeofstr =
N_FRAMES *3 + // 0x,
sizeof(void*) * N_FRAMES * 4 + // hex number
256;
void *stack_frames[N_FRAMES];
char addresslist[sizeofstr];
size_t size, i;
long offset = 0;
offset = sprintf(addresslist, \n%ld: [%s][, nFD, CallName);
size = backtrace(stack_frames, sizeof(stack_frames) / sizeof(void*));
if (size 0)
{
if (N_FRAMES size)
size = N_FRAMES;
for (i = 1; i size; i++) {
offset += sprintf(addresslist + offset, %p;, stack_frames[i]);
}
}
offset += snprintf(addresslist + offset, sizeof(addresslist) - offset, ]\n\t%s,
str1);
fwrite(addresslist, 1, offset, myfd);
}
#define NUMBUFSIZE 60
static char numbuf[NUMBUFSIZE];
char *str_off_t(__off64_t t)
{
char *p=numbuf+sizeof(numbuf)-1;
int isneg=0;
if (t 0)
{
t= -t;
isneg=1;
}
*p=0;
do
{
*--p= '0' + (t % 10);
t=t / 10;
} while(t);
if (isneg)
*--p='-';
return p;
}
int open64(const char *pathname, int flag, ...)
{
int ret;
RESOLVE(open64);
ret = o_open64(pathname, flag);
oneline_backtrace (__FUNCTION__, pathname, ret);
return ret;
}
FILE *fopen64(const char *pathname, const char *mode)
{
FILE *Ret;
RESOLVE(fopen64);
Ret = o_fopen64(pathname, mode);
oneline_backtrace (__FUNCTION__, pathname, fileno(Ret));
return Ret;
}
int socket(int domain, int type, int protocol)
{
int ret;
char buf[128];
RESOLVE(socket);
ret = o_socket(domain, type, protocol);
snprintf(buf, sizeof(buf), t: %d p:%d %s,
type, protocol, strerror(errno));
oneline_backtrace (__FUNCTION__, buf, ret);
return ret;
}
int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
{
const char *what;
int ret;
RESOLVE(connect);
if (addrlen == sizeof(struct sockaddr_in6))
{
what = IPv6 ;
}
else if (addrlen == sizeof(struct sockaddr_in))
{
what = IPv4 ;
}
else
{
what = WTF? ;
}
ret = o_connect(sockfd, addr, addrlen);
oneline_backtrace (__FUNCTION__, what, sockfd);
return ret;
}
int close(int fd)
{
oneline_backtrace (__FUNCTION__, , fd);
RESOLVE(close);
return o_close(fd);
}
int fclose(FILE *stream)
{
int fd;
int ret;
fd = fileno(stream);
RESOLVE(fclose);
ret = o_fclose(stream);
oneline_backtrace (__FUNCTION__, strerror(errno), fd);
return ret;
}
[Citadel Development] (no subject)
Mon Aug 12 2013 05:17:50 AM EDT from dothebart @ Uncensored hm, somethings smelly around the network queue importer. it seems there is some sort of double close here (though I couldn't find it by browsing the source) and from sendcommand rwho I see something messing with the current room of running rss aggregators over here on uncensored, which also seems to be the networker? Probably time to give it its own context like all the other background jobs have? So, this is something still remaining? This appears to be what happens when the networker gets hung up in 8.16, and clears when I stop and restart citadel.
[Citadel Development] (no subject)
Tue Aug 13 2013 11:37:05 EDT from Freakdog @ Dog Pound BBS II Mon Aug 12 2013 05:17:50 AM EDT from dothebart @ Uncensored hm, somethings smelly around the network queue importer. it seems there is some sort of double close here (though I couldn't find it by browsing the source) and from sendcommand rwho I see something messing with the current room of running rss aggregators over here on uncensored, which also seems to be the networker? Probably time to give it its own context like all the other background jobs have? So, this is something still remaining? This appears to be what happens when the networker gets hung up in 8.16, and clears when I stop and restart citadel. for some reason yes. I've found fixed a similar problem with cURL the RSS-Aggregator which at least for my productive platform fixed the now and then appearing double close db panics. Howevery my dev system on my laptop oopsed again with no RSS-Aggregator being active.
[Citadel Development] (no subject)
ok, next version.
doing pretty well already; however it doesn't show all open system calls any hints which calls I should intercept also are welcome.
/*
* gcc -Wall -nostartfiles -fpic -shared -olibbacktrace.so backtrace_open.c
*/
#define _GNU_SOURCE
#define _FILE_OFFSET_BITS 64
#define _LARGEFILE_SOURCE
#include dlfcn.h
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
#include sys/types.h
#include sys/stat.h
#include assert.h
#include sys/mman.h
#include fcntl.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include errno.h
#include time.h
#include execinfo.h
/* XXX: do parallel support for open AND open64 by #undef open etc .. */
#define RESOLVE(x) if (!o_##x !(o_##x = dlsym(RTLD_NEXT, #x))) { fprintf(stderr, #x() not found!\n); exit(-1); }
#define min(x,y) ( (x)(y)?(x):(y) )
#define max(x,y) ( (x)(y)?(x):(y) )
#define N_FRAMES 50
/* XXX: need to handle this differently .. linked list? */
#define HIGHEST_FD 256
#define FEAT_RANGE_SUPPORT 1
static int (*o_open64)(const char *, int, ...);
static int (*o_close)(int);
static FILE *(*o_fopen64)(const char *, const char *);
static FILE *(*o_fdopen)(int fd, const char *mode);
static int (*o_fclose)(FILE *);
static int (*o_socket)(int domain, int type, int protocol);
static int (*o_connect)(int sockfd, const struct sockaddr *addr, socklen_t addrlen);
FILE *myfd = NULL;
void _init(void)
{
RESOLVE(fopen64);
RESOLVE(open64);
RESOLVE(fdopen);
RESOLVE(socket);
RESOLVE(connect);
RESOLVE(fopen64);
RESOLVE(close);
RESOLVE(fclose);
/* CRASH! if you load us uninitialized, your process deserves to die! */
myfd = o_fopen64(getenv(DEBUG_FILENAME), a+);
fprintf(myfd, %d: my filedescriptor.\n, fileno(myfd));
fprintf(myfd, %d: my pid\n, getpid());
}
void oneline_backtrace(const char* CallName, const char *str1, long nFD)
{
static const long sizeofstr =
N_FRAMES *3 + // 0x,
sizeof(void*) * N_FRAMES * 4 + // hex number
N_FRAMES * 64 + // function string version
256;
void *stack_frames[N_FRAMES];
char addresslist[sizeofstr];
size_t size, i;
long offset = 0;
char **strings;
addresslist [0] = '\0';
// fprintf(myfd, \n%ld: [, nFD);
// fprintf(myfd, \n%s: [, CallName);
offset = sprintf(addresslist, \n%ld: [%s][, nFD, CallName);
size = backtrace(stack_frames, sizeof(stack_frames) / sizeof(void*));
/// fprintf(myfd, \n%ld: [, size);
strings = backtrace_symbols(stack_frames, size);
if (size 0)
{
if (N_FRAMES size)
size = N_FRAMES;
// skip first two frames, its just us.
for (i = 2; i size; i++) {
// fprintf(myfd, \t%ld - %p\n, i, strings[i]);
if ((strings != NULL) (strings[i] != NULL))
{
//fprintf(myfd, \t%s\n, strings[i]);
offset += snprintf(addresslist + offset, sizeofstr - offset, \t%s\n, strings[i]);
}
else
{
//fprintf(myfd, %p;, stack_frames[i]);
offset += snprintf(addresslist + offset, sizeofstr - offset, %p;, stack_frames[i]);
}
if (sizeofstr offset + 64)
break;
}
}
offset += snprintf(addresslist + offset, sizeofstr - offset, ]\n\t%s,
str1);
fwrite(addresslist, 1, offset, myfd);
}
int open64(const char *pathname, int flag, ...)
{
int ret;
ret = o_open64(pathname, flag);
oneline_backtrace (__FUNCTION__, pathname, ret);
return ret;
}
FILE *fopen64(const char *pathname, const char *mode)
{
FILE *Ret;
Ret = o_fopen64(pathname, mode);
oneline_backtrace (__FUNCTION__, pathname, fileno(Ret));
return Ret;
}
FILE *fdopen(int fd, const char *mode)
{
FILE *Ret;
Ret = o_fdopen(fd, mode);
oneline_backtrace (__FUNCTION__, mode, fd);
return Ret;
}
int socket(int domain, int type, int protocol)
{
int ret;
char buf[128];
ret = o_socket(domain, type, protocol);
snprintf(buf, sizeof(buf), t: %d p:%d %s,
type, protocol, strerror(errno));
oneline_backtrace (__FUNCTION__, buf, ret);
return ret;
}
int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
{
char what[64];
char netbuf[64];
int ret;
if (addrlen == sizeof(struct sockaddr_in6))
{
inet_ntop(AF_INET6,
addr,
netbuf,
sizeof(netbuf));
sprintf(what, ipv6[%s], netbuf);
}
else if (addrlen == sizeof(struct sockaddr_in))
{
inet_ntop(AF_INET,
addr,
netbuf,
sizeof(netbuf));
sprintf(what, ipv4[%s], netbuf);
}
else
{
sprintf(what, WTF? neither ipv4 nor 6? );
}
ret = o_connect(sockfd, addr, addrlen);
oneline_backtrace (__FUNCTION__, what, sockfd);
return ret;
}
int close(int fd)
{
oneline_backtrace (__FUNCTION__, , fd);
return o_close(fd);
}
int fclose(FILE *stream)
{
int fd;
int ret;
fd = fileno(stream);
ret = o_fclose(stream);
oneline_backtrace (__FUNCTION__, strerror(errno), fd);
return ret;
}
[Citadel Development] (no subject)
hm, somethings smelly around the network queue importer. it seems there is some sort of double close here (though I couldn't find it by browsing the source) and from sendcommand rwho I see something messing with the current room of running rss aggregators over here on uncensored, which also seems to be the networker? Probably time to give it its own context like all the other background jobs have?
[Citadel Development] (no subject)
Fri Jul 19 2013 15:56:07 EDT from IGnatius T Foobar @ Uncensored
Jul 19 2013 3:15pm from Citadel Subject: RSS Aggregation run failure Error while RSS-Aggregation Run of http://deutschesteffi.blogspot.com/feeds/posts/default need a 200, got a 0 ! Curl Error message: Operation too slow. Less than 64 bytes/sec transferred the last 600 seconds / Timeout was reached Response text was: GOTO _BASEROOM_
There's gotta be something wrong in there. Uninitialized buffer maybe?
our gateway to curl:
static size_tgotdata(void *data, size_t size, size_t nmemb, void *cglobal){ AsyncIO *IO = (AsyncIO*) cglobal; SetEVState(IO, eCurlGotData); if (IO-HttpReq.ReplyData == NULL) { IO-HttpReq.ReplyData = NewStrBufPlain(NULL, SIZ); } IO-Now = ev_now(event_base); return CurlFillStrBuf_callback(data, size, nmemb, IO-HttpReq.ReplyData);}
size_t CurlFillStrBuf_callback(void *ptr, size_t size, size_t nmemb, void *stream){ StrBuf *Target; Target = stream; if (ptr == NULL) return 0; StrBufAppendBufPlain(Target, ptr, size * nmemb, 0); return size * nmemb;}
so... its gotta be cURL that gives us uninitialized data in case of errors...
only possible solution is to skip the reply buffer from the error message, which may contain usefull informations in other cases...
[Citadel Development] (no subject)
ok, did everything for 8.17 - debbuild triggered. Please upgrade the dist, we can release 8.20 on monday then.
[Citadel Development] (no subject)
Jul 19 2013 3:15pm from Citadel Subject: RSS Aggregation run failure Error while RSS-Aggregation Run of http://deutschesteffi.blogspot.com/feeds/posts/default need a 200, got a 0 ! Curl Error message: Operation too slow. Less than 64 bytes/sec transferred the last 600 seconds / Timeout was reached Response text was: GOTO _BASEROOM_ There's gotta be something wrong in there. Uninitialized buffer maybe?
[Citadel Development] (no subject)
Thu Jul 11 2013 12:42:21 EDT from IGnatius T Foobar @ Uncensored Or we could just release 8.20, what's stopping us? hm, we need to disable the experimental ical code in webcit. Sorry, weeks are flying by and quality hacking time is next to NIL.
[Citadel Development] (no subject)
Thu Jul 11 2013 06:35:09 EDT from dothebart @ Uncensored Wed Jul 10 2013 21:09:27 EDT from IGnatius T Foobar @ Uncensored Ok, fixed. StrBufStripAllBut() now returns the leftmost qualifying substring. did you check whether there are other places which might not like that behaviour? 8.1x-next now? (cherry pick the last two commits over - webcit vcard fix plus yours) StrBufStripAllBut(sSMTP-from, '', ''); StrBufStripAllBut(sSMTP-OneRcpt, '', '');./citadel/modules/smtp/serv_smtp.c StrBufStripAllBut(section, '[', ']'); StrBufStripAllBut(partial, '', '');./citadel/modules/imap/imap_fetch.c I still don't think thats a clever solution to change the methods way of working - i'd rather add a new function with another name for this.
[Citadel Development] (no subject)
The previous behavior was not "rightmost" but rather "undefined" -- in other words, it was used in places where there was an assumption that there would never be more than one qualifying substring on the line. That having been said, I did test the IMAP parser again, which is where these other calls are made, and it does seem to work properly.
[Citadel Development] (no subject)
Queasy Install has been updated: * It now delivers Berkeley DB 5.1 instead of the old 4.1 (I'm looking forward to DB 6 because it's released under the AGPL, for once Oracle did something right ... but it hasn't been tested with Citadel yet) * The text mode client is now built and delivered When the 8.20 release goes gold, deployment strategy will be to simply copy the Queasy Install site to the Easy Install site, and change the name and URL. Now for the big question: are there any release stopping bugs still in git master? I am ready for an 8.20 release. (I don't want to do another 8.1X release. If any package maintainers want to stay on that track they will be responsible as maintainers. I am upstream.)
[Citadel Development] (no subject)
Wed Jul 10 2013 21:09:27 EDT from IGnatius T Foobar @ Uncensored Ok, fixed. StrBufStripAllBut() now returns the leftmost qualifying substring. did you check whether there are other places which might not like that behaviour? 8.1x-next now? (cherry pick the last two commits over - webcit vcard fix plus yours)
[Citadel Development] (no subject)
Or we could just release 8.20, what's stopping us?
[Citadel Development] (no subject)
i'd like to have another stable release with the latest bunch of bugfixes without eventualy introducing new ones. I think its also better to provide that to distros and users conservative about upgrades. 8.20 also means some more work because of the citadel text client now is going to be its own tarball.
[Citadel Development] (no subject)
All right, backport what you want, tag it, and I'll put it up for download.
[Citadel Development] (no subject)
Ok, fixed. StrBufStripAllBut() now returns the leftmost qualifying substring.
[Citadel Development] (no subject)
Mon Jul 08 2013 13:57:39 EDT from IGnatius T Foobar @ Uncensored SHOW STOPPING BUG. This may explain why I've been losing so much mail (and why my wife got a GMail account, and my mother in law got a Yahoo account) ... MAIL FROM:nore...@microcenter.com SIZE=17697 AUTH= BODY=7BIT WTF?!?!?!?!?! what sort of mta is this? is it legal?
[Citadel Development] (no subject)
It's questionable whether that sort of behavior is legal. RFC 2821 doesn't say anything about it other than the fact that parameters are acceptable on the MAIL FROM: line. I can't find any mention of an AUTH= parameter anywhere. As far as I can tell this is some sort of weird M$ thing that is now leaking out onto the Internet, so I guess we've got to deal with it. In the absence of any real instruction it seems that the correct thing to do is to always parse the leftmost string in angle brackets following MAIL FROM: as the envelope sender address.
[Citadel Development] (no subject)
SHOW STOPPING BUG. This may explain why I've been losing so much mail (and why my wife got a GMail account, and my mother in law got a Yahoo account) ... 220 uncensored.citadel.org ESMTP Citadel server ready. EHLO hoexcas03.ad.microcenter.com 250-Hello hoexcas03.ad.microcenter.com (webmail.ad.microcenter.com [66.194.187.100]) 250-HELP 250-SIZE 1500 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250 8BITMIME MAIL FROM:nore...@microcenter.com SIZE=17697 AUTH= BODY=7BIT 550 You must log in to send mail from uncnsrd QUIT 221 Goodbye... WTF?!?!?!?!?!
[Citadel Development] (no subject)
Ok, looks like it's the AUTH= that's confusing it. stripallbut('','')
is grabbing the second set of angle brackets instead of the first. We never
guaranteed a specific behavior when more than one substring qualifies. Empty
address means an empty node name, empty node name is replaced with ours, ours
is parsed as a spoof.
[Citadel Development] (no subject)
hm, after a report that the browser locale detection may go haywire if the locale is not on the on the list and you end up with russian or chinese, I first touched that code again after 8 years. like time travel ;-) the C now also is en_US - which should be more intuitive to the users.
[Citadel Development] (no subject)
Thu Apr 11 2013 22:11:21 EDT from IGnatius T Foobar @ Uncensored Except I can't get it to work at all. It won't accept my username/password, it won't let me create a new account, and OpenID login doesn't seem to be operable. check out http://dev.citadel.org (I'm looking at it with chrome) hm, I don't see this effect over here - should do_template require http based authentication in first place? I guess there is something else wrong. That typo which I just committed just ommits the template with the login dialog, so this is a completely different thing. I see a cookie in the request... so why? Maybe you should have another look at the conditions of your system?
[Citadel Development] (no subject)
Does your patch implement a page change rather than a js modal?
[Citadel Development] (no subject)
the patch does 3fold: - fix the js not to do things which are unneccesary and some browsers seem to not understand properly (have a function pointer in place instead of simply declaring a function) - put the login dialog hidden into the header if one is not logged in, and let the .js simply uncover it once the user clicks / calls the .js function (which had a typo, so the dialog text would allways be there...) - so the login js doesn't load this login.html anymore - saves an http request. the symptoms of your system is to send an HTTP 401 to do_template, which it definitely shouldn't. if you use i.e. teh firebug or its chrome equivalent (F12...) you see that the pop brings you the regular logged in page as it should (in advance to the 401) so... you need to find out why the 401 comes. maybe its session missmatch or some citserver communication issue...
[Citadel Development] (no subject)
Except I can't get it to work at all. It won't accept my username/password, it won't let me create a new account, and OpenID login doesn't seem to be operable. check out http://dev.citadel.org (I'm looking at it with chrome)
[Citadel Development] (no subject)
commit 66b37caa8621e2e78c61b44acef3653fdfdc1192Author: Wilfried Goesgens dotheb...@citadel.orgDate: Sun Mar 31 13:52:02 2013 +0200 Rework Login dialog to work with rekonq (and hopefully Safari) - modal.js: don't use a function pointer - simply name the function as the pointer. - head.html: if we're not logged in, we add the login dialog to the page; its hidden anyways. - login.html: since we get printed into existing pages, we don't need htmlbody - its wrong in first place to have them. - authmethods.js: GetLoggedInFirst(): we don't need to send an ajax request to retrieve the login mask; if its needed, head.html already contains it. Simply uncover it to the user. so now we have login.html in the pages if the user is not logged in. what exactly would now be the usefullness of the push infrastructure over adding a hidden post field to login.html and filling that with GetLoggedInFirst()? just to KISS?
[Citadel Development] (no subject)
Sun Mar 31 2013 08:00:48 EDT from dothebart @ Uncensored commit 66b37caa8621e2e78c61b44acef3653fdfdc1192Author: Wilfried Goesgens dotheb...@citadel.orgDate: Sun Mar 31 13:52:02 2013 +0200 Rework Login dialog to work with rekonq (and hopefully Safari) - modal.js: don't use a function pointer - simply name the function as the pointer. - head.html: if we're not logged in, we add the login dialog to the page; its hidden anyways. - login.html: since we get printed into existing pages, we don't need htmlbody - its wrong in first place to have them. - authmethods.js: GetLoggedInFirst(): we don't need to send an ajax request to retrieve the login mask; if its needed, head.html already contains it. Simply uncover it to the user. so now we have login.html in the pages if the user is not logged in. what exactly would now be the usefullness of the push infrastructure over adding a hidden post field to login.html and filling that with GetLoggedInFirst()? just to KISS? nice side effect: passvoid autocompletion from browser memory works again.
[Citadel Development] (no subject)
ok, I think i've found the problem with the webcit login in rekonq (and most probably apple safari?) ;
changing in modal.jsvar toggleModal = function (b) {
to:
function toggleModal (b) {
seems to fix the problem.
next questions... why do we need to load the page (get_logged_in.html) in a second call? can't we just put it in there?
and if, why does it have extra htmlbody/body/html if its put into the DOM?
[Citadel Development] (no subject)
The purpose of get_logged_in is to display the login dialog and then take the user to the page he requested.
[Citadel Development] (no subject)
get_logged_in.html _is_ the login dialog, and nothing more. GetLoggedInFirst() loads it, and inserts it into the page; I've found no place in which get_logged_in would be viewed as toplevel page - so the html wrappers are most probably wrong? next - whats the sense in having a function pointer in toggleModal instead of having a function by that name? Since it seems not to be working in some browsers...
[Citadel Development] (no subject)
I would give you instructions on how to do so, but by posting a support request in the developers forum you have clearly demonstrated that you do not know how to follow instructions, so I'm not going to bother.
[Citadel Development] (no subject)
citadel and names in outlook and other mail programs '[Log in to get rid of this advertisement] Hi,I am using citadel to handle my mail, and I want the name from the client E.G. Michael Taboada to replace the person's user name.For example, if I have a user called person, and they're real name is Michael Taboada, and their name is set that way in their client, the mail in other people's inboxes still shows person, instead of Michael Taboada.This applies to all inboxes sent to, not just other citadel users.Any help is appreciated.
[Citadel Development] (no subject)
I've noted two things, today, that might merit being looked at: 1) The Human readable node name is limited to 20 characters. Doesn't affect me, much, but a new node came online that wanted to have a name that was 21 characters, and that last character is dropped. 2) When using the refresh option in a room's sharing options, in order to catch a remote node up with that room's content, I've noticed that the messages are imported (and I assume exported...I didn't look at the spool file) in newest to oldest order. In other words, messages that were received by my system yesterday or today, show up on the new/remote node in the First screen full of messages, and the oldest messages not purged from my system show up in the last screen full of messages. I'm thinking that we would want those messages to be exported/imported in the same order in which they were sent.
[Citadel Development] (no subject)
fyi -- I have tagged v8.16
[Citadel Development] (no subject)
citserver[7336]: nothing to do for Global Address Book citserver[7336]: nothing to do for edit me please citserver[7336]: nothing to do for Digg citserver[7336]: nothing to do for 09.Al Kaboom Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb71ffb70 (LWP 7341)] 0x080af3fa in DeletePOP3Aggregator (vptr=0x8282990) at modules/pop3client/serv_pop3client.c:202 202 ((struct CitContext*)ptr-IO.CitContext)-state = CON_IDLE; (gdb) bt #0 0x080af3fa in DeletePOP3Aggregator (vptr=0x8282990) at modules/pop3client/serv_pop3client.c:202 #1 0xb7d82e4d in DeleteHashPayload (Data=optimized out) at lib/hash.c:322 #2 0xb7d837cc in Put (Hash=0x827ea68, HKey=0x8283758 pop3://test:passw...@pop.mailinator.com/09.Al%20Kaboom, HKLen=62, Data=0x8283178, DeleteIt=0x80af350 DeletePOP3Aggregator) at lib/hash.c:698 #3 0x080af7b8 in pop3client_scan_room (OneRNCFG=0x8288328, qrbuf=0xb71ff110, data=optimized out) at modules/pop3client/serv_pop3client.c:1078 #4 pop3client_scan_room (qrbuf=0xb71ff110, data=0x0, OneRNCFG=0x8288328) at modules/pop3client/serv_pop3client.c:986 #5 0x08065f8d in CtdlForEachNetCfgRoom (CB=0x80af4d0 pop3client_scan_room, in_data=0x0, filter=pop3client) at room_ops.c:618 #6 0x080b060e in pop3client_scan () at modules/pop3client/serv_pop3client.c:1123 #7 pop3client_scan () at modules/pop3client/serv_pop3client.c:1090 #8 0x0805f5fb in PerformSessionHooks (EventType=50) at serv_extensions.c:1332 #9 0x08076e33 in do_housekeeping () at housekeeping.c:155 #10 0x0805d219 in worker_thread (blah=0x0) at sysdep.c:1355 #11 0x0807b190 in CTC_backend (supplied_start_routine=0x805d0c0) at threads.c:152 #12 0xb7d64c39 in start_thread () from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 #13 0xb79d992e in clone () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 Backtrace stopped: Not enough registers or memory available to unwind further
[Citadel Development] (no subject)
Jan 4 14:08:21 prod citserver[26786]: SMTPCQ: processing outbound queue Jan 4 14:08:21 prod citserver[26786]: SMTPCQ: smtp_do_procmsg(3375193) Jan 4 14:08:21 prod citserver[26786]: EVCURL:IO[12620]CC[62879] error description: The requested URL returned error: 404 Jan 4 14:08:21 prod citserver[26786]: EVCURL:IO[12620]CC[62879] error performing request: HTTP response code said error Jan 4 14:08:21 prod citserver[26786]: IO[12620]CC[62879][252368]RSSneed a 200, got a 404 ! Jan 4 14:08:21 prod citserver[26786]: not sending message again Jan 4 14:08:21 prod citserver[26786]: DB: seek: 1818125: (0 * 0) + 1818125: Illegal seek Jan 4 14:08:21 prod citserver[26786]: DB: seek: 1818125: (0 * 0) + 1818125: Illegal seek Jan 4 14:08:21 prod citserver[26786]: bdb(): txn_commit: Illegal seek Jan 4 14:08:21 prod citserver[26786]: citserver is stopping in order to prevent data loss. uid=100 gid=101 euid=100 egid=101
[Citadel Development] (no subject)
Fri Jan 04 2013 14:47:05 EST from IGnatius T Foobar @ Uncensored Jan 4 14:08:21 prod citserver[26786]: SMTPCQ: processing outbound queue Jan 4 14:08:21 prod citserver[26786]: SMTPCQ: smtp_do_procmsg(3375193) Jan 4 14:08:21 prod citserver[26786]: EVCURL:IO[12620]CC[62879] error description: The requested URL returned error: 404 Jan 4 14:08:21 prod citserver[26786]: EVCURL:IO[12620]CC[62879] error performing request: HTTP response code said error Jan 4 14:08:21 prod citserver[26786]: IO[12620]CC[62879][252368]RSSneed a 200, got a 404 ! Jan 4 14:08:21 prod citserver[26786]: not sending message again Jan 4 14:08:21 prod citserver[26786]: DB: seek: 1818125: (0 * 0) + 1818125: Illegal seek Jan 4 14:08:21 prod citserver[26786]: DB: seek: 1818125: (0 * 0) + 1818125: Illegal seek Jan 4 14:08:21 prod citserver[26786]: bdb(): txn_commit: Illegal seek Jan 4 14:08:21 prod citserver[26786]: citserver is stopping in order to prevent data loss. uid=100 gid=101 euid=100 egid=101 please install a backtrace enabled binary so we can see where this error is triggered from
[Citadel Development] (no subject)
For the record, IT'S NOT MY FAULT.
[Citadel Development] (no subject)
ok, f81a5a37a8c492f1061c8cca886d820acc9e3fb6 hopefully overcomes the good old challenge 'with which alias did I subscribe to that mailinglist?'
[Citadel Development] (no subject)
Queasy Install (updated from git master) does not build: In file included from utils/aidepost.c:26: /snprintf.h:5: error: expected declaration specifiers or '...' before 'va_list' /snprintf.h:5: error: conflicting types for 'vsnprintf' make: *** [utils/aidepost.o] Error 1 Operating system: Linux Debian 6.0.4 ( 2.6.32-5-686 i686)
[Citadel Development] (no subject)
does it define HAVE_SNPRINTF ? at least over here its not'and its compiling fine. do we need our own snprintf implementation in first place? Sat Nov 17 2012 12:46:49 EST from IGnatius T Foobar @ Uncensored Queasy Install (updated from git master) does not build: In file included from utils/aidepost.c:26: ./snprintf.h:5: error: expected declaration specifiers or '...' before 'va_list' ./snprintf.h:5: error: conflicting types for 'vsnprintf' make: *** [utils/aidepost.o] Error 1 Operating system: Linux Debian 6.0.4 ( 2.6.32-5-686 i686)
