Re: Tru64 and 2.2 problems - cast-to-union
Scott Adkins wrote:
> Yes, this is a concern for me... I am not exactly sure how this will be
> stored in Tru64. We are talking about a "char *" and an "int" stored in
> the same location. I have always known them to consume 4 bytes of memory,
> but my manager isn't so sure, thinking that maybe it is 8 bytes of memory
> these days for more efficient storage. The little-endian and big-endian
alpha is 64-bit. It conforms to the LP64 standard (long/pointers are 64
bits). Thus under normal circumstances pointers and longs ("long int")
are 64 bits == 8 bytes. A union of "char *" and "int" will be 8 bytes long.
For completeness I mention the compiler and linker flags "-taso", "-xtaso",
and "-xtaso_short", which can be used to force the compiler/linker to make
virtual addresses fit within 32-bits, and also make pointers 32-bits
long, but unless you're trying to compile horribly unportable code you
should avoid these.
> Isn't there a more portable way of doing this? Requiring GCC for the
> compilation of Cyrus is a bit too strict, in my opinion. Rob sent another
> message out asking me why I just don't use GCC anyways, because it would
> be simpler than them rewriting the code to make it more portable. I just
> don't agree with that... in fact, the Tru64 CC compile is highly optimized
> for the platform, takes advantage of all the pipelining and special ways
> that the architecture is designed to execute code. Sure, Compaq supplied
> a bunch of code to GCC, but it is nowhere near what is already in the CC
> compiler, and on top of that, the engineers there have stated that they
> are constantly comparing CC to GCC to see how it compares, and CC always
> blows away GCC with regards to performance. Why switch to GCC and lose
> any performance gains we would have had just to support a GCC specific
> extension which is a bit controversial in nature to begin with?
also, if the DECC compiler can compile something, because of its
strictness the chances are very good that other compilers will too.
That is, getting rid of errors that DECC brings to light makes the code
cleaner...
Rob Urban
Re: Tru64 and 2.2 problems
Scott Adkins wrote: > 1) The configure process appears to pick up on the fact that Tru64 does > have getnameinfo(), but not getaddrinfo(). The problem is that if one > is found and the other is not, the definitions for both are included > in lib/gai.h. Well, getnameinfo() on Tru64 has a slightly different > definition and produces a conflict that the compiler can't resolve. > The solution was to modify gai.h and wrap the getaddrinfo() related > routines with "#ifndef HAVE_GETADDRINFO/#endif" macros, and wrap the > getnameinfo() with similar HAVE_GETNAMEINFO macros. Tru64 does indeed have a getaddrinfo, it even has two. You must #include in order to pull in the appropriate definition. The designers of Tru64 bent over backwards trying to be as standards-compatible as humanly possible. Because the standards (4.4/4.3 BSD) define contradictory behaviour for getaddrinfo, you must say what you want. By default you get 4.3BSD behaviour. If you want 4.4BSD, you must define _XOPEN_SOURCE_EXTENDED before you #include . See standards(5) for more information on these things... > 3) After that, it compiles for awhile and then stops on imap/protocol.c > with the following error: > > cc: Error: ./../lib/prot.h, line 209: Missing ";". (nosemi) > __attribute__ ((format (printf, 2, 3))); > > Looking in lib/prot.h, I see the following: > > extern int prot_printf(struct protstream *, const char *, ...) > __attribute__ ((format (printf, 2, 3))); > > What is that supposed to do? I simply deleted the line that has the > __attribute__ on it and put a semicolon on the previous line and it > compiles. What problems will I see by doing that? I don't have any specific suggestions wrt to the problems above, but cc -source_listing -show all [other flags] sourcefile.c is your *friend*. It produces sourcefile.lis which can be immensely helpful. cheers, Rob Urban
Re: addusers and bsd2cyrus
joe ritter wrote: > scripts still refer to the TCL based cyradm. I was > wondering if anyone could share any batch creating and > batch setup scripts with me and or any other tips on > this procedure. Thanks in advance. I just finished an example script for adding users. You may find it helpful: http://www.unix-wissen.de/add-cyrus-user cheers, Rob Urban
what are the units for the setquota() method
Does anyone know what the units are (i.e., Bytes, KBytes, etc) for the setquota method? (Cyrus::IMAP::Admin) Couldn't hurt to put this in the manpage! cheers, Rob Urban
HTML-formatted mails [was: Re: Question about Autocreate patch.]
is it naive of me to think that it might be possible to train users of this list not to send HTML-formatted mails to the list? that perhaps with constant reminders and pointers to the appropriate documentation on netiquette things might improve? any chance of configuring the list server to reject mails containing HTML? Rob Urban http://www.tfl.net/maillistfaq.html http://www.imperialclub.com/GettingStarted/MailingLists/Etiquette.html http://www.openz.org/list_etiquette.php http://www.efn.no/html-bad.html http://www.writerswrite.com/journal/dec99/pirillo1.htm http://www-zeuthen.desy.de/~friebel/mail/mail02/text10.html In PDF, but very nicely done: http://eesc.orst.edu/agcomwebfile/staff/Cate/Back0999.pdf other lists' policies: http://www.histology.to/listservers.html http://www.rockandwater.net/list-policies.html http://legalminds.lp.findlaw.com/list/food-law/msg02330.html http://lyrictracker.com/main.php?action=nug-rules tips for turning off HTML in various clients: http://email.about.com/cs/netiquettetips/a/et070103.htm Drew Weaver wrote: > Howdy, I got the autocreate patch working and its very nice, the only = > thing im trying to figure out is this. If I userdel a user, why does = > sendmail still deliver mail as if the user still exists? Shouldnt = > sendmail say, hey uh this user doesnt exist, and return the message? > > -Drew > > > > > > > > > Howdy, I got the autocreate patch working and its > very nice, the only thing im trying to figure out is this. If I userdel a user, > why does sendmail still deliver mail as if the user still exists? Shouldnt > sendmail say, hey uh this user doesnt exist, and return the > message? > > -Drew > >
Re: Ok -- I got a few problems ironed out.
You wrote: > any idea what I need to do? also does anyone have something I can toss = > into a perl script to auto create mailboxes for users that have 15mb = > quotas? see: http://www.unix-wissen.de/add-cyrus-user for a (very) simple example of a script for adding cyrus users. cheers, Rob Urban
Re: cyradm authentication error
Kevin Williams wrote: > My imapd.conf file looks as follows: > > configdirectory: /var/imap > partition-default: /var/spool/imap > admins: cyrus root > sasl_pwcheck_method: saslauthd > > I can successfully authenticate using the imtest command. When I > tried to use cyradm, I originally got a "can't locat > Cyrus/IMAP/Shell.pm in @INC. I moved all necessary (I think) > folders from the folder they were installed in (/user/local/lib > instead of /user/lib) to be included in the path. Now when I run > cyradm, the program just hangs and I get the following error in my > imapd.log file: > > badlogin: web01[127.0.0.1] DOGEST-MD% [SASL(-13): authentication failure: > client response doesn't match what we generated]. > > When I enter the sasldblistuser2 command, I get the following: > [EMAIL PROTECTED]: userPassword. I had this problem too. The answer is actually in the docs (install-auth), but it can take days before you find it :( The whole authentication business is pretty badly documented, IMHO. use sasl_pwcheck_method: auxprop in imapd.conf (which is the default) and both imtest and cyradm should used sasldb2. Rob Urban
mixed delivery to imap and non-imap mailboxes
Hello imappers, apparently the standard installation of cyrus imap entails changing themail config such that local delivery is performed exclusively to IMAP mailboxes. I'm trying to configure a system on which some users should have mail delivered to IMAP mailboxes, others however to their regular unix mailboxes. I can imagine that others have also had to solve this problem, particularly considering there are some accounts that require exceptions to the usual delivery rules. In particular the "root" account springs to mind. Before I install procmail as my MDA and handle it that way, I wanted to ask this community if there is a simpler way. It would seem reasonable for "deliver" to deliver to a unix mailbox if no such cyrus user exists. Since I couldn't find anything about this in the docs, I presume it doesn't behave this way. Any comments or simpler solutions? thanks, Rob Urban
user unable to create sub-folders
Hello,
i've just set up v2.1.12 on a RedHat 8.0 system using sasl2.
I've created a single user (urban) using cyradm, and now I'm using
Mozilla 1.0.1 ("the client") as MUA to test. The client is connecting
to the IMAP server using TLS sucessfully. When the client tries to
create the "Drafts" or "Sent" folders however, the operation fails.
It seems to me that the client should be able to do this.
cyradm says:
=
localhost> lm
user.urban (\HasNoChildren)
localhost> lam user.urban
urban lrswipcda
in imapd.log I see:
==
Feb 22 04:16:29 bingo imapd[27855]: open: user urban opened INBOX
Feb 22 04:17:18 bingo imapd[27855]: myfetch: starting txn 2147483657
Feb 22 04:17:18 bingo imapd[27855]: abort_txn: aborting txn 2147483657
Feb 22 04:18:47 bingo master[27843]: process 27847 exited, status 0
and in configdirectory/log/urban/ I see
===
-- urban Sat Feb 22 04:16:29 2003
<1045883789<4 select "INBOX"
>1045883789>* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)]
* 0 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1045842775]
* OK [UIDNEXT 1]
4 OK [READ-WRITE] Completed
<1045883838<5 list "" "Sent"
>1045883838>5 OK Completed (0.000 secs 1 calls)
<1045883838<6 create "Sent"
>1045883838>6 NO Permission denied
<1045884225<7 noop
>1045884225>7 OK Completed
<1045884825<8 noop
>1045884825>8 OK Completed
anyone have an idea?
thanks,
Rob Urban
