Re: [Citadel Development] (no subject)

so either ldap:uid=blah,dc=base,dc=name or some uid which (already) exists anyway in the system?   I just wonder if there would be more confusion if someone switched their LDAP basename etc on a running system if the full DN is used... even if the users are the same, would their mail store

Re: [Citadel Development] (no subject)

is used... even if the users are the same, would their mail store disappear?     > Sat Oct 28 2017 12:54:33 AM EDT from IGnatius T Foobar @ Uncensored >Subject: Re: [Citadel Development] (no subject) > > >Ok, getting back to LDAP Sync. This opened a big can of worms

Re: [Citadel Development] (no subject)

Ok, getting back to LDAP Sync. This opened a big can of worms but it's going to end up a lot cleaner. Currently we map LDAP entries to Citadel accounts by using (or deriving) a uid, and then passing that through the same way we would if we were using Unix authentication. This requires a

Re: [Citadel Development] (no subject)

Grr. In addition to OpenSSL, the new Debian also brings along libical2, which has an API change which is neither forward nor backward compatible.

Re: [Citadel Development] (no subject)

ummm ... It looks like the patch submitted by a user back in August, in commit e42596a94e31ac9f5106f62d83dc56ddbd779b6a , may have already fixed the libssl issue. I'm going to investigate some more!

Re: [Citadel Development] (no subject)

! > Fri Oct 20 2017 04:48:25 PM EDT from IGnatius T Foobar @ Uncensored >Subject: Re: [Citadel Development] (no subject) > > >>Seems the temporary solution would be to put libssl1.0-dev as a >>requirement > > >>instead of libssl-dev until

Re: [Citadel Development] (no subject)

>Seems the temporary solution would be to put libssl1.0-dev as a requirement >instead of libssl-dev until the code is updated for the 1.1 api. Actually it seems that you've done the hardest part of the work already, by helping to arrive at the likely root cause: that something in

Re: [Citadel Development] (no subject)

Seems the temporary solution would be to put libssl1.0-dev as a requirement instead of libssl-dev until the code is updated for the 1.1 api. > Thu Oct 19 2017 04:11:40 PM EDT from "Robert J. Clay" <rjc...@gmail.com> >Subject: Re: [Citadel Development] (no subject) >

[Citadel Development] (no subject)

That was my impression as well. I wonder if there is a package conflict with some other dev packages which provide the same files as libssl-dev which when give the right combo produce broken ssl compile? > Thu Oct 19 2017 01:47:17 PM EDT from IGnatius T Foobar @ Uncensored > >Some are

[Citadel Development] (no subject)

 That is funny, because one of the people said they had that library, and still failed. Good to know it works. > Mon Oct 16 2017 03:43:52 PM EDT from IGnatius T Foobar @ Uncensored > >sheesh ... all of those people having trouble building Citadel using >Easy Install simply didn't have the

[Citadel Development] (no subject)

sheesh ... all of those people having trouble building Citadel using Easy Install simply didn't have the zlib dev package installed. So there's nothing to "fix" which is good. I've added "zlib1g-dev" to the install process shown on the web site, and I suppose if zlib is a requirement now I'll

[Citadel Development] (no subject)

Great. I've got a busy couple of days at work right now, but as much as I can I'm going to work on the change from LDAP "access" to LDAP "sync" , and also do some test building/fixing in the Debian Stretch VM that I built over the weekend.

[Citadel Development] (no subject)

We have entries! Must have been the log level by default is turned down to not show that level. > Sun Oct 15 2017 03:22:50 PM EDT from bennabiy @ Uncensored > > > >will try to see if it makes a difference > >  >> Sun Oct 15 2017 03:12:18 PM EDT from IGnatius T Foobar @ Uncensored >>

[Citadel Development] (no subject)

will try to see if it makes a difference   > Sun Oct 15 2017 03:12:18 PM EDT from IGnatius T Foobar @ Uncensored > > >>Is it possible that I need to enable some form of logging more than by > > >>default in order to see the entries? All I see is the ldap: populating > >

[Citadel Development] (no subject)

>Is it possible that I need to enable some form of logging more than by >default in order to see the entries? All I see is the ldap: populating >Citadel user database from LDAP If your'e running citserver in the foreground, you can do "citserver -x9" for maximum logging to the

[Citadel Development] (no subject)

Is it possible that I need to enable some form of logging more than by default in order to see the entries? All I see is the ldap: populating Citadel user database from LDAP > Sat Oct 14 2017 02:51:12 PM EDT from IGnatius T Foobar @ Uncensored > > >bennabiy : I know you're not on right now

[Citadel Development] (no subject)

Oct 15 02:27:38 cit citserver[59797]: ldap: populating Citadel user database from LDAP Oct 15 02:28:39 cit citserver[59797]: ldap: populating Citadel user database from LDAP   Oct 15 02:29:40 cit citserver[59797]: ldap: populating Citadel user database from LDAP   no listing yet. 

[Citadel Development] (no subject)

Great! I will get the recompile going and let you know (probably tomorrow) :) > Sat Oct 14 2017 02:51:12 PM EDT from IGnatius T Foobar @ Uncensored > > >bennabiy : I know you're not on right now because it's Saturday and also >you're busy with the new baby, but if and when you have some

[Citadel Development] (no subject)

bennabiy : I know you're not on right now because it's Saturday and also you're busy with the new baby, but if and when you have some time to tinker ... I tinkered with the LDAP Sync code a bit today (and that's what we're going to do now -- think of it as LDAP Sync rather than just "using"

[Citadel Development] (no subject)

Ig, I had a funny dream about you last night.  Any progress?

[Citadel Development] (no subject)

Ok, the funeral was today, so I'm getting back into the project now. I'm currently erasing the database on my development system and rebuilding it with LDAP pointing at my directory server. I was running standalone for the previous development cycle.

[Citadel Development] (no subject)

Ouch, I understand how that goes... Let me know when you are able to get back to it.  > Thu Sep 07 2017 10:22:23 PM EDT from IGnatius T Foobar @ Uncensored > >Still working on it. When it rains it pours. I got pulled into >"assisting" with something that took three entire business days

[Citadel Development] (no subject)

Still working on it. When it rains it pours. I got pulled into "assisting" with something that took three entire business days plus an overnight maintenance window. And now my grandmother has died and we're putting together funeral arrangements. *grml*

[Citadel Development] (no subject)

Update? 

[Citadel Development] (no subject)

Agreed :) And they don't stay little for long...  > Mon Aug 21 2017 06:57:08 PM EDT from IGnatius T Foobar @ Uncensored > >Ok then, family first. Little girls are always a higher priority than >computers. >ALWAYS. > > > >  

[Citadel Development] (no subject)

Ok then, family first. Little girls are always a higher priority than computers. ALWAYS.

[Citadel Development] (no subject)

My wife was sick tonight, so I had all my girls with me... Final transfer will be Tuesday night (I am at our deli all night tomorrow)     > Fri Aug 18 2017 06:31:12 PM EDT from IGnatius T Foobar @ Uncensored > > >>I would assume it's the same issue I dealt with: blood pools in the

[Citadel Development] (no subject)

Ok, so I have been doing repeated IMAPcopies waiting for tonight when I will shut down the server, do the final copy over. I will still have the old database intact on the previous instance which I can clear all personal data from so we can see what happened... > Fri Aug 18 2017 06:31:12 PM EDT

[Citadel Development] (no subject)

> I would assume it's the same issue I dealt with: blood pools in the >ankle when you're sitting at a desk, so you have to go lie down and >elevate. You're right about that. They said keep the leg elevated, which I do, even at the desk -- chair as far down as it'll go, leg up on a

[Citadel Development] (no subject)

I have been trying to figure out how to code from my back... apart from some type of VR goggles and a special keyboard / mouse mount, it evades me.   Just remember, if you do it, I wont charge you royalties, just send me one ;) > Fri Aug 18 2017 11:24:00 AM EDT from LoanShark @ Uncensored

[Citadel Development] (no subject)

Thanks for asking. :) It's slow going and I am physically and emotionally drained. I'll work a few hours and then have to go lie down for a while. Very frustrating. Ok so tell me what you did with imapcopy. Does this mean your production system is on a "clean" server now? I'm convinced

[Citadel Development] (no subject)

That is what I did.  How is the recovery? > Thu Aug 17 2017 10:24:47 AM EDT from IGnatius T Foobar @ Uncensored > >Most imap-to-imap copy tools have a way to exclude public folders, or at >least to include/exclude folders which match a particular pattern (in Citadel >that would be

[Citadel Development] (no subject)

Most imap-to-imap copy tools have a way to exclude public folders, or at least to include/exclude folders which match a particular pattern (in Citadel that would be mailboxes under the INBOX/ hierarchy, and public rooms under their floor names)

[Citadel Development] (no subject)

Annoying!  I am trying to do an imapcopy from one citadel to another to clear out possible corruption in the system configs, but it is copying into each users folder the shared rooms! This would make my DB 300x the current size for those files!   Any thoughts?

[Citadel Development] (no subject)

>2) unable to send email to users with internet mail disabled. This is a show >stopper. I cannot use the email address listed as internet address without >enabling all internet email. Let's see if we can boil this down a bit. Is it your expectation that we should always read

[Citadel Development] (no subject)

I understand. Good recovery to you. Any time frame on being back on your feet?   > Wed Aug 09 2017 11:47:41 AM EDT from IGnatius T Foobar @ Uncensored > > >I'm currently bedridden and taking painkillers, so we may be into next week >before I'm able to concentrate on code again. It

[Citadel Development] (no subject)

I'm currently bedridden and taking painkillers, so we may be into next week before I'm able to concentrate on code again. It sounds like you've found the kind of issues that would have caused some problems had we released the new code into the wild without more testing, so that;s good.

[Citadel Development] (no subject)

Ouch, just read about your trip to Texas... I thought Chicago would do more damage...  Let me know when we can work together to hammer out this new model. I have a system up with a userbase / dataload in it of about 300 users and about 56 gig db, which should allow for some testing. > Sun

[Citadel Development] (no subject)

Ig, you on vacation?   I would like to troubleshoot through getting the new model working, but we would need to be semi-interactive. How is your schedule?

[Citadel Development] (no subject)

Issues with new model.    1) authentication was hit and miss with ldap. webcit would authenticate, but IMAP would not.   2) unable to send email to users with internet mail disabled. This is a show stopper. I cannot use the email address listed as internet address without enabling all

[Citadel Development] (no subject)

You are correct in assuming I have auto delete enabled. Once I do the db_recover and restart citadel, after a little bit, it clears through them, but then something happens and they start to pile up again. If I do not catch it in time, it is ends up filling up the drive, and then crashes the

[Citadel Development] (no subject)

>IG, what would cause my data folder to fill up with .log files repeatedly? I I'm assuming you have your Citadel Server configured to automatically delete log files after they are no longer needed? In that case the server should automatically be doing what you are doing manually. If

[Citadel Development] (no subject)

IG, what would cause my data folder to fill up with .log files repeatedly? I have to keep running db_recover -c to bring citserver to the place where it will clear them up, but then within hours they are appearing again.     

[Citadel Development] (no subject)

It will certainly not *pull* from the vCard any time after the initial conversion. Now, we have to talk about what conditions should cause a *push* to the vCard, and what conditions should cause a push of the vCard to the GAB.

[Citadel Development] (no subject)

So, after that, it will not look at the vcard any more? Am I going to be fighting with it constantly wanting to pull that info back in or is it a one time thing? > Tue Jul 18 2017 09:29:38 AM EDT from IGnatius T Foobar @ Uncensored > >There is nothing special about the GAB. We don't read

[Citadel Development] (no subject)

There is nothing special about the GAB. We don't read it during the upgrade. When you upgrade an existing system to the new format, it goes through each user's vCard in their own config room, and pulls out the email addresses -- just like it used to do when populating the GAB. It then puts

[Citadel Development] (no subject)

Ok, so now that we made some progress on our Bakery, I am finally able to get back to citadel.   I am setting up a machine which can host my tests both with an existing dataset, and without so that I can test an upgrade with 300 + accounts and also a new install. This will all be LDAP.  

[Citadel Development] (no subject)

IG, I got troubles here. My production citserver is failing to come up. The drive filled up because of the logging issue, and when I tried to recompile with the new update to fix it, it will not start now citserver fails to come up, so setup has nothing to connect to...

[Citadel Development] (no subject)

Not sure ... I do a lot of silly things when the focus is stolen. I'm on a Linux desktop right now. Gosh this feels good. Anyway, LDAP definitely has to factor into it, but of course we still have to work properly on standalone systems. And I'm still thinking through this

[Citadel Development] (no subject)

Seems a message may have been clobbered... unless you deleted it (granted, it was only asking if my last post was clear and made sense)... It is no longer here.

[Citadel Development] (no subject)

Seems good. I would push it out. > Tue Apr 18 2017 01:33:50 PM EDT from IGnatius T Foobar @ Uncensored > > >I've committed a change to git master that I believe makes UID COPY match >the expected output format. A sample output is posted to >http://pastebin.ca/3798661 in case it doesn't

[Citadel Development] (no subject)

I will give this a try tomorrow night (next chance I get to push something).    I do recall that possibly a system will have issues with it because the source UID and destination UID are the same... I believe they are supposed to be unique per folder. (I could be wrong though) > Tue Apr

[Citadel Development] (no subject)

I've committed a change to git master that I believe makes UID COPY match the expected output format. A sample output is posted to http://pastebin.ca/3798661 in case it doesn't reproduce cleanly here, but here it is: A001 fetch 1:* uid * 1 FETCH (UID 5559) * 2 FETCH (UID 5711) * 3

[Citadel Development] (no subject)

Yes, ok. I will check back in this afternoon to see where things are at. Thank you! > Tue Apr 18 2017 11:30:40 AM EDT from IGnatius T Foobar @ Uncensored > >I'll manage on this one :) I will try to get a fix out later today. >https://tools.ietf.org/html/rfc2359#section-4.3 makes it pretty

[Citadel Development] (no subject)

I'll manage on this one :) I will try to get a fix out later today. https://tools.ietf.org/html/rfc2359#section-4.3 makes it pretty clear what the output should look like in this case.

[Citadel Development] (no subject)

Do you need me to be around today to test a patch? I still have some repair work to do, and will be in and out today (unless I know when you will be ready to test a patch).   The RFC on it is pretty simple.

[Citadel Development] (no subject)

I will not be checking messages for the next 24 hours or so. If there is any more input needed from me, I will check back tomorrow night and see where things are at, and will be back at it on Sunday.   Thanks again!

[Citadel Development] (no subject)

I like ctdlsh - can't wait for more functionality. It feels good.   export seems really slow... and is there an import?

[Citadel Development] (no subject)

I just pushed another minor change out. Temporarily undeliverable outbound mail was being retried a bit too aggressively, after I accidentally committed a testing hack. The update restores the normal behavior of reasonable retry times. By the way, the new version no longer does exponential

[Citadel Development] (no subject)

I guess I kept it generic enough on the last one that it isn't actually just an ldap issue :)   Issue 1a) ability to edit an existing post :)

[Citadel Development] (no subject)

>IG, thoughts on my first issue? If you need a couple issues which you might >be able to do quicker, I could set up a list and you can pick which one to >work on as you know your time better than I do. I'm trying to understand it, actually. Are you having trouble selecting

[Citadel Development] (no subject)

IG, thoughts on my first issue? If you need a couple issues which you might be able to do quicker, I could set up a list and you can pick which one to work on as you know your time better than I do. Would be nice to hear at least a "looking over it... or whatever" :) 

[Citadel Development] (no subject)

  Wed Mar 22 2017 16:28:12 EDTfrom bennabiy @ Uncensored What OS do you run on your server? Gentoo with a self compiled monolithic kernel. I is definitely a layer 8 failure, since I ran into the same problem with two different network cards.

[Citadel Development] (no subject)

What OS do you run on your server? > Wed Mar 22 2017 04:14:22 PM EDT from the_mgt @ Uncensored > > > >Swamped up in work here, too. > >Since you live closer to IBM central then me, can you please drive over and >tell them to doing systems management here? > >They incredibly inefficient

[Citadel Development] (no subject)

Swamped up in work here, too. Since you live closer to IBM central then me, can you please drive over and tell them to doing systems management here? They incredibly inefficient and incompetent at the same time, it is as if they skim the market and pickt the most unfit persons for a certain task

[Citadel Development] (no subject)

  Wed Mar 22 2017 16:14:22 EDT from the_mgt @ Uncensored Since you live closer to IBM central then me, can you please drive over and tell them to doing systems management here? That should have been Since you live closer to IBM central than me, can you please drive over and tell them to stop

[Citadel Development] (no subject)

The simplified RSS reader has now been published (Citadel server v906). It's not running on Uncensored yet, but I'll push that out maybe tonight. About half of our RSS feeds are failing right now.

[Citadel Development] (no subject)

Nice to hear, will have a look at the code thins weekend. The "transition phase" at the new job is a disaster.

[Citadel Development] (no subject)

This weekend I rewrote the RSS feed reader. Since a lot of effort has gone into the last couple of versions, I wanted to take some time to outline my current vision for the system and why I'm replacing working code. The very short answer is: "simplify." My original intention this

[Citadel Development] (no subject)

Current targets: webcit (webcit-ng branch) , and ctdlsh Objective: end the use of the various GNU auto-tools Rationale: Richard Stallman is Hitler Actual rationale: these tools introduce an unnecessary level of complexity. 10-15 years ago the unix systems in use at the time were wildly

[Citadel Development] (no subject)

Well, we could just identify a parent room for each room, which would make more sense than trying to put together an entire directory-structure of child rooms. So I'm not going to remove floors quite yet. A replacement is not on its way however. We have to cope with the reality that we

[Citadel Development] (no subject)

CalDAV: I only ever got groupdav running once, every other machine I use lures me into using CalDAV. Speaking of this, I can offer a Sailfish OS mobile phone and a bunch of Apple devices to torture your CalDAV implementation. Just tell me where and when and why and what. Floors: IIRC, IMAP

[Citadel Development] (no subject)

> I'd still ditch the C, and build a stateless variant of the port-504 >protocol hosted in citserver itself. That would be enough to break the >depedency on having an "engine" per se in webcit, which is necessary >because webcit is currently acting as a TCP concentrator for port 504.

Re: [Citadel Development] (no subject)

On Sat, Jul 16, 2016 at 12:36 AM, IGnatius T Foobar wrote: > > Also thinking about getting rid of floors. They've never been proper > containers and the system would be simpler without them. > > And then replaced by what, if anything? It's already hard enough to organize

[Citadel Development] (no subject)

Also thinking about getting rid of floors. They've never been proper containers and the system would be simpler without them.

[Citadel Development] (no subject)

I am both thrilled that my CalDAV implementation is coming along and frustrated that CalDAV is the de-facto standard protocol. I still think it's a *way* over-engineered design. But I finally got Thunderbird to actually display my calendar. Booyah! Mozilla takes the same approach to

[Citadel Development] (no subject)

What's with the openssl problem? Is it something that breaks when you use a newer version of the openssl library? If I can make it break by updating OpenSSL on my dev box, that would be pretty straightforward to test. As for GroupDAV, as much as I completely think CalDAV is BADLY

[Citadel Development] (no subject)

yes, groupdav iseems more than dead. btw, openssl? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828267

[Citadel Development] (no subject)

Next design decision I am considering (and this requires immediate attention). Although I still consider GroupDAV to be a superior design to CalDAV+CardDAV, it seems we lost that battle a long time ago. The question is not whether to support CalDAV+CardDAV in addition to GroupDAV, but

[Citadel Development] (no subject)

Here's another interesting candidate CSS/JS framework: [ http://materializecss.com/ ] This framework is modeled after the "Material Design" UX that is popular on current web and mobile applications. It's built using just CSS and JS (including some JQuery plugins, but we were

[Citadel Development] (no subject)

What is ED? Looks like some sort of new crypto algorithm?

[Citadel Development] (no subject)

while you're at it, maybe also add the initialisation code for ED? https://github.com/arangodb/arangodb/commit/4a7e54e215e13b12792f1a01d25795455e708071 the chatter about it and what else could be done: https://github.com/arangodb/arangodb/issues/1771 (though the ed just needs some additional

[Citadel Development] (no subject)

And in another "seriously, it's 2016, wtf" moment of clarity ... OpenSSL is now a required dependency. This took about a quadrillion #ifdef clauses out of the code (which is impressive considering that it's only a few hundred lines). Pretty much everyone wants crypto now anyway, and the

[Citadel Development] (no subject)

SSL code now mostly in place. S much cleaner this time. Passing the SSL handle up the stack along with the socket number, instead of sticking it into a thread context. That's the idea this time, everything gets passed up the stack, we try not to stick a lot of stuff into thread

[Citadel Development] (no subject)

Sold!  It makes sense that increasing concurrency has a point of diminishing returns.  Back when threads were bound to individual user sessions rather than actively running transactions, it made sense to have lots of them because they'd spend most of their lifetime in a blocking state.

[Citadel Development] (no subject)

32 is the value for maxWorkerThreads that we use in a variety of our (Java-based) backend service Tomcat instances for the AJP pool tuning. Default values in the hundreds proved to be too resource-hungry; and, empirical load testing has often found a point of diminishing returns (on a

[Citadel Development] (no subject)

> You'll Never Need More Than 32. As long as they're not blocking for >long periods. Ok, I'll bite ... where did you get that number from? Right now I've got it set up the same as it was before: start with 1 thread, spawn another thread whenever it is detected that all threads are

[Citadel Development] (no subject)

>So, no cleanup if there's no connections after a period of time. Any >thoughts on settings for minimum or maximum worker threads? Actually I meant no cleanup when the program exits, since the operating system will take care of that. I know that deliberately unloading everything makes

[Citadel Development] (no subject)

>So, no cleanup if there's no connections after a period of time. Any >thoughts on settings for minimum or maximum worker threads? You'll Never Need More Than 32. As long as they're not blocking for long periods.

[Citadel Development] (no subject)

  Wed May 11 2016 05:31:46 PM EDT from IGnatius T Foobar @ Uncensored The very bottom layers of webcit-ng are taking shape. It is so refreshing to be able to throw away code that implements assumptions and requirements from 20 years ago. The new code requires no per-thread state, since it's

[Citadel Development] (no subject)

The very bottom layers of webcit-ng are taking shape. It is so refreshing to be able to throw away code that implements assumptions and requirements from 20 years ago. The new code requires no per-thread state, since it's not descended from code that was, at one time, not a worker thread

[Citadel Development] (no subject)

awesome :) Hopefully you notice ... nothing!All the changes are under the hood. But we know networking is up :)

[Citadel Development] (no subject)

WOOT!!! Citadel 902 Dog Pound BBS II Fishers, IN

[Citadel Development] (no subject)

LOL...I'm trying it again.

[Citadel Development] (no subject)

Fscking h3ll. /usr/bin/git checkout $BRANCH #for module in libcitadel citadel webcit textclient for module in textclient do That's the push script.  I must have commented the other stuff out for an interim release of the text client.  It's fixed now.

[Citadel Development] (no subject)

Um...maybe not? Installation will now begin. Command output will not be sent to the terminal. To view progress, see the /tmp/citadel-install-log.txt file. * libical does not need updating. * libsieve does not need updating. * Berkeley DB does not need updating. * expat does

[Citadel Development] (no subject)

>Oops. I only upgraded Queasy Install. > > Easy Install is now updated too. D'oh!!! I'll give it another try. Thanks.

[Citadel Development] (no subject)

Oops. I only upgraded Queasy Install. Easy Install is now updated too.

[Citadel Development] (no subject)

> Ok, it's time! > > "Release_902" is the git tag for our official Version 902 release of >the Citadel system. > > Easy Install has been updated, and I'm building source tarballs now. I just tried to upgrade via Easy Install...the only thing updated was the text

[Citadel Development] (no subject)

I don't think that swaggerized API description is a playbed. If you want to do REST, you have to design a URL patern, so you can reliably parse them and split "floor / room \ subroom / item" when parsing the URL. I think the code to work with mail inside of webcit is sophisticated enough to void

<    1   2   3   4   5   6   7   8   9   10   >