From achurch at achurch.org Wed Jan 2 01:30:41 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Services 5.0 alpha 10 released Message-ID: <3c31e50f.43167@achurch.org> >memoserv/forward: /ms SET FORWARD [ON|OFF|COPY] doesn't work. Patch >follows: Fixed. >memoserv/forward: After applying the above fix, /ms SET FORWARD >[ON|COPY] returns the following: > [14:11:26] Your memos will now be forwarded to your E-mail address: >(null) Fixed. >memoserv/forward: After applying the set forward fix, forwarded memo >e-mails contain: > Memo from (Dec 26 13:58:10 2001 GMT) >without any name. Probably a similar problem to the above. Fixed (the code was passing a User * to a %s). >nickserv/autojoin: Although the AJOIN command works a treat, it >doesn't seem to appear on the /ns HELP COMMANDS list. Fixed. >memoserv/main: The memo send confirmation messages appear when >sending to some users, but not others. I'm not sure what determines >this though. Every time, however, the memo is sent, just sometimes it >isn't confirmed. I can't see any obvious reason for this. Can you try to narrow down what causes the problem (e.g. various memo option settings)? --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Wed Jan 2 01:34:41 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] errors.log? Message-ID: <3c31e5bc.43213@achurch.org> >Hi! > >errors.log: >[Fri Dec 28 23:16:22 2001] - num - 1 > >What's this? I have no clue; Services doesn't write an "errors.log" file (unless you've set the log filename to that), and there's no code in Services that would write a log message like that, at least that I can see. --Andrew Church achurch@achurch.org http://achurch.org/ From haibi at free.fr Sat Jan 5 05:41:46 2002 From: haibi at free.fr (Habib HAIBI) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Meilleurs Vœux pour 2002 : année de mémoire, de mobilisation, d'action, de justice et de sérénité - Appel au soutien moral et financier Message-ID: <3c37026b3cebd6fb@amyris.wanadoo.fr> (added by amyris.wanadoo.fr) Meilleurs Vœux pour 2002 : année de mémoire, de mobilisation, d'action, de justice et de sérénité - Appel au soutien moral et financier ======================== M. Habib HAIBI, 7, Aguesseau St. 69007 LYON - France Tél. 00 33 4 72 73 19 08 - Fax 00 33 4 78 61 39 27 Email : haibi@free.fr http://haibi.free.fr Je suis qualifié pour exprimer mes voeux pour le Nouvel An à tous les survivants et les familles des victimes des attaques terroristes, au peuple américain, ses dirigeants, ses institutions, son président et tous les combattants de la liberté, loin de leurs foyers, tout autour du monde! Je suis fier de vous dire avec gratitude combien Les USA sont puissants, démocratiques et qualifiés pour défendre la liberté et la démocratie avec humanisme et sérénité. L'ennemi du progrès du genre humain peut encore frapper. La liberté et la démocratie peuvent être encore sous attaques! Personne ne s'imaginait que cela pouvait arriver et c'est arrivé en ce jour pacifique du 11 septembre 2001 Personne ne s'imaginait que cela pouvait arriver… en France et c'est arrivé le 26 février 2001 quand les magistrats du parquet de Lyon, par impulsion suicidaire et préméditée, ont eu recours à l'arbitraire pour entraver l'action Publique mise en Mouvement : ils ont requis l'expertise psychiatrique de la Partie Civile par l'action avant de l'entendre dans ses accusations ! Cette dérive obscurantiste a dépassé tout entendement C'est arrivé un jour pacifique pour moi et pour les institutions de la République en France. Le réquisitoire aux fins de l'expertise psychiatrique de la partie civile par l'action, avant de l'entendre dans ses accusations, constitue une atteinte obscurantiste à l'intégrité de la personne de la partie civile et surtout un attentat aux valeurs fondamentales de la société civilisée et une infamie assénée à la République et ses Institutions: - à tous les martyrs de la liberté qui ont payé de leur vie la défense des personnes et des biens et des valeurs fondamentales et universelles de la République. - à tous ceux qui dans l'exercice de leurs fonctions, au nom du devoir de servir, exposeraient leurs vies, sans hésitation, pour la défense de ces mêmes valeurs - à tous les hommes ou femmes de bonne volonté, citoyens anonymes, élevés sur la foi en une société pacifiée par l'avènement de la République, la crainte des lois et l'indéfectibilité de l'Etat, de la Justice et des Institutions en Démocratie. J'étais, longtemps avant le WTC l'autre "point zéro" de la planète qui a subit les premières vagues d'attaque contre les institutions de la République, la liberté et les droits de l'homme … en France ! Il y a eu trois autres attaques avec la même détermination, diabolique et suicidaire, de stopper l'action publique régulièrement mise en mouvement ! J'ai fait face à l'adversité en mettant en accusation 15 magistrats, saisis par la foudre de l'action publique en colère, nominativement impliqués, des deux juridictions de Lyon tout rôle et rang confondus pour abus d'autorité aggravé et trafic d'influence aggravé. Une fois que vous avez pris la mesure de l'attaque contre les valeurs universelles de la liberté et la justice en démocratie en France… et assimilé la grandeur de la querelle qui m'anime … Votre réaction sera vivement souhaitée et sollicitée ! Je recevrai vos contributions morales et financières comme une juste consolation pour le grand préjudice moral que je subis dans l'attente de la réparation de la faute lourde par la justice et l'Etat. Souvenez-vous que la paix civile fut conquise au prix de feu, de sang et de sacrifices… avec pour objectif le règne absolu et égalitaire de la loi. Imaginez les victimes du 11 septembre 2001 dans un monde sans liberté, sans justice et sans démocratie… Imaginez tous les sacrifices de tous les combattants de la liberté, depuis deux siècles et plus, laissés pour compte et discrédités en une seule journée d'attaques perpétrées par les forces diaboliques de l'arbitraire et de l'obscurantisme dans le pays qui a donné naissance au reigne de la loi, l'avènement de la République et les droits de l'homme. Une nouvelle ère a commencé où le grand pays que sont les Etats Unis vont guider et pour longtemps l'impulsion de l'alerte et de la réaction pour perpétuer la liberté et la justice en démocraties. C'est aussi votre combat et le combat de tous les hommes libres. Merci au président des Etats Unis pour son leadership, l'immense puissance de son pays et sa sérénité. Merci à tous d'avoir lu et compris ce message. Merci pour vos réactions et vos contributions. ========================== Ces contributions sont souhaitées à la hauteur de 500 $ ou euros et plus pour tous les représentants élus des peuples, sénateurs et députés, quelque soit leur pays et quelque soit le moyen utilisé pour les alerter des attaques contre la démocratie et de la colère de l'action Publique en mouvement : "ma tristesse s'est muée en colère et la colère en résolution "! (ma conviction est que si de tels actes ont pu se produire c'est à cause d'un climat de permissivité qui a pu s'installer par l'absence du contrôle de l'exécutif par le pouvoir législatif…). ======= vous pouvez verser directement vos contributions financières sur le compte : RIP RELEVE D'IDENTITE BANCAIRE 20041 01007 1112632 F038 69 IBAN IDENTIFIANT INTERNATIONAL FR 53 20041 01007 1112632 F 038 69 Ou envoyer un mandat cash à mon nom et à mon adresse. ================================ Les contributions seront libres et bienvenues de la part de tout autre citoyen sensible à l'idée de vivre dans une société pacifiée par la crainte des lois et la crédibilité des institutions démocratiques. ============ Mon objectif est de réunir 10 000 réactions à 100 $ ou euros chacune : vous pouvez m'aider à atteindre ce but. Je serai, à coup sûr, un homme riche! Mais je ne recouvrerai la paix intérieure avant que justice soit faite! 'J'ai un rêve"! La justice sera faite ! ============ Le site où est publié l'ensemble du dossier est en français, vous pouvez vous aider pour la traduction par un moteur de traduction sur internet. http://haibi.free.fr ============ Cette mailing liste, non exhaustive, est composée de 30 000 emails : des représentants élus, les représentants de l'Etat, hauts fonctionnaires, magistrats, avocats, journalistes, chefs d'entreprise, président ou membre d'association, profession libérale ou tout autre simple citoyen intéressé par la vie sociale, administrative et judiciaire. ======================= Vous pourrez discuter en circuit interne non publié sur le net en vous abonnant au groupe créé pour cet objet "Il n'y a pas d'alternative à la justice en république en france" Coordonnées du groupe : Email du groupe : lecitoyen.laloi.larepublique@smartgroups.com Email du gestionnaire : lecitoyen.laloi.larepublique-owner@smartgroups.com Pour devenir membre : lecitoyen.laloi.larepublique-subscribe@smartgroups.com Pour ne plus être membre : lecitoyen.laloi.larepublique-unsubscribe@smartgroups.com Accueil du groupe : http://smartgroups.wanadoo.fr/groups/lecitoyen.laloi.larepubliqu e ====================== Si vous ne vous sentez pas concerné, vous pouvez demander à ce que votre email soit effacer en exprimant votre volonté à l'adresse email : haibi@free.fr Merci encore de participer à l'alerte et au suivi de l'action publique en mouvement, et au soutien moral et financier de la partie civile par l'action. =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================================== =================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== =================================== ceci n'est pas un spam vous pourrez en recevoir une version en anglais Merci ! NEVER SEND SPAM. IT IS BAD. From v13 at priest.com Sun Jan 6 05:52:14 2002 From: v13 at priest.com (v13@priest.com) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] svcs5 - request Message-ID: <200201061352.PAA01890@ppp0.the.forthnet.gr> If you realy want other people to write useful modules, then it should be possible for each module to extend the NickServ and ChanServ (and even the others) databases. I suppose that having a: struct ext_list { struct ext_list *prev, *next; long id; size_t size; void *buf; }; that will form a list for each nickname/channel whould be what we need. It should be easy to save it using the existing database format. Also by providing some functions like: struct ext_list *get_extlist_memb(struct ext_list *head, long id); void update_extlist_memb(struct ext_list **head, long id, size_t size, void *buf); /* and one for delete */ it should be very easy to handle it. Each module will only need to have a fixed unique integer to use and it will need only one field to be added to struct NickInfo etc.. like: struct NickInfo { ... struct ext_list *head; }; and after that.. /**********************************************/ #define MY_ID 0x1234 struct NickInfo *ni; struct ext_list *el; ...code... update_extlist_memb( &(ni->head), MY_ID, 7, "RANDOM" ); ...code... el=get_extlist_memb(ni->head, MY_ID); /* and there we have el==NULL or el->buf == "RANDOM" */ /**********************************************/ Something like this whould *REALY* help to add functionality without changing existing code, without creating another database and will be compatible to future versions. TIA <> From achurch at achurch.org Sun Jan 6 22:57:52 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] svcs5 - request Message-ID: <3c3858ae.37251@achurch.org> I'm planning to do this when I redo the database handling, but that will be in a future version--the current design has settled too much for me to want to redo it right now. As things stand now, such additions can still be done--they just require a separate database. (Whether this is more or less efficient than a structure of the kind described below is left as an exercise for the reader.) --Andrew Church achurch@achurch.org http://achurch.org/ > If you realy want other people to write useful modules, then it should b >e >possible for each module to extend the NickServ and ChanServ (and even th >e >others) databases. I suppose that having a: > >struct ext_list { > struct ext_list *prev, *next; > long id; > size_t size; > void *buf; >}; > >that will form a list for each nickname/channel whould be what we need. I >t >should be easy to save it using the existing database format. >Also by providing some functions like: > >struct ext_list *get_extlist_memb(struct ext_list *head, long id); > >void update_extlist_memb(struct ext_list **head, long id, size_t size, > void *buf); > >/* and one for delete */ > >it should be very easy to handle it. > >Each module will only need to have a fixed unique integer to use and it w >ill >need only one field to be added to struct NickInfo etc.. like: > >struct NickInfo { > ... > struct ext_list *head; >}; > >and after that.. > >/**********************************************/ > >#define MY_ID 0x1234 > > struct NickInfo *ni; > struct ext_list *el; > > ...code... > > update_extlist_memb( &(ni->head), MY_ID, 7, "RANDOM" ); > > ...code... > > el=get_extlist_memb(ni->head, MY_ID); > > /* and there we have el==NULL or el->buf == "RANDOM" */ > >/**********************************************/ > >Something like this whould *REALY* help to add functionality without chan >ging >existing code, without creating another database and will be compatible t >o >future versions. > >TIA ><> >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From beng at nc.rr.com Sun Jan 6 09:42:24 2002 From: beng at nc.rr.com (Ben Goldstein) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] svcs5 - request References: <200201061352.PAA01890@ppp0.the.forthnet.gr> Message-ID: <023d01c196d9$811dad80$0300a8c0@asi200> This is an excellent idea. I don't think it would be that big of a deal to add this to a final database version in 5.0-release, depending on how far off that is.. Keep up the good work, guys. -- Ben Goldstein (beng@nc.rr.com) ----- Original Message ----- From: To: Sent: Sunday, January 06, 2002 8:52 AM Subject: [IRCServices Coding] svcs5 - request If you realy want other people to write useful modules, then it should be possible for each module to extend the NickServ and ChanServ (and even the others) databases. I suppose that having a: struct ext_list { struct ext_list *prev, *next; long id; size_t size; void *buf; }; that will form a list for each nickname/channel whould be what we need. It should be easy to save it using the existing database format. Also by providing some functions like: struct ext_list *get_extlist_memb(struct ext_list *head, long id); void update_extlist_memb(struct ext_list **head, long id, size_t size, void *buf); From griever at t2n.org Sun Jan 6 13:05:14 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] svcs5 - request In-Reply-To: <023d01c196d9$811dad80$0300a8c0@asi200> Message-ID: On Sun, 6 Jan 2002, Ben Goldstein wrote: Well the thing is, you would need a pointer to a function that prints it to a file, as we dont know whether it contains ints, chars, shorts, longs, or whatever. > This is an excellent idea. I don't think it would be that big of a deal to > add this to a final database version in 5.0-release, depending on how far > off that is.. Keep up the good work, guys. > > -- Ben Goldstein (beng@nc.rr.com) > > ----- Original Message ----- > From: > To: > Sent: Sunday, January 06, 2002 8:52 AM > Subject: [IRCServices Coding] svcs5 - request > > > If you realy want other people to write useful modules, then it should be > possible for each module to extend the NickServ and ChanServ (and even the > others) databases. I suppose that having a: > > struct ext_list { > struct ext_list *prev, *next; > long id; > size_t size; > void *buf; > }; > > that will form a list for each nickname/channel whould be what we need. It > should be easy to save it using the existing database format. > Also by providing some functions like: > > struct ext_list *get_extlist_memb(struct ext_list *head, long id); > > void update_extlist_memb(struct ext_list **head, long id, size_t size, > void *buf); > > > > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From v13 at priest.com Sun Jan 6 15:42:09 2002 From: v13 at priest.com (v13@priest.com) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] svcs5 - request In-Reply-To: References: Message-ID: <200201062342.BAA03628@ppp0.the.forthnet.gr> On Sunday 06 January 2002 23:05, Finny Merrill wrote: > On Sun, 6 Jan 2002, Ben Goldstein wrote: > > Well the thing is, you would need a pointer to a function > that prints it to a file, as we dont know whether it contains > ints, chars, shorts, longs, or whatever. This is the needed code.. I hope that there are no faults.. Use it if you like.. The struct contains a filed named 'type' This indicates that buf is an char buffer, an array of 16 bit values, or an array of 32 bit values. The types that are used, are uint8,16 and 32. This means that this should make the databases portable from 32bit machines to 64 bit machines as long as the head is not written to the database (I believe that pointers are 64 bit long on every 64bit machine and 32bit long on 32bit machines) The read/write routines are ready to be added to services4 database read/write functions. I don't know what are the plans for the new database format. 1st Define this struct struct ext_list { struct ext_list *next; uint32 id; uint32 size; uint8 type; void *buf; }; 2nd add to the desired existing structures this: e.x. struct NickInfo { ... struct ext_list head; /* Yes.. not a pointer. Just make sure that this has */ /* id==0, size==0, buf==NULL, next==NULL on startup */ /* Use el_clear provided below to do this el_clear(&ni->head) */ }; 3rd define: #define EL_AS_IS 1 #define EL_8BIT EL_AS_IS #define EL_16BIT 2 #define EL_32BIT 3 #define EL_SIZE(x) ( (x)==EL_8BIT ? 1 : ((x)==EL_16_BIT ? 2 : 4 ) ) void el_clear(struct ext_list *el) { el->next=NULL; el->id=0; el->size=0; el->buf=NULL; el->type=EL_AS_IS; }; 3rd add those generic functions: /* Allocate and return a new ext_list */ struct ext_list *new_el() { struct ext_list *el; el=(struct ext_list *)malloc(sizeof(struct ext_list)); el_clear(el); return(el); } /* Return the desired el, or NULL if not found */ struct ext_list *get_el_memb(struct ext_list *head, uint32 id) { struct ext_list *el; el=head->next; /* Ignore the head */ while ((el!=NULL) && (el->id!=id)) el=el->next; return(el); } /* Update or add an el */ void update_el_memb(struct ext_list *head, uint32 id, uint32 size, void *buf, uint8 type) { struct ext_list *el; el=get_el_memb(head,id); /* Check if it exists allready */ if (el==NULL) { el=new_el(); /* if not, create it */ el->id=id; el->next=head->next; /* Update the list */ head->next=el; } else { if (el->buf!=NULL) /* Else free the old data */ free(el->buf); } el->size=size; el->type=type; if (size>0) { /* if there are data */ el->buf=malloc(size); memcpy(el->buf, buf, size); /* Copy the new data */ } else el->buf=NULL; } /* Delete an el from a list */ void delete_el_memb(struct ext_list *head, uint32 id) { struct ext_list *el,*prev; prev=&head el=head->next; while ((el!=NULL) && (el->id!=id)) { prev=el; el=el->next; } if (el!=NULL) { if (el->buf!=NULL) free(el->buf); prev->next=el->next; /* prev always exists, becaus of head */ free(el); } } /* Delete a whole list */ void delete_all_el(struct ext_list *head) { struct ext_list *el,*tmp; el=head->next; while (el!=NULL) { if (el->buf!=NULL) free(el->buf); tmp=el; el=el->next; free(tmp); } head->next=NULL; } /* Write the el list to f */ void el_write(FILE *f, struct ext_list *head) { struct ext_list *el; int n,m; uint8 *p8; uint16 *p16; uint32 *p32; el=head->next; /* Ignore the head */ while (el!=NULL) { SAFE(write_int32(el->id,f)); /* First it is written the ID */ SAFE(write_int32(el->size,f)); SAFE(write_int8(el->type,f)); if (el->size>0) { /* if there are data, write them too */ switch(el->type) { case EL_8BIT: m=size; p8=(uint8 *)buf; break; case EL_16BIT: m=size/2; p16=(uint16 *)buf; break; case EL_32BIT: m=size/4; p32=(uint16 *)buf; break; } for (n=0;ntype) { case EL_8BIT: SAFE(write_int8(p8[n],f); break; case EL_16BIT: SAFE(write_int16(p16[n],f); break; case EL_32BIT: SAFE(write_int32(p32[n],f); break; } } } el=el->next; } SAFE(write_int32(0,f)); /* Now write an ID==0 to indicate the end */ } /* Read from f and append to head */ void el_read(FILE *f, struct ext_list *head) { struct ext_list el void *buf; uint8 i8,*p8; uint16 i16,*p16; uint32 i32,*p32; int n,m; SAFE(read_int32(&i32,f)); while (i32!=0) { el.id=i32; SAFE(read_int32(&i32,f)); el.size=i32; SAFE(read_int8(&i8,f)); el.type=i8; if (el.size>0) { /* if there are data */ buf=malloc(el.size); switch(el->type) { case EL_8BIT: m=size; p8=(uint8 *)buf; break; case EL_16BIT: m=size/2; p16=(uint16 *)buf; break; case EL_32BIT: m=size/4; p32=(uint16 *)buf; break; } for (n=0;ntype) { case EL_8BIT: SAFE(read_int8(&(p8[n]),f); break; case EL_16BIT: SAFE(read_int16(&(p16[n]),f); break; case EL_32BIT: SAFE(read_int32(&(p32[n]),f); break; } } update_el_memb(head,el.id,el.size,buf); /* add them to the list */ free(buf); /* free the buffer */ } else { update_el_memb(head,el.id,0,NULL); /* add them to the list */ } } } <> p.s. Sorry for the tabs :) From casper at wbss.com Sun Jan 6 17:20:55 2002 From: casper at wbss.com (CaSPeR) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] newbee ircservices User Message-ID: <03fa01c19719$8f4e8970$ace4fea9@casper> hello fellows! I am a first time user of ircservices is there any site or can someone email me a list of all the services commands that are available. I have to start somewhere! sorry for being so ignorant! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20020106/14ad2e26/attachment.html From achurch at achurch.org Tue Jan 8 00:43:22 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Services 5.0 alpha 11 released Message-ID: <3c39c64e.35136@achurch.org> Services 5.0 alpha 11 has been released, and can be downloaded from the Services home page (http://www.ircservices.za.net/) as usual. The major addition this time is XML importing, i.e. database merging. (Those of you with sharp eyes may have noticed an extra file called "xml-import.c" in modules/misc that never got compiled--well, now you know what it is. :) ) Importing is currently only possible through the httpd/dbaccess module, which will put up an import link if you load the xml-import module; you may also need to increase RequestBufferSize in modules.conf (for httpd/main) depending on the size of the file you send, since it all has to fit in a single request buffer (at least currently). It's not heavily tested, but it should know enough not to choke if you try to feed it an MP3. Changes in version 5.0a11 ------------------------- 2002/01/08 Added XML import module (xml-import) and dbaccess link. 2002/01/07 Added automatic parsing of form variables to HTTP server. 2002/01/06 Fixed memory leak (forgetting to free nickgroup ignore list). 2002/01/04 Fixed MemoServ bugs occurring with default memo limits. 2002/01/03 Removed duplicate "flags" line in NickGroupInfo XML output. 2002/01/02 Modified XML export format to make it easier to parse. 2002/01/01 Added AJOIN command to NickServ HELP COMMANDS. Reported by Russ Garrett 2002/01/01 Fixed bugs with MemoServ SET FORWARD and memo forwarding. Reported by Russ Garrett --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Sun Jan 13 11:03:43 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Hrm Message-ID: my last email didnt get through x-X here it is again. Idea: can the expire functions go into the database module so we dont have to flush the cache every time they're run? From achurch at achurch.org Mon Jan 14 04:08:47 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Services 5.0 alpha 12 released Message-ID: <3c41def7.13361@achurch.org> Services 5.0 alpha 12 has been released in the usual place (http://achurch.org/services/5.0-alpha/). This release contains many small changes, and one big change: import-db is (finally!) back, in the new "tools" subdirectory, and it now converts databases to XML on standard output instead of modifying the actual Services database files; those can be saved to disk and then imported using the XML import link from the httpd/dbaccess module. Changes in version 5.0a12 ------------------------- 2002/01/14 Services will now try to remove or raise the core dump size limit when configured with -dumpcore. 2002/01/14 Fixed bug causing -log command-line option to not work. 2002/01/14 Moved LogMaxUsers, WallGetpass, and WallSetpass to services.conf (where they belong). 2002/01/14 Made OperServ RESTART work correctly again. 2002/01/14 Fixed crash on REHASH when StatServ is in use. Reported by Martin Pels 2002/01/14 Fixed broken-connection log message to be slightly more useful. 2002/01/14 Fixed crash on remote SQUIT. Reported by Martin Pels 2002/01/13 Ignored data elements no longer cause XML importing to abort immediately. 2002/01/13 Fixed bug in XML import causing crashes when called twice. 2002/01/13 Removed trailing null bytes from passwords in XML export. 2002/01/13 Fixed bug in XML export causing crashes when OperServ SU password is not set. 2002/01/13 Rewrote import-db for 5.0; new database is now output as XML. 2002/01/11 Mode locks are now saved as character strings in XML export. --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Sun Jan 13 00:16:46 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Question Message-ID: do the nickinfo, chaninfo, and ngi iteration functions absolutely NEED to return in alphabetical order? also, suggestion: put expire_foo in database module so modules that cache dont need to reload the whole database and can expire nicks as they're loaded. From todd at doonga.net Sun Jan 13 23:48:59 2002 From: todd at doonga.net (Todd Punderson) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Bug Report for Services 5.0 alpha 12 In-Reply-To: <3c41def7.13361@achurch.org> Message-ID: <000001c19ccf$f07187a0$fe00a8c0@toddlaptop> Hello, I've been playing with the alpha version on a very small irc server I run. I ran into this problem after doing: nickserv forbid q nickserv forbid w nickserv forbid x operserv update ...segfaults After the segfault, the lock file is left in the database directory, the nick.db is 0 bytes and nick.db.save exists as the version before the forbids. I can reproduce this error over and over... This also happened in version alpha 11. I have included a chunk of the services.log entry and the gdb output. If you need any more information, I'll try to accommodate. I read through everything I could find and it didn't look like anyone reported this yet, so hopefully this will help! BTW, this isn't a complaint, just a report. :) Thanks! Todd Uname -a - FreeBSD todd-server.doonga.net 4.5-PRERELEASE FreeBSD 4.5-PRERELEASE #7: Sat Dec 22 14:30:34 EST 2001 todd@todd-server.doonga.net:/usr/obj/usr/src/sys/SMPKERNEL i386 Services.log - [Jan 14 02:32:32 2002] nickserv/main: Doonga!Doonga@DoongaNET set FORBID for nick q [Jan 14 02:32:34 2002] nickserv/main: Doonga!Doonga@DoongaNET set FORBID for nick w [Jan 14 02:32:36 2002] nickserv/main: Doonga!Doonga@DoongaNET set FORBID for nick x [Jan 14 02:32:40 2002] operserv/main: Doonga: update [Jan 14 02:32:40 2002] database/version4: nick q has no NickGroupInfo, setting password to nick GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... Core was generated by `services'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libc.so.4...done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/protocol/bahamut.so. ..done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/database/version4.so ...done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/mail/main.so...done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/mail/smtp.so...done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/operserv/main.so...d one. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/operserv/akill.so... done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/operserv/news.so...d one. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/operserv/sessions.so ...done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/operserv/sline.so... done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/nickserv/main.so...d one. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/nickserv/access.so.. .done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/nickserv/link.so...d one. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/nickserv/mail-auth.s o...done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/nickserv/sendpass.so ...done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/chanserv/main.so...d one. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/chanserv/access-leve ls.so...done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/chanserv/sendpass.so ...done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/memoserv/main.so...d one. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/memoserv/forward.so. ..done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/memoserv/ignore.so.. .done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/statserv/main.so...d one. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/misc/helpserv.so...d one. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/httpd/main.so...done . Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/httpd/auth-ip.so...d one. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/httpd/auth-password. so...done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/httpd/dbaccess.so... done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/httpd/redirect.so... done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/misc/xml-export.so.. .done. Reading symbols from /usr/home/todd/irc/ircservices/lib/services/modules/misc/xml-import.so.. .done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x2811f4db in sync_nick_db (dbname=0x813d940 "nick.db") at version4.c:550 550 if (irc_stricmp(ni->nick, ngi->nicks[ngi->mainnick]) != 0) { From achurch at achurch.org Mon Jan 14 18:05:46 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Bug Report for Services 5.0 alpha 12 Message-ID: <3c429fb2.16100@achurch.org> > I've been playing with the alpha version on a very small irc >server I run. I ran into this problem after doing: >nickserv forbid q >nickserv forbid w >nickserv forbid x >operserv update >...segfaults [...] >[Jan 14 02:32:40 2002] operserv/main: Doonga: update >[Jan 14 02:32:40 2002] database/version4: nick q has no NickGroupInfo, >setting password to nick [...] >#0 0x2811f4db in sync_nick_db (dbname=0x813d940 "nick.db") at >version4.c:550 >550 if (irc_stricmp(ni->nick, ngi->nicks[ngi->mainnick]) != >0) { Well, that was a pretty dumb one on my part... forbidden nicks aren't being handled correctly. Fixed, thanks for the report. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Mon Jan 14 18:36:42 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Question Message-ID: <3c42a734.20236@achurch.org> >do the nickinfo, chaninfo, and ngi iteration functions absolutely NEED to >return in alphabetical order? I don't _think_ anything will crash and burn if they don't, but NS/CS LIST and such return things in the same order they come out of first/next, so you'd end up with lists in random order >also, suggestion: put expire_foo in database module so modules that cache >dont need to reload the whole database and can expire nicks as they're >loaded. Already mentioned in private mail, but this sounds reasonable; I'll look into it. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Mon Jan 14 23:28:42 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Services 5.0 alpha 13 released Message-ID: <3c42eed0.27623@achurch.org> Well, it's only been about 2/3 of a day, but alpha 13 is out at the usual place. This takes care of the bug with forbidden nicks mentioned earlier, but more importantly, now saves the servicestamp of the last user to identify for a nick. This stops people from having to reidentify if Services goes down, but if I didn't implement it right could be a big fat security hole, so please check it and try to break it. Thanks. --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Mon Jan 14 12:11:56 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] DB Names Message-ID: IMHO, wouldn't it be more practical to put the DB filenames in the DB module instead of each module that uses a db? It makes sense that two different dbs would have different names (and mysql databases can't have .s in them) From achurch at achurch.org Tue Jan 15 06:07:38 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] DB Names Message-ID: <3c4348cf.27763@achurch.org> >IMHO, wouldn't it be more practical to put the DB filenames in the DB >module instead of each module that uses a db? It makes sense that two >different dbs would have different names (and mysql databases can't have >.s in them) So don't put dots in them, for crying out loud. That's what the config file is for. --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Mon Jan 14 13:12:22 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] DB Names In-Reply-To: <3c4348cf.27763@achurch.org> Message-ID: On Tue, 15 Jan 2002, Andrew Church wrote: > >IMHO, wouldn't it be more practical to put the DB filenames in the DB > >module instead of each module that uses a db? It makes sense that two > >different dbs would have different names (and mysql databases can't have > >.s in them) > > So don't put dots in them, for crying out loud. That's what the > config file is for. What I mean is put the DB name config item under the DB module, NOT the nickserv/chanserv etc modules > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From thebeast at xs4all.nl Mon Jan 14 13:42:27 2002 From: thebeast at xs4all.nl (Hans v Steenbergen) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] nickserv auth option and chanserv Message-ID: <3C4350C2.17A87BC3@xs4all.nl> Hello coders Just a quistion is there a option or is it a idea to put in a option that nicks that are registerd and not have made a Auth to nickserv to lock them out from registering a room -- Grtzz Hans v Steenbergen Mail me at thebeast@xs4all.nl Tech Admin on rc5proxy.mp3crew.nu www.mp3crew.nu for info about this irc server. mail to admins@mp3crew.nu for info The only one who got his work done by friday was R.Crusoe 10:35pm up 6 days, 4:09, 1 user, load average: 1.20, 1.12, 1.08 From todd at doonga.net Mon Jan 14 16:38:41 2002 From: todd at doonga.net (Todd Punderson) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] FW: Channel Time Setting issue Message-ID: <001501c19d5c$fe290de0$fe00a8c0@toddlaptop> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OOPS, Sent that last one with the wrong email account. Let's try this again.. Hello, I noticed this one in the services.log file. Not a show stopper by any means. protocol/bahamut: sjoin: unable to resolve symbol `get_channelinfo' in database module, channel time setting I poked around in the code a bit, but I'm not familiar with it enough yet to propose any patches. Thanks for the quick fix on the segfault! Todd -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPEN6EZsJsSKrNKqPEQJzsACg2Q/PPtWOS5GLTYhb/Q7EJKS5IM8Ani+V KZ/JSqmF2g5CbL4ClvpNQz7x =O6Ab -----END PGP SIGNATURE----- From achurch at achurch.org Tue Jan 15 11:04:53 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] FW: Channel Time Setting issue Message-ID: <3c438eed.35261@achurch.org> >protocol/bahamut: sjoin: unable to resolve symbol `get_channelinfo' >in database module, channel time setting What OS are you using (sorry, I frogot)? Have you tried using static modules (./configure -use-static-modules)? Does the patch below fix the problem? Index: modules.c =================================================================== RCS file: /var/cvs-private/ircservices/modules.c,v retrieving revision 2.41 diff -u -r2.41 modules.c --- modules.c 13 Jan 2002 17:57:34 -0000 2.41 +++ modules.c 15 Jan 2002 02:04:04 -0000 @@ -186,7 +186,22 @@ { #if !defined(STATIC_MODULES) +#if 0 return dlsym(handle ? handle : program_handle, symname); +#else + if (handle) { + return dlsym(handle, symname); + } else { + Module *mod; + void *ptr; + LIST_FOREACH (mod, modulelist) { + ptr = dlsym(mod->dllhandle?mod->dllhandle:program_handle, symname); + if (ptr) + return ptr; + } + return NULL; + } +#endif #else /* STATIC_MODULES */ --Andrew Church achurch@achurch.org http://achurch.org/ From todd at doonga.net Mon Jan 14 21:10:22 2002 From: todd at doonga.net (Todd Punderson) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] FW: Channel Time Setting issue In-Reply-To: <3c438eed.35261@achurch.org> Message-ID: <000701c19d82$f3a1efb0$fe00a8c0@toddlaptop> > What OS are you using (sorry, I frogot)? Have you tried using static > modules (./configure -use-static-modules)? Does the patch below fix the > problem? I'm running FreeBSD 4.5-PRERELEASE. I tried with -use-static-modules and that fixed it. So then I applied that patch, rm'ed config.cache and compiled without the static modules and the error was gone. Thanks again! Todd From Georges at Berscheid.lu Tue Jan 15 13:36:44 2002 From: Georges at Berscheid.lu (Georges Berscheid) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] channel KICK callback Message-ID: Hi, I've just got a small question. Wouldn't it be helpful in some cases to pass the kicker (i.e. the person who kicked the user) as a parameter to the callback function as well? Georges From achurch at achurch.org Wed Jan 16 07:34:44 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] channel KICK callback Message-ID: <3c44ae91.41473@achurch.org> >I've just got a small question. >Wouldn't it be helpful in some cases to pass the kicker (i.e. the person who >kicked the user) as a parameter to the callback function as well? Is there an actual need for this? --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Wed Jan 16 07:35:18 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] FW: Channel Time Setting issue Message-ID: <3c44aef6.41504@achurch.org> >> What OS are you using (sorry, I frogot)? Have you tried using >static >> modules (./configure -use-static-modules)? Does the patch below fix >the >> problem? > >I'm running FreeBSD 4.5-PRERELEASE. I tried with -use-static-modules and >that fixed it. So then I applied that patch, rm'ed config.cache and >compiled without the static modules and the error was gone. Okay, I guess FreeBSD doesn't automatically default to checking all modules when a symbol isn't found. I'll commit that change, then. (Note that you can disable static modules with ./configure -no-use-static-modules) --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Wed Jan 16 07:36:56 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] nickserv auth option and chanserv Message-ID: <3c44af19.41513@achurch.org> >Just a quistion is there a option or is it a idea to put in a option >that nicks that are registerd and not have made a Auth to nickserv >to lock them out from registering a room That's a good point, I'll look into it. --Andrew Church achurch@achurch.org http://achurch.org/ From Georges at Berscheid.lu Wed Jan 16 00:04:17 2002 From: Georges at Berscheid.lu (Georges Berscheid) Date: Sat Oct 23 23:09:12 2004 Subject: AW: [IRCServices Coding] channel KICK callback In-Reply-To: <3c44ae91.41473@achurch.org> Message-ID: Well, it's not an absolute must, but I was just recoding SeenServ (like bseen for eggdrops but MySQL-powered) I did for 4.5 as a module for version 5 when I saw that this parameter was missing. Georges -----Ursprungliche Nachricht----- Von: ircservices-coding-admin@ircservices.za.net [mailto:ircservices-coding-admin@ircservices.za.net]Im Auftrag von Andrew Church Gesendet: Dienstag, 15. Januar 2002 23:35 An: ircservices-coding@ircservices.za.net Betreff: Re: [IRCServices Coding] channel KICK callback >I've just got a small question. >Wouldn't it be helpful in some cases to pass the kicker (i.e. the person who >kicked the user) as a parameter to the callback function as well? Is there an actual need for this? --Andrew Church achurch@achurch.org http://achurch.org/ ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Wed Jan 16 22:20:17 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] nickserv auth option and chanserv Message-ID: <3c457e40.62426@achurch.org> >Just a quistion is there a option or is it a idea to put in a option >that nicks that are registerd and not have made a Auth to nickserv >to lock them out from registering a room That's a very good point--thanks. I'll include this in 5.0. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Fri Jan 18 01:39:40 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Services 5.0 alpha 14 released Message-ID: <3c46ff27.01713@achurch.org> I'm up way past my bedtime, but it was worth it: Services 5.0 alpha 14 is out at the usual place (or will be shortly, it's still uploading at the moment). Please forgive the lack of a witty comment here; my tired mind can't think one up. Changes in version 5.0a14 ------------------------- 2002/01/18 Fixed lots of errors in import-db. 2002/01/17 Added trircd handler to import-db. 2002/01/17 import-db no longer imports channel access levels (LEVELS command settings); all channels are reset to default. 2002/01/16 Changed default access level for ACC-CHANGE to 4 to match behavior for *OP (HOP users allowed to add VOPs). 2002/01/16 Removed unneeded code in ChanServ do_opvoice(). 2002/01/16 Added ChanServ KICK command. Suggested by Yusuf Iskenderoglu 2002/01/16 ChanServ REGISTER now requires identification, not just recognition, for the registering user's nick. Suggested by Hans v Steenbergen 2002/01/16 Fixed bug causing module symbols to not resolve under FreeBSD. Reported by Todd Punderson 2002/01/15 Added quote parsing to allow SGLINEs with spaces in them. Reported by Yusuf Iskenderoglu --Andrew Church achurch@achurch.org http://achurch.org/ From v13 at it.teithe.gr Sun Jan 20 08:27:22 2002 From: v13 at it.teithe.gr (v13@it.teithe.gr) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Request... Message-ID: <200201201627.SAA28919@ppp0.the.forthnet.gr> With SplitRecovery, users that were connected before split will not be asked for a password. I believe that Logon News should also be stoped. (This may save a lot of useless traffic) <> From griever at t2n.org Sun Jan 20 08:31:16 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Re: idea about database names In-Reply-To: Message-ID: On Sun, 20 Jan 2002, Finny Merrill wrote: > I think the [open|sync|close]_x_db functions should really all be handled > by one function each (open_databases etc). > > The way MySQL works, it would be easier for AKILL, S-lines and other > operserv things to be handled in one database > > wrong email address... From achurch at achurch.org Mon Jan 21 23:48:36 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Services 5.0 alpha 15 released Message-ID: <3c4c2f67.17534@achurch.org> Services 5.0 alpha 15 is out at the usual place. No major functional changes in this release, but a whole bunch of reorganization and renaming of files, and two new, completely untested meta-features: (1) RPM and .deb binary packages, available at the same place as the tarball--try them out and let me know of any problems, especially ones that blow up your box-- and (2) preliminary Win32 support via Cygwin; I'll let you all have a flamefest over that one while I get some much-needed sleep. Oh, and I'm well aware that the HTML documentation for convert-db (the new name for import-db) isn't done, so please don't bother sending mail to tell me so. (: Changes in version 5.0 alpha 15 ------------------------------- 2002/01/21 Added preliminary Win32 support via Cygwin. Assistance from Andre Arruda 2002/01/21 Changed hostmask creation code to only mask off the last part of an IP address, even for (former) class A/B addresses. Suggested by Sly. 2002/01/21 Fixed bug parsing incomplete user@host masks. Reported by Sly. 2002/01/21 convert-db is now installed in data directory by make install. 2002/01/21 Renamed executable file from "services" to "ircservices", and main configuration file to "ircservices.conf". 2002/01/21 "make spotless" target may now also be called as "distclean". 2002/01/21 Fixed cosmetic bug in "configuration file not found" error. 2002/01/21 Removed dependency on Perl for static compilation. 2002/01/20 Fixed bug in usage of `tar' program. 2002/01/19 Added NOQUIT support to trircd protocol module. Suggested by Yusuf Iskenderoglu 2002/01/19 Renamed import-db to convert-db. 2002/01/18 Made PTlink database importing more robust. 2002/01/18 Fixed bug causing import-db to fail with trircd databases. Reported by Yusuf Iskenderoglu --Andrew Church achurch@achurch.org http://achurch.org/ From thebeast at xs4all.nl Mon Jan 21 13:50:42 2002 From: thebeast at xs4all.nl (Hans v Steenbergen) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] something to put on your todo list ?? Message-ID: <3C4C8D31.D83359C6@xs4all.nl> hello Andrew thanks for the quick fix with the auth part ;) we will are testing it now you have created a email part i got the idea to use it also for warnings wen a nick or channel will expire is there a way to send a email to the user XX days before the nick will expire or is this idea already some where on your todo list ? (Asking my self now is your todo list for ircservices 5 some where on line?? ) -- Grtzz Hans v Steenbergen Mail me at thebeast@xs4all.nl Tech Admin on rc5proxy.mp3crew.nu www.mp3crew.nu for info about this irc server. mail to admins@mp3crew.nu for info The only one who got his work done by friday was R.Crusoe 10:40pm up 13 days, 4:14, 1 user, load average: 1.00, 1.00, 1.00 From achurch at achurch.org Tue Jan 22 08:36:28 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Request... Message-ID: <3c4ca652.27732@achurch.org> > With SplitRecovery, users that were connected before split will not be a >sked >for a password. I believe that Logon News should also be stoped. (This ma >y >save a lot of useless traffic) This isn't easy to do in the current framework, but you're right in principle, and I'll take a look and see how feasible it is. ><> > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Jan 22 08:39:37 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Re: idea about database names Message-ID: <3c4ca703.27746@achurch.org> >On Sun, 20 Jan 2002, Finny Merrill wrote: > >> I think the [open|sync|close]_x_db functions should really all be handled >> by one function each (open_databases etc). And just how do you plan to handle having some modules loaded and not others? >> The way MySQL works, it would be easier for AKILL, S-lines and other >> operserv things to be handled in one database So use tables for crying out loud. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Jan 22 08:41:43 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] something to put on your todo list ?? Message-ID: <3c4ca771.27757@achurch.org> >now you have created a email part i got the idea to use it also for >warnings >wen a nick or channel will expire is there a way to send a email to the >user >XX days before the nick will expire or is this idea already some where >on >your todo list ? That's an interesting idea, I'll think about it. >(Asking my self now is your todo list for ircservices 5 some where on >line?? ) No, but you can always grab it from the latest tarball. --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Mon Jan 21 15:59:24 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Re: idea about database names In-Reply-To: <3c4ca703.27746@achurch.org> Message-ID: On Tue, 22 Jan 2002, Andrew Church wrote: > >On Sun, 20 Jan 2002, Finny Merrill wrote: > > > >> I think the [open|sync|close]_x_db functions should really all be handled > >> by one function each (open_databases etc). > > And just how do you plan to handle having some modules loaded and not > others? Err.... ya > > >> The way MySQL works, it would be easier for AKILL, S-lines and other > >> operserv things to be handled in one database > > So use tables for crying out loud. Well I thought it would be kind of a hack if the AKILL table had a different name for every database. I guess what I'm really getting at is to have the database names under the database module instead of under the individual modules. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From achurch at achurch.org Tue Jan 22 09:46:44 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Re: idea about database names Message-ID: <3c4cb7e1.30036@achurch.org> >> >> The way MySQL works, it would be easier for AKILL, S-lines and other >> >> operserv things to be handled in one database >> >> So use tables for crying out loud. > >Well I thought it would be kind of a hack if the AKILL table had a >different name for every database. I guess what I'm really getting at is >to have the database names under the database module instead of under >the individual modules. The current database system works the same way and I don't see any problems with it. Besides, if you do want to do it all in one table, there's nothing that says you can't do it that way... though I do see what you're getting at with database/table names. I'll think about it. --Andrew Church achurch@achurch.org http://achurch.org/ From Kevc at gmx.co.uk Tue Jan 22 14:49:03 2002 From: Kevc at gmx.co.uk (Kevin (BT)) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Cosmetic Bug with Enforcer Message-ID: <1472095903.20020122224903@gmx.co.uk> Hi All, IRCServices 5.0 seem Pretty stable, although ive only had them running for a day. I havent noticed any problems except 1, when my nick was enforced, i did a whois on the Enforcer and it returned this weird line.. | Kevc (@ail/sendmail) | name : NickServ Enforcement | serv : Wont.Spam.Server.Net any ideas? Regards, -- Kevin Conlin BT Operator http://www.darkserv.net Kevc@gmx.co.uk Running The Bat! 1.54 Beta/18 on Windows XP 5.1 -- From achurch at achurch.org Wed Jan 23 16:17:01 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Cosmetic Bug with Enforcer Message-ID: <3c4e6386.67040@achurch.org> >I havent noticed any problems except 1, when my nick was enforced, i >did a whois on the Enforcer and it returned this weird line.. > >| Kevc (@ail/sendmail) >| name : NickServ Enforcement >| serv : Wont.Spam.Server.Net This looks like something isn't being copied when it should be; I'll look into this. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Wed Jan 23 22:42:08 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Cosmetic Bug with Enforcer Message-ID: <3c4ebde8.77217@achurch.org> >I havent noticed any problems except 1, when my nick was enforced, i >did a whois on the Enforcer and it returned this weird line.. > >| Kevc (@ail/sendmail) >| name : NickServ Enforcement >| serv : Wont.Spam.Server.Net This doesn't happen for me. Can you reproduce it, and if so how? --Andrew Church achurch@achurch.org http://achurch.org/ From Kevc at gmx.co.uk Wed Jan 23 13:07:49 2002 From: Kevc at gmx.co.uk (Kevin (BT)) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Cosmetic Bug with Enforcer In-Reply-To: <3c4ebde8.77217@achurch.org> References: <3c4ebde8.77217@achurch.org> Message-ID: <1621865171.20020123210749@gmx.co.uk> The Current Stats of the Server at the time were: IRCd: Unreal3.2 Beta 6 I just didnt identify to my Nickname, my nickname was changed and when i tried to Change it back, it said my nick was in use and showed that screen. Regards, -- Kevin Conlin BT Operator http://www.darkserv.net Kevc@gmx.co.uk Running The Bat! 1.54 Beta/18 on Windows XP 5.1 -- From achurch at achurch.org Thu Jan 24 06:50:36 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Cosmetic Bug with Enforcer Message-ID: <3c4f305c.24366@achurch.org> >The Current Stats of the Server at the time were: > >IRCd: Unreal3.2 Beta 6 > >I just didnt identify to my Nickname, my nickname was changed and when >i tried to Change it back, it said my nick was in use and showed that >screen. That doesn't help me; I need to know if you can reproduce the same thing every time you try, --Andrew Church achurch@achurch.org http://achurch.org/ From Kevc at gmx.co.uk Wed Jan 23 14:04:51 2002 From: Kevc at gmx.co.uk (Kevin (BT)) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Cosmetic Bug with Enforcer In-Reply-To: <3c4f305c.24366@achurch.org> References: <3c4f305c.24366@achurch.org> Message-ID: <1125287102.20020123220451@gmx.co.uk> This was Fixed after a Restart. Cannot seem to reproduce. Regards, -- Kevin Conlin BT Operator http://www.darkserv.net Kevc@gmx.co.uk Running The Bat! 1.54 Beta/18 on Windows XP 5.1 -- From andrewk at isdial.net Wed Jan 23 22:02:38 2002 From: andrewk at isdial.net (Andrew Kempe) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Cosmetic Bug with Enforcer References: <3c4f305c.24366@achurch.org> <1125287102.20020123220451@gmx.co.uk> Message-ID: <003d01c1a49c$b9f5ed40$9c011ac4@africa.didata.local> A restart of the ircd or services? Andrew ----- Original Message ----- From: "Kevin (BT)" To: "Andrew Church" Sent: Thursday, January 24, 2002 12:04 AM Subject: Re[4]: [IRCServices Coding] Cosmetic Bug with Enforcer > This was Fixed after a Restart. > > Cannot seem to reproduce. > > > > Regards, > > -- > > Kevin Conlin > BT Operator > http://www.darkserv.net > Kevc@gmx.co.uk > Running The Bat! 1.54 Beta/18 on Windows XP 5.1 > > -- > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > From Kevc at gmx.co.uk Wed Jan 23 22:09:46 2002 From: Kevc at gmx.co.uk (Kevin (BT)) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Cosmetic Bug with Enforcer In-Reply-To: <003d01c1a49c$b9f5ed40$9c011ac4@africa.didata.local> References: <3c4f305c.24366@achurch.org> <1125287102.20020123220451@gmx.co.uk> <003d01c1a49c$b9f5ed40$9c011ac4@africa.didata.local> Message-ID: <2134383751.20020124060946@gmx.co.uk> Restarted Services, i changed the enforcer option from Enforcer@DarkServ.Net to just Enforcer.. seemed to work pretty good Regards, -- Kevin Conlin BT Operator http://www.darkserv.net Kevc@gmx.co.uk Running The Bat! 1.54 Beta/18 on Windows XP 5.1 -- From achurch at achurch.org Thu Jan 24 19:26:58 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Services 5.0 alpha 16 released Message-ID: <3c4fe414.07403@achurch.org> Services 5.0 alpha 16 has been released at the usual place. This release is mainly to take care of a whole bunch of FIXMEs in the code; I'll get to the recent suggestions and stuff soon. Also, I'd like to get this as stable as possible before releasing a beta version; please let me know of any problems ASAP. Changes in version 5.0a16 ------------------------- 2002/01/24 MemoServ no longer requires ChanServ to load. 2002/01/24 Sessions module (operserv/sessions) no longer requires autokill module in order to load. 2002/01/24 Got OperServ LISTSERVERS debug command working. 2002/01/24 Fixed bug causing time of maximum user count to be set to maximum user count. 2002/01/24 Fixed a cosmetic bug in OperServ STATS uptime display. 2002/01/24 Fixed up OperServ STATS ALL processing. 2002/01/24 Channel last-used time properly set again on auto-op. 2002/01/23 Fixed several bugs in channel auto-mode handling. 2002/01/23 Fixed GLINE (autokill) handling on ircu 2.9.32. 2002/01/23 Main nick now indicated by "*" in NickServ LISTLINKS. 2002/01/23 NickServ UNLINK now sets main nick to current nick when unlinking main nick. 2002/01/23 Fixed bug causing main nick to change on UNLINK. 2002/01/23 Fixed memory leak with -log command-line option. 2002/01/23 Fixed handling of overlong mode parameters in set_cmode(). 2002/01/22 Made pack_ip() syntax check more robust. 2002/01/22 username@[IP-address] E-mail addresses are now permitted. 2002/01/22 Added checks on configuration parameter values for systems with a 64-bit `long' type. 2002/01/22 Users who get changed to guest nicks will no longer be affected by SQlines on guest nicks. 2002/01/22 If a client matches an SQline (and no SGline or SZline) and the IRC server supports forced nick changes, the client will be sent a 432 (invalid nickname) reply and have its nick changed instead of being killed. 2002/01/22 A 433 (nick in use) reply is no longer sent as soon as a client connects with a registered nickname. --Andrew Church achurch@achurch.org http://achurch.org/ From v13 at it.teithe.gr Thu Jan 24 16:06:59 2002 From: v13 at it.teithe.gr (v13@it.teithe.gr) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Enforced nicknames Message-ID: <200201250007.CAA04944@ppp700.the.forthnet.gr> I see many people using the changed nicknames. (XXX-number in our net). It may be useful to kill them after.. lets say.. X minutes... Also, why kill with 'too many passwords' and not just change and enforce their nick and put an ignore on them for some time ? This should work better for brute force attacks (if any) <> From achurch at achurch.org Fri Jan 25 10:41:53 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Enforced nicknames Message-ID: <3c50b868.15261@achurch.org> > I see many people using the changed nicknames. (XXX-number in our net). >It may be useful to kill them after.. lets say.. X minutes... Why? >Also, why kill with 'too many passwords' and not just change and enforce >their >nick and put an ignore on them for some time ? This should work better fo >r >brute force attacks (if any) And what would stop them from reconnecting manually/automatically? An auto-AKILL solution is already in the works. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Fri Jan 25 10:41:53 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Enforced nicknames Message-ID: <3c50b868.15261@achurch.org> > I see many people using the changed nicknames. (XXX-number in our net). >It may be useful to kill them after.. lets say.. X minutes... Why? >Also, why kill with 'too many passwords' and not just change and enforce >their >nick and put an ignore on them for some time ? This should work better fo >r >brute force attacks (if any) And what would stop them from reconnecting manually/automatically? An auto-AKILL solution is already in the works. --Andrew Church achurch@achurch.org http://achurch.org/ From v13 at it.teithe.gr Thu Jan 24 20:03:22 2002 From: v13 at it.teithe.gr (v13@it.teithe.gr) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Enforced nicknames In-Reply-To: <3c50b868.15261@achurch.org> References: <3c50b868.15261@achurch.org> Message-ID: <200201250403.GAA07460@ppp700.the.forthnet.gr> On Friday 25 January 2002 12:41, Andrew Church wrote: > > I see many people using the changed nicknames. (XXX-number in our net). > >It may be useful to kill them after.. lets say.. X minutes... > > Why? *** XXX-66156451613046 has been idle 2 minutes, signed on at Fri Jan 25 05:36:25 2002 *** XXX-62156451512457 has been idle 1 minutes, signed on at Fri Jan 25 05:27:20 2002 *** XXX-1085196303245 has been idle 10 seconds, signed on at Thu Jan 24 13:47:28 2002 *** XXX-11156432583997 has been idle 276 minutes, signed on at Wed Jan 23 22:34:52 2002 *** XXX-1156431683934 has been idle 301 minutes, signed on at Thu Jan 24 21:32:59 2002 *** XXX-19155941152125 has been idle 4666 minutes, signed on at Tue Jan 22 00:07:33 2002 Those users are not going to change their nicks unless forced Local time is 05.57am. This is the time with the minimal users on-line on our net... During midnight, there are many many more... I suppose this happens on other nets too > --Andrew Church <> p.s. Do you know if it is safe to q-line XXX-* ? Afaik SVSNICK still works, but is it ok? From achurch at achurch.org Fri Jan 25 13:57:10 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Enforced nicknames Message-ID: <3c50e642.21515@achurch.org> >> > I see many people using the changed nicknames. (XXX-number in our net >). >> >It may be useful to kill them after.. lets say.. X minutes... >> >> Why? [...] >*** XXX-19155941152125 has been idle 4666 minutes, signed on at Tue Jan 2 >2 00:07:33 2002 > >Those users are not going to change their nicks unless forced And again I ask: why is this a problem? If they want to stay with the guest nicks, I see nothing wrong with that. You can't register them anyway. >p.s. Do you know if it is safe to q-line XXX-* ? Afaik SVSNICK still work >s, but is it ok? Yes, there's no problem with adding Q:lines to servers for this. Using the SQLINE command for this does _not_ work at the moment (Services will get into an infinite loop guesting people), but I'll fix this sooner or later. --Andrew Church achurch@achurch.org http://achurch.org/ From jh at fxpers.net Sat Jan 26 04:41:05 2002 From: jh at fxpers.net (JH) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] bug in alpha 16 ? Message-ID: <00ff01c1a666$b9a86360$0a01a8c0@jespers> hey all i have configured and trying to link services up but get this error [Jan 26 13:50:38.921017 2002] debug: Sent: :ChanServ MODE ChanServ +o [Jan 26 13:50:38.921052 2002] debug: Received: :ceres.dk.eu.sp33d.net KILL MemoServ :ceres.dk.eu.sp33d.net (MemoServ(?) <- services.sp33d.net[unknown@localhost]) [Jan 26 13:50:38.921094 2002] FATAL: introduce_user() loop detected [Jan 26 13:50:38.921176 2002] debug: Sent: :services.sp33d.net GLOBOPS :FATAL ERROR! introduce_user() loo p detected you got any ideas ? regards JH From ron885 at axenet.org Sat Jan 26 07:56:15 2002 From: ron885 at axenet.org (Ron885) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] bug in alpha 16 ? References: <00ff01c1a666$b9a86360$0a01a8c0@jespers> Message-ID: <002501c1a681$fc7cbdb0$b9340344@HOME> > [Jan 26 13:50:38.921176 2002] debug: Sent: :services.sp33d.net GLOBOPS > :FATAL ERROR! introduce_user() loo > p detected > > you got any ideas ? you have a memoserv already online and when you start services it can't handle that memoserv there and it tries to connect its client repeatedly till it crashes. --- Ron885 TechAdmin @ irc.axenet.org From achurch at achurch.org Sun Jan 27 01:01:59 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] bug in alpha 16 ? Message-ID: <3c52d309.64065@achurch.org> >hey all > >i have configured and trying to link services up > >but get this error > >[Jan 26 13:50:38.921017 2002] debug: Sent: :ChanServ MODE ChanServ +o >[Jan 26 13:50:38.921052 2002] debug: Received: :ceres.dk.eu.sp33d.net KILL >MemoServ :ceres.dk.eu.sp33d.net > (MemoServ(?) <- services.sp33d.net[unknown@localhost]) Do you have the correct protocol module loaded? --Andrew Church achurch@achurch.org http://achurch.org/ From jh at fxpers.net Sat Jan 26 08:20:23 2002 From: jh at fxpers.net (JH) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] bug in alpha 16 ? References: <00ff01c1a666$b9a86360$0a01a8c0@jespers> <002501c1a681$fc7cbdb0$b9340344@HOME> Message-ID: <011701c1a685$5f0886a0$0a01a8c0@jespers> i have no other services online... there is only my server and the services i have set protocol dreamforce for ultimateircd hope that helps a little more regards JH ----- Original Message ----- From: "Ron885" To: Sent: Saturday, January 26, 2002 4:56 PM Subject: Re: [IRCServices Coding] bug in alpha 16 ? > > > > [Jan 26 13:50:38.921176 2002] debug: Sent: :services.sp33d.net GLOBOPS > > :FATAL ERROR! introduce_user() loo > > p detected > > > > you got any ideas ? > > you have a memoserv already online and when you start services it can't handle > that memoserv there and it tries to connect its client repeatedly till it > crashes. > --- > Ron885 > TechAdmin @ irc.axenet.org > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From atcarr at hotmail.com Sun Jan 27 05:44:08 2002 From: atcarr at hotmail.com (Alan Carr) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Problem with alpha16? In-Reply-To: <002501c1a681$fc7cbdb0$b9340344@HOME> Message-ID: <000801c1a738$b18d01e0$0201a8c0@phantomnet.net> I finally got around to compiling alpha16 of IRCServices for testing on my test network. Compile worked fine with no errors reported. I edited the new Configuration files and attempted to load the server only to get Initialization failed, exiting. I checked the log file to find this message: [Jan 27 08:45:32 2002] IRC Services 5.0a14 starting up [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 0 (en_us) [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 10 (nl) [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 9 (de) [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 8 (it) [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 2 (ja_euc) [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 3 (ja_sjis) [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 5 (pt) [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 4 (es) [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 7 (tr) [Jan 27 08:45:32 2002] modules: Unable to load module `protocol/bahamut': /home/servers/test/services/modules/protocol/bahamut.so: $ [Jan 27 08:45:32 2002] Error loading modules, aborting I have run through testing all the protocols which might work with my dreamforge derived server with no success. This could be just me however I don't know. Phantom From Georges at Berscheid.lu Sun Jan 27 05:51:13 2002 From: Georges at Berscheid.lu (Georges Berscheid) Date: Sat Oct 23 23:09:12 2004 Subject: AW: [IRCServices Coding] Problem with alpha16? In-Reply-To: <000801c1a738$b18d01e0$0201a8c0@phantomnet.net> Message-ID: Hi, [Jan 27 08:45:32 2002] IRC Services 5.0a14 starting up <-- seems like 'gmake install' didn't replace your binary since you were still running alpha14 instead of alpha16. Georges -----Urspr?ngliche Nachricht----- Von: ircservices-coding-admin@ircservices.za.net [mailto:ircservices-coding-admin@ircservices.za.net]Im Auftrag von Alan Carr Gesendet: Sonntag, 27. Januar 2002 14:44 An: ircservices-coding@ircservices.za.net Betreff: [IRCServices Coding] Problem with alpha16? I finally got around to compiling alpha16 of IRCServices for testing on my test network. Compile worked fine with no errors reported. I edited the new Configuration files and attempted to load the server only to get Initialization failed, exiting. I checked the log file to find this message: [Jan 27 08:45:32 2002] IRC Services 5.0a14 starting up [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 0 (en_us) [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 10 (nl) [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 9 (de) [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 8 (it) [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 2 (ja_euc) [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 3 (ja_sjis) [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 5 (pt) [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 4 (es) [Jan 27 08:45:32 2002] Warning: Bad number of strings (1098, wanted 1104) for language 7 (tr) [Jan 27 08:45:32 2002] modules: Unable to load module `protocol/bahamut': /home/servers/test/services/modules/protocol/bahamut.so: $ [Jan 27 08:45:32 2002] Error loading modules, aborting I have run through testing all the protocols which might work with my dreamforge derived server with no success. This could be just me however I don't know. Phantom ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From atcarr at hotmail.com Sun Jan 27 05:56:38 2002 From: atcarr at hotmail.com (Alan Carr) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Problem with alpha16? In-Reply-To: <000801c1a738$b18d01e0$0201a8c0@phantomnet.net> Message-ID: <000201c1a73a$70c0a660$0201a8c0@phantomnet.net> Actually forget this one. It was of course my mistake. Somehow I didn't change over to make sure the system was using the same start program so instead of typing ./ircservices I typed ./services. Sorry Phantom From martinpels at hotmail.com Sun Jan 27 08:50:02 2002 From: martinpels at hotmail.com (Martin Pels) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] NICK_OPER_HELP_SET never used? Message-ID: When I type "/msg nickserv help set" the content of NICK_OPER_HELP_SET is not shown. With ChanServ the problem doesn't occur: CHAN_OPER_HELP_SET is included with the reply to "/msg chanserv help set". The version i'm using is Alpha16. Setting the language to a different setting doesn't make any difference. Greetz, Rodecker From achurch at achurch.org Mon Jan 28 08:18:06 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] NICK_OPER_HELP_SET never used? Message-ID: <3c548ab6.73072@achurch.org> >When I type "/msg nickserv help set" the content of NICK_OPER_HELP_SET is >not shown. Fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Mon Jan 28 08:29:53 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] bug in alpha 16 ? Message-ID: <3c548d7f.73450@achurch.org> >i have no other services online... there is only my server and the services > >i have set protocol dreamforce for ultimateircd What version of Ultimate are you using? --Andrew Church achurch@achurch.org http://achurch.org/ >hope that helps a little more > >regards >JH > >----- Original Message ----- >From: "Ron885" >To: >Sent: Saturday, January 26, 2002 4:56 PM >Subject: Re: [IRCServices Coding] bug in alpha 16 ? > > >> >> >> > [Jan 26 13:50:38.921176 2002] debug: Sent: :services.sp33d.net GLOBOPS >> > :FATAL ERROR! introduce_user() loo >> > p detected >> > >> > you got any ideas ? >> >> you have a memoserv already online and when you start services it can't >handle >> that memoserv there and it tries to connect its client repeatedly till it >> crashes. >> --- >> Ron885 >> TechAdmin @ irc.axenet.org >> >> ------------------------------------------------------------------ >> To unsubscribe or change your subscription options, visit: >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding >> > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From jh at fxpers.net Sun Jan 27 15:39:32 2002 From: jh at fxpers.net (JH) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] bug in alpha 16 ? References: <3c548d7f.73450@achurch.org> Message-ID: <004c01c1a78b$df41aac0$0a01a8c0@jespers> i'm using Ultimate3.0.0.a18 and ircservices-5.0a16 regards JH ----- Original Message ----- From: "Andrew Church" To: Sent: Monday, January 28, 2002 12:29 AM Subject: Re: [IRCServices Coding] bug in alpha 16 ? > >i have no other services online... there is only my server and the services > > > >i have set protocol dreamforce for ultimateircd > > What version of Ultimate are you using? > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > > >hope that helps a little more > > > >regards > >JH > > > >----- Original Message ----- > >From: "Ron885" > >To: > >Sent: Saturday, January 26, 2002 4:56 PM > >Subject: Re: [IRCServices Coding] bug in alpha 16 ? > > > > > >> > >> > >> > [Jan 26 13:50:38.921176 2002] debug: Sent: :services.sp33d.net GLOBOPS > >> > :FATAL ERROR! introduce_user() loo > >> > p detected > >> > > >> > you got any ideas ? > >> > >> you have a memoserv already online and when you start services it can't > >handle > >> that memoserv there and it tries to connect its client repeatedly till it > >> crashes. > >> --- > >> Ron885 > >> TechAdmin @ irc.axenet.org > >> > >> ------------------------------------------------------------------ > >> To unsubscribe or change your subscription options, visit: > >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > >> > > > >------------------------------------------------------------------ > >To unsubscribe or change your subscription options, visit: > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From achurch at achurch.org Mon Jan 28 09:01:17 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] bug in alpha 16 ? Message-ID: <3c54950f.74572@achurch.org> >i'm using Ultimate3.0.0.a18 and ircservices-5.0a16 Then the answer is that version 3.0.0 doesn't work with Services, and you need to use a different ircd. --Andrew Church achurch@achurch.org http://achurch.org/ >regards >JH > >----- Original Message ----- >From: "Andrew Church" >To: >Sent: Monday, January 28, 2002 12:29 AM >Subject: Re: [IRCServices Coding] bug in alpha 16 ? > > >> >i have no other services online... there is only my server and the >services >> > >> >i have set protocol dreamforce for ultimateircd >> >> What version of Ultimate are you using? >> >> --Andrew Church >> achurch@achurch.org >> http://achurch.org/ >> >> >hope that helps a little more >> > >> >regards >> >JH >> > >> >----- Original Message ----- >> >From: "Ron885" >> >To: >> >Sent: Saturday, January 26, 2002 4:56 PM >> >Subject: Re: [IRCServices Coding] bug in alpha 16 ? >> > >> > >> >> >> >> >> >> > [Jan 26 13:50:38.921176 2002] debug: Sent: :services.sp33d.net >GLOBOPS >> >> > :FATAL ERROR! introduce_user() loo >> >> > p detected >> >> > >> >> > you got any ideas ? >> >> >> >> you have a memoserv already online and when you start services it can't >> >handle >> >> that memoserv there and it tries to connect its client repeatedly till >it >> >> crashes. >> >> --- >> >> Ron885 >> >> TechAdmin @ irc.axenet.org >> >> >> >> ------------------------------------------------------------------ >> >> To unsubscribe or change your subscription options, visit: >> >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding >> >> >> > >> >------------------------------------------------------------------ >> >To unsubscribe or change your subscription options, visit: >> >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding >> ------------------------------------------------------------------ >> To unsubscribe or change your subscription options, visit: >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding >> > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From ShadowMaster at Shadow-Realm.org Sun Jan 27 16:04:11 2002 From: ShadowMaster at Shadow-Realm.org (Thomas J. =?iso-8859-1?q?Stens=E5s?=) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] bug in alpha 16 ? In-Reply-To: <004c01c1a78b$df41aac0$0a01a8c0@jespers> References: <3c548d7f.73450@achurch.org> <004c01c1a78b$df41aac0$0a01a8c0@jespers> Message-ID: <200201280004.g0S04Cr31625@villageirc.net> On Monday 28 January 2002 00:39, you wrote: > i'm using Ultimate3.0.0.a18 and ircservices-5.0a16 UltimateIRCd3.0.0 alpha's are based on the bahamut protocol. I'll make sure to have this clearly noted in the FAQ and README files in the next snapshot. -- Yours Sincerely Thomas Juberg Stens?s -- What we do in life echoes in eternity. DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/ From achurch at achurch.org Mon Jan 28 13:33:02 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Services 5.0 alpha 17 released Message-ID: <3c54d50c.26261@achurch.org> Services 5.0 alpha 17 has been released at the usual place. This takes care of several bugs reported to me, adds the OperServ SERVERMAP command (I _think_ it works right), and gets rid of some way-out-of-date bloat. Changes in version 5.0a17 ------------------------- 2002/01/28 Fixed BUG message occurring when a nick with registered channels was dropped. Reported by Martin Pels 2002/01/28 Fixed potential crash when dropping in-use channels. 2002/01/28 Fixed crash when expiring nicks with registered channels. Reported by Martin Pels 2002/01/28 Fixed bug causing oper help for NickServ SET to not be shown. Reported by Martin Pels 2002/01/28 Fixed bug in MemoServ SET LIMIT where DEFAULT was interpreted as 0 and anything else as DEFAULT. Reported by Martin Pels 2002/01/28 Removed IrcIIHelp pseudoclient and ircII help files. 2002/01/24 Fixed bug in configure that caused the data directory to be asked for on the first run even if -defaults was given. 2002/01/24 Added the OperServ SERVERMAP command. --Andrew Church achurch@achurch.org http://achurch.org/ From jh at fxpers.net Sun Jan 27 22:31:15 2002 From: jh at fxpers.net (JH) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] bug in alpha 16 ? References: <3c548d7f.73450@achurch.org> <004c01c1a78b$df41aac0$0a01a8c0@jespers> <200201280004.g0S04Cr31625@villageirc.net> Message-ID: <006601c1a7c5$62e909c0$0a01a8c0@jespers> thanx with that an version a17 it now works regards JH ----- Original Message ----- From: "Thomas J. Stens?s" To: Sent: Monday, January 28, 2002 1:04 AM Subject: Re: [IRCServices Coding] bug in alpha 16 ? > On Monday 28 January 2002 00:39, you wrote: > > i'm using Ultimate3.0.0.a18 and ircservices-5.0a16 > > UltimateIRCd3.0.0 alpha's are based on the bahamut protocol. > > I'll make sure to have this clearly noted in the FAQ and README files in the > next snapshot. > > -- > Yours Sincerely > > Thomas Juberg Stens?s > > -- What we do in life echoes in eternity. > > DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From martinpels at hotmail.com Mon Jan 28 14:18:07 2002 From: martinpels at hotmail.com (Martin Pels) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] 2 small bugs References: <3c54d50c.26261@achurch.org> Message-ID: 1. when using nickserv dropnick the dropped nick gets displayed as (null) for example, when doing: /msg nickserv dropnick FooBar Services replies: [12:29] -NickServ- Nickname (null) and all linked nicknames have been dropped. 2. When a registered nickname does not have a last quit message in its info display the following happens when viewing the info online: Registered to: FooBar Time registered: Dec 31 14:05:38 2001 Last seen address: foo@bar Last seen on: Jan 20 23:26:57 2002 Last quit message: Jan 20 23:26:57 2002 The last quitmessage should be empty here. Instead the Last seen on value gets shown again, and the services logfile shows a bug: [Jan 28 23:10:37 2002] httpd/main: BUG: http_quote_html(): str is NULL! From achurch at achurch.org Tue Jan 29 08:36:40 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] 2 small bugs Message-ID: <3c55e099.04657@achurch.org> Both fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ >1. >when using nickserv dropnick the dropped nick gets displayed as (null) > >for example, when doing: /msg nickserv dropnick FooBar >Services replies: >[12:29] -NickServ- Nickname (null) and all linked nicknames have been >dropped. > >2. >When a registered nickname does not have a last quit message in its info >display the following happens when viewing the info online: > > Registered to: FooBar > Time registered: Dec 31 14:05:38 2001 > Last seen address: foo@bar > Last seen on: Jan 20 23:26:57 2002 > Last quit message: Jan 20 23:26:57 2002 > > >The last quitmessage should be empty here. Instead the Last seen on value >gets shown again, and the services logfile shows a bug: >[Jan 28 23:10:37 2002] httpd/main: BUG: http_quote_html(): str is NULL! > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From todd at doonga.net Wed Jan 30 00:34:45 2002 From: todd at doonga.net (Todd Punderson) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Fwd: Possible Bug? (or am I misinterpreting something?) Message-ID: <20020129083615.1110E17466@snow.fingers.co.za> Hello, Ooops, accidentally posted this to the wrong list... Under alpha 17, I have a channel set up like this: ChanServ: Information for channel #doonga: ChanServ: Founder: Doonga ChanServ: Description: DoongaNET IRC Main Help Channel ChanServ: Registered: Jan 15 00:02:31 2002 EST ChanServ: Last used: Jan 28 20:59:33 2002 EST ChanServ: Last topic: Welcome to DoongaNET IRC. Please be patient and an admin (@ or +) will be along soon to help you. ChanServ: Topic set by: Doonga ChanServ: Entry message: Welcome ChanServ: Options: Topic Retention, Topic Lock, Secure Ops, Secure, Op-Notice, Enforce ChanServ: Mode lock: +nt ChanServ: This channel will not expire. The levels for the channel are as such: ChanServ: Access level settings for channel #doonga: ChanServ: AUTOPROTECT 10 ChanServ: AUTOOP 5 ChanServ: AUTOHALFOP 4 ChanServ: AUTOVOICE 3 ChanServ: AUTODEOP -1 ChanServ: NOJOIN -2 ChanServ: INVITE 5 ChanServ: AKICK 10 ChanServ: SET 10000 ChanServ: CLEAR 10000 ChanServ: UNBAN 5 ChanServ: ACC-LIST 0 ChanServ: ACC-CHANGE 10 ChanServ: MEMO 10 ChanServ: OP-DEOP 5 ChanServ: VOICE 3 ChanServ: HALFOP 4 ChanServ: PROTECT 10 ChanServ: KICK 5 And users are set as: ChanServ: Access list for #doonga: ChanServ: Num Lev Nick ChanServ: 1 10 Gusman1 ChanServ: 2 10 norked1 ChanServ: 3 10 Darkangel ChanServ: 4 5 sykkbot ChanServ: 5 5 todd Now, given all that...User todd cannot use the unban command, it says "Permission Denied." When he tries to use it. I had a similer problem with norked1 and gusman1, so I bumped their access level to 10 before I realized the issue. Temporarily I made another channel: ChanServ: Information for channel #testing: ChanServ: Founder: Doonga ChanServ: Description: testing ChanServ: Registered: Jan 28 21:08:53 2002 EST ChanServ: Last used: Jan 28 21:09:52 2002 EST ChanServ: Options: Topic Retention, Secure, Op-Notice ChanServ: Mode lock: +nt ChanServ: Access level settings for channel #testing: ChanServ: AUTOPROTECT 10 ChanServ: AUTOOP 5 ChanServ: AUTOHALFOP 4 ChanServ: AUTOVOICE 3 ChanServ: AUTODEOP -1 ChanServ: NOJOIN -2 ChanServ: INVITE 5 ChanServ: AKICK 10 ChanServ: SET 10000 ChanServ: CLEAR 10000 ChanServ: UNBAN 5 ChanServ: ACC-LIST 0 ChanServ: ACC-CHANGE 4 ChanServ: MEMO 10 ChanServ: OP-DEOP 5 ChanServ: VOICE 3 ChanServ: HALFOP 4 ChanServ: PROTECT 10 ChanServ: KICK 5 ChanServ: Access list for #testing: ChanServ: Num Lev Nick ChanServ: 1 5 todd The unban command works properly for channel #testing. I'm more than willing to admit that I am misinterpreting one of the SET options and it is working properly. But if not, here's a bug report. :) Thanks for the help, if more info is needed, please ask. Todd ------------------------------------------------------- From achurch at achurch.org Tue Jan 29 18:07:43 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Fwd: Possible Bug? (or am I misinterpreting something?) Message-ID: <3c5666c0.31217@achurch.org> Have the users in question identified for their nicks? What does /cs status #doonga say? --Andrew Church achurch@achurch.org http://achurch.org/ >Hello, > Ooops, accidentally posted this to the wrong list... > Under alpha 17, I have a channel set up like this: > >ChanServ: Information for channel #doonga: >ChanServ: Founder: Doonga >ChanServ: Description: DoongaNET IRC Main Help Channel >ChanServ: Registered: Jan 15 00:02:31 2002 EST >ChanServ: Last used: Jan 28 20:59:33 2002 EST >ChanServ: Last topic: Welcome to DoongaNET IRC. Please be patient and an >admin (@ or +) will be along soon to help you. >ChanServ: Topic set by: Doonga >ChanServ: Entry message: Welcome >ChanServ: Options: Topic Retention, Topic Lock, Secure Ops, Secure, >Op-Notice, Enforce >ChanServ: Mode lock: +nt >ChanServ: This channel will not expire. > >The levels for the channel are as such: > >ChanServ: Access level settings for channel #doonga: >ChanServ: AUTOPROTECT 10 >ChanServ: AUTOOP 5 >ChanServ: AUTOHALFOP 4 >ChanServ: AUTOVOICE 3 >ChanServ: AUTODEOP -1 >ChanServ: NOJOIN -2 >ChanServ: INVITE 5 >ChanServ: AKICK 10 >ChanServ: SET 10000 >ChanServ: CLEAR 10000 >ChanServ: UNBAN 5 >ChanServ: ACC-LIST 0 >ChanServ: ACC-CHANGE 10 >ChanServ: MEMO 10 >ChanServ: OP-DEOP 5 >ChanServ: VOICE 3 >ChanServ: HALFOP 4 >ChanServ: PROTECT 10 >ChanServ: KICK 5 > >And users are set as: > >ChanServ: Access list for #doonga: >ChanServ: Num Lev Nick >ChanServ: 1 10 Gusman1 >ChanServ: 2 10 norked1 >ChanServ: 3 10 Darkangel >ChanServ: 4 5 sykkbot >ChanServ: 5 5 todd > >Now, given all that...User todd cannot use the unban command, it says >"Permission Denied." When he tries to use it. I had a similer problem with >norked1 and gusman1, so I bumped their access level to 10 before I realized >the issue. > >Temporarily I made another channel: > >ChanServ: Information for channel #testing: >ChanServ: Founder: Doonga >ChanServ: Description: testing >ChanServ: Registered: Jan 28 21:08:53 2002 EST >ChanServ: Last used: Jan 28 21:09:52 2002 EST >ChanServ: Options: Topic Retention, Secure, Op-Notice >ChanServ: Mode lock: +nt > >ChanServ: Access level settings for channel #testing: >ChanServ: AUTOPROTECT 10 >ChanServ: AUTOOP 5 >ChanServ: AUTOHALFOP 4 >ChanServ: AUTOVOICE 3 >ChanServ: AUTODEOP -1 >ChanServ: NOJOIN -2 >ChanServ: INVITE 5 >ChanServ: AKICK 10 >ChanServ: SET 10000 >ChanServ: CLEAR 10000 >ChanServ: UNBAN 5 >ChanServ: ACC-LIST 0 >ChanServ: ACC-CHANGE 4 >ChanServ: MEMO 10 >ChanServ: OP-DEOP 5 >ChanServ: VOICE 3 >ChanServ: HALFOP 4 >ChanServ: PROTECT 10 >ChanServ: KICK 5 > >ChanServ: Access list for #testing: >ChanServ: Num Lev Nick >ChanServ: 1 5 todd > >The unban command works properly for channel #testing. I'm more than willing >to admit that I am misinterpreting one of the SET options and it is working >properly. But if not, here's a bug report. :) >Thanks for the help, if more info is needed, please ask. >Todd > >------------------------------------------------------- >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From todd at doonga.net Wed Jan 30 02:46:20 2002 From: todd at doonga.net (Todd Punderson) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Fwd: Possible Bug? (or am I misinterpreting something?) In-Reply-To: <3c5666c0.31217@achurch.org> References: <3c5666c0.31217@achurch.org> Message-ID: <20020129104749.92F7C17466@snow.fingers.co.za> Hello, Yes, the users have identified for their nicks. The output from status for the one in question is: ChanServ: STATUS #doonga todd 5 Just for completeness I did a /ns status todd .. this is the output: NickServ: STATUS todd 3 Thanks! On Tuesday 29 January 2002 01:07 pm, you wrote: > Have the users in question identified for their nicks? What does > /cs status #doonga say? > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > > >Hello, > > Ooops, accidentally posted this to the wrong list... > > Under alpha 17, I have a channel set up like this: > > > >ChanServ: Information for channel #doonga: > >ChanServ: Founder: Doonga > >ChanServ: Description: DoongaNET IRC Main Help Channel > >ChanServ: Registered: Jan 15 00:02:31 2002 EST > >ChanServ: Last used: Jan 28 20:59:33 2002 EST > >ChanServ: Last topic: Welcome to DoongaNET IRC. Please be patient and an > >admin (@ or +) will be along soon to help you. > >ChanServ: Topic set by: Doonga > >ChanServ: Entry message: Welcome > >ChanServ: Options: Topic Retention, Topic Lock, Secure Ops, Secure, > >Op-Notice, Enforce > >ChanServ: Mode lock: +nt > >ChanServ: This channel will not expire. > > > >The levels for the channel are as such: > > > >ChanServ: Access level settings for channel #doonga: > >ChanServ: AUTOPROTECT 10 > >ChanServ: AUTOOP 5 > >ChanServ: AUTOHALFOP 4 > >ChanServ: AUTOVOICE 3 > >ChanServ: AUTODEOP -1 > >ChanServ: NOJOIN -2 > >ChanServ: INVITE 5 > >ChanServ: AKICK 10 > >ChanServ: SET 10000 > >ChanServ: CLEAR 10000 > >ChanServ: UNBAN 5 > >ChanServ: ACC-LIST 0 > >ChanServ: ACC-CHANGE 10 > >ChanServ: MEMO 10 > >ChanServ: OP-DEOP 5 > >ChanServ: VOICE 3 > >ChanServ: HALFOP 4 > >ChanServ: PROTECT 10 > >ChanServ: KICK 5 > > > >And users are set as: > > > >ChanServ: Access list for #doonga: > >ChanServ: Num Lev Nick > >ChanServ: 1 10 Gusman1 > >ChanServ: 2 10 norked1 > >ChanServ: 3 10 Darkangel > >ChanServ: 4 5 sykkbot > >ChanServ: 5 5 todd > > > >Now, given all that...User todd cannot use the unban command, it says > >"Permission Denied." When he tries to use it. I had a similer problem with > >norked1 and gusman1, so I bumped their access level to 10 before I > > realized the issue. > > > >Temporarily I made another channel: > > > >ChanServ: Information for channel #testing: > >ChanServ: Founder: Doonga > >ChanServ: Description: testing > >ChanServ: Registered: Jan 28 21:08:53 2002 EST > >ChanServ: Last used: Jan 28 21:09:52 2002 EST > >ChanServ: Options: Topic Retention, Secure, Op-Notice > >ChanServ: Mode lock: +nt > > > >ChanServ: Access level settings for channel #testing: > >ChanServ: AUTOPROTECT 10 > >ChanServ: AUTOOP 5 > >ChanServ: AUTOHALFOP 4 > >ChanServ: AUTOVOICE 3 > >ChanServ: AUTODEOP -1 > >ChanServ: NOJOIN -2 > >ChanServ: INVITE 5 > >ChanServ: AKICK 10 > >ChanServ: SET 10000 > >ChanServ: CLEAR 10000 > >ChanServ: UNBAN 5 > >ChanServ: ACC-LIST 0 > >ChanServ: ACC-CHANGE 4 > >ChanServ: MEMO 10 > >ChanServ: OP-DEOP 5 > >ChanServ: VOICE 3 > >ChanServ: HALFOP 4 > >ChanServ: PROTECT 10 > >ChanServ: KICK 5 > > > >ChanServ: Access list for #testing: > >ChanServ: Num Lev Nick > >ChanServ: 1 5 todd > > > >The unban command works properly for channel #testing. I'm more than > > willing to admit that I am misinterpreting one of the SET options and it > > is working properly. But if not, here's a bug report. :) > >Thanks for the help, if more info is needed, please ask. > >Todd > > > >------------------------------------------------------- > >------------------------------------------------------------------ > >To unsubscribe or change your subscription options, visit: > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Tue Jan 29 22:31:09 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Fwd: Possible Bug? (or am I misinterpreting something?) Message-ID: <3c56a787.45075@achurch.org> >Hello, >Yes, the users have identified for their nicks. The output from status for >the one in question is: ChanServ: STATUS #doonga todd 5 Okay, found and fixed--thanks. >Just for completeness I did a /ns status todd .. this is the output: >NickServ: STATUS todd 3 >Thanks! > >On Tuesday 29 January 2002 01:07 pm, you wrote: >> Have the users in question identified for their nicks? What does >> /cs status #doonga say? >> >> --Andrew Church >> achurch@achurch.org >> http://achurch.org/ >> >> >Hello, >> > Ooops, accidentally posted this to the wrong list... >> > Under alpha 17, I have a channel set up like this: >> > >> >ChanServ: Information for channel #doonga: >> >ChanServ: Founder: Doonga >> >ChanServ: Description: DoongaNET IRC Main Help Channel >> >ChanServ: Registered: Jan 15 00:02:31 2002 EST >> >ChanServ: Last used: Jan 28 20:59:33 2002 EST >> >ChanServ: Last topic: Welcome to DoongaNET IRC. Please be patient and an >> >admin (@ or +) will be along soon to help you. >> >ChanServ: Topic set by: Doonga >> >ChanServ: Entry message: Welcome >> >ChanServ: Options: Topic Retention, Topic Lock, Secure Ops, Secure, >> >Op-Notice, Enforce >> >ChanServ: Mode lock: +nt >> >ChanServ: This channel will not expire. >> > >> >The levels for the channel are as such: >> > >> >ChanServ: Access level settings for channel #doonga: >> >ChanServ: AUTOPROTECT 10 >> >ChanServ: AUTOOP 5 >> >ChanServ: AUTOHALFOP 4 >> >ChanServ: AUTOVOICE 3 >> >ChanServ: AUTODEOP -1 >> >ChanServ: NOJOIN -2 >> >ChanServ: INVITE 5 >> >ChanServ: AKICK 10 >> >ChanServ: SET 10000 >> >ChanServ: CLEAR 10000 >> >ChanServ: UNBAN 5 >> >ChanServ: ACC-LIST 0 >> >ChanServ: ACC-CHANGE 10 >> >ChanServ: MEMO 10 >> >ChanServ: OP-DEOP 5 >> >ChanServ: VOICE 3 >> >ChanServ: HALFOP 4 >> >ChanServ: PROTECT 10 >> >ChanServ: KICK 5 >> > >> >And users are set as: >> > >> >ChanServ: Access list for #doonga: >> >ChanServ: Num Lev Nick >> >ChanServ: 1 10 Gusman1 >> >ChanServ: 2 10 norked1 >> >ChanServ: 3 10 Darkangel >> >ChanServ: 4 5 sykkbot >> >ChanServ: 5 5 todd >> > >> >Now, given all that...User todd cannot use the unban command, it says >> >"Permission Denied." When he tries to use it. I had a similer problem with >> >norked1 and gusman1, so I bumped their access level to 10 before I >> > realized the issue. >> > >> >Temporarily I made another channel: >> > >> >ChanServ: Information for channel #testing: >> >ChanServ: Founder: Doonga >> >ChanServ: Description: testing >> >ChanServ: Registered: Jan 28 21:08:53 2002 EST >> >ChanServ: Last used: Jan 28 21:09:52 2002 EST >> >ChanServ: Options: Topic Retention, Secure, Op-Notice >> >ChanServ: Mode lock: +nt >> > >> >ChanServ: Access level settings for channel #testing: >> >ChanServ: AUTOPROTECT 10 >> >ChanServ: AUTOOP 5 >> >ChanServ: AUTOHALFOP 4 >> >ChanServ: AUTOVOICE 3 >> >ChanServ: AUTODEOP -1 >> >ChanServ: NOJOIN -2 >> >ChanServ: INVITE 5 >> >ChanServ: AKICK 10 >> >ChanServ: SET 10000 >> >ChanServ: CLEAR 10000 >> >ChanServ: UNBAN 5 >> >ChanServ: ACC-LIST 0 >> >ChanServ: ACC-CHANGE 4 >> >ChanServ: MEMO 10 >> >ChanServ: OP-DEOP 5 >> >ChanServ: VOICE 3 >> >ChanServ: HALFOP 4 >> >ChanServ: PROTECT 10 >> >ChanServ: KICK 5 >> > >> >ChanServ: Access list for #testing: >> >ChanServ: Num Lev Nick >> >ChanServ: 1 5 todd >> > >> >The unban command works properly for channel #testing. I'm more than >> > willing to admit that I am misinterpreting one of the SET options and it >> > is working properly. But if not, here's a bug report. :) >> >Thanks for the help, if more info is needed, please ask. >> >Todd >> > >> >------------------------------------------------------- >> >------------------------------------------------------------------ >> >To unsubscribe or change your subscription options, visit: >> >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding >> >> ------------------------------------------------------------------ >> To unsubscribe or change your subscription options, visit: >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding --Andrew Church achurch@achurch.org http://achurch.org/ From Kevc at gmx.co.uk Thu Jan 31 04:21:36 2002 From: Kevc at gmx.co.uk (Kevin (BT)) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Error in Logon News Adding Message-ID: <1567657400.20020131122136@gmx.co.uk> Hey, This Following Thing Occured on my server after adding Logon News #3 [12:14] -OperServ- 1 (Jan 30 16:50:33 2002 CST by Kevc) [12:14] -OperServ- Blah Blah Blah [12:14] -OperServ- 2 (Jan 31 05:29:58 2002 CST by Kevc) [12:14] -OperServ- Welcome to The Blah Blah Blah [12:14] -OperServ- 2 (Jan 31 06:13:42 2002 CST by Kevc) [12:14] -OperServ- Blah Blah Blah Also When adding the news, it shows the following (Didnt Record the Logonnews #1 Message) [11:30] -OperServ- Added new logon news item (#2). [12:13] -OperServ- Added new logon news item (#2). Guess #3 Disappeared, so i tried adding another and got the following, -> [msg(operserv)] logonnews add blah [12:19] -OperServ- Added new logon news item (#2). Now.... to try deleting #2 .. Nothing happened, i got the message [12:20] -OperServ- Logon news item #2 deleted. But when i did a list, all three #2's were intact. Regards, -- Kevin Conlin BT Operator http://www.darkserv.net Kevc@gmx.co.uk Running The Bat! 1.54 Beta/18 on Windows XP 5.1 -- From rg at tcslon.com Thu Jan 31 12:49:59 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] A few bugs... In-Reply-To: <3c56a787.45075@achurch.org> Message-ID: Sorry I haven't been around much recently... loads of school work... Found a few small spelling mistakes: /modules/protocol/bahamut.c line 137: " sure you have no pre-1.4.25 servers on your netowrk," example-ircservices.conf line 691: # user-configuratble data. This is separate from the help messages And another bug in my favourite module, xml-export: xml-export.c line 339: writefunc(data, "\t\t%s\n", should read (I assume): writefunc(data, "\t\t%s\n", That's all for now :) Russ Garrett (russ@garrett.co.uk) From achurch at achurch.org Fri Feb 1 14:53:06 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] A few bugs... Message-ID: <3c5a2d7e.65616@achurch.org> Thanks, fixed. --Andrew Church achurch@achurch.org http://achurch.org/ >Sorry I haven't been around much recently... loads of school work... > >Found a few small spelling mistakes: > >/modules/protocol/bahamut.c line 137: > " sure you have no pre-1.4.25 servers on your >netowrk," >example-ircservices.conf line 691: ># user-configuratble data. This is separate from the help >messages > > >And another bug in my favourite module, xml-export: > >xml-export.c line 339: > writefunc(data, "\t\t%s\n", >should read (I assume): > writefunc(data, "\t\t%s\n", > > >That's all for now :) > > >Russ Garrett (russ@garrett.co.uk) > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Fri Feb 1 15:39:53 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Error in Logon News Adding Message-ID: <3c5a3848.70534@achurch.org> Fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ >Hey, > >This Following Thing Occured on my server after adding Logon News #3 > >[12:14] -OperServ- 1 (Jan 30 16:50:33 2002 CST by Kevc) >[12:14] -OperServ- Blah Blah Blah >[12:14] -OperServ- 2 (Jan 31 05:29:58 2002 CST by Kevc) >[12:14] -OperServ- Welcome to The Blah Blah Blah >[12:14] -OperServ- 2 (Jan 31 06:13:42 2002 CST by Kevc) >[12:14] -OperServ- Blah Blah Blah > >Also When adding the news, it shows the following > >(Didnt Record the Logonnews #1 Message) > >[11:30] -OperServ- Added new logon news item (#2). > >[12:13] -OperServ- Added new logon news item (#2). > >Guess #3 Disappeared, so i tried adding another and got the following, > >-> [msg(operserv)] logonnews add blah >[12:19] -OperServ- Added new logon news item (#2). > >Now.... to try deleting #2 > >.. Nothing happened, i got the message >[12:20] -OperServ- Logon news item #2 deleted. > >But when i did a list, all three #2's were intact. > > > >Regards, > >-- > >Kevin Conlin >BT Operator >http://www.darkserv.net >Kevc@gmx.co.uk >Running The Bat! 1.54 Beta/18 on Windows XP 5.1 > >-- > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From rg at tcslon.com Fri Feb 1 11:44:31 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] More bugs In-Reply-To: <3c5a3848.70534@achurch.org> Message-ID: I have a confession to make.... Last night I was bored, so I set up a test box and linked IRCServices 5 into my "live" network. Well, to be honest, it's not particularly live with only 15 users, but services hasn't caused a single problem (and yes, I know services are unsupported, and I won't whinge if anything goes wrong :), and having it on a live net with users does make it easier to find any bugs. I'm pretty confident that these services are beta-quality now. Well I lie a bit, because I did find a few small bugs I probably wouldn't have noticed on my testnet: chanserv: It seems that the /cs set secureops option doesn't work - it is set but it doesn't take effect - I had a (very) quick browse through the code and couldn't find anything obviously amiss. operserv: Minor documentation bug in lang/en_us.l on line 4510: Limited to ^BServices admins^B. /os raw is now limited to services root, so this is wrong. operserv: I noticed the undocumented /os LISTIGNORE function. If this is to remain undocumented (and I don't see why it shouldn't - it has no non-debugging use as far as I can see - correct me if I'm wrong), it would probably be better restricted to the services root and put inside an #ifdef DEBUG_COMMANDS, or it should be documented. Thanks, Russ Garrett (rg@tcslon.com) From griever at t2n.org Fri Feb 1 17:18:41 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Exceptions Message-ID: Why can't you use user@host masks in exceptions? This would be helpful for things like limiting the number of connections from a host not running ident. From rg at tcslon.com Sat Feb 2 03:26:25 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] A subtle levels bug Message-ID: I'm running Bahamut with IRCServices 5, and I've spotted a chanserv levels bug: Pertinent Channel level settings: AUTOVOICE 0 AUTOHALFOP 4 (although it isn't used, because Bahamut doesn't support hop) A user with access level 4 enters the channel. He is not autovoiced, despite being above the AUTOVOICE leve, because he would be be hopped if this wasn't bahamut, so he is left with no modes. The bahamut protocol module needs to recognise this situation and voice him. Thanks, Russ Garrett (russ@garrett.co.uk) From rg at tcslon.com Sat Feb 2 03:31:49 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] A subtle levels bug In-Reply-To: Message-ID: > The bahamut protocol module needs to recognise this > situation and voice him. Just to add something to this: The easy temporary way to fix this is to disable the AUTOHALFOP level, so, an alternative to modifying the bahamut protocol module would be to disable AUTOHALFOP on channels created on a Bahamut server (I don't know, this may be done already - the channel in question was originally registered on Unreal, before we changed to Bahamut) Russ Garrett (russ@garrett.co.uk) From rg at tcslon.com Sat Feb 2 03:59:33 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] A not-quite-so-subtle, but pretty nasty, levels bug (a.k.a. no bugs for several days, then 5 come along at once ;) In-Reply-To: Message-ID: I found this one by fidding about with my last bug, and is best summed up by this transcript (my comments in [square brackets]): -> ChanServ levels #chat list Access level settings for channel #chat: AUTOPROTECT 10 AUTOOP 5 AUTOHALFOP 4 AUTOVOICE 0 AUTODEOP -1 NOJOIN -2 INVITE 5 AKICK 10 SET (disabled) CLEAR (disabled) UNBAN 5 ACC-LIST 0 ACC-CHANGE 10 MEMO 10 OP-DEOP 5 VOICE 3 HALFOP 4 PROTECT 10 KICK 5 -> ChanServ levels #chat DIS AUTOHALFOP AUTOHALFOP disabled on channel #chat. -> ChanServ levels #chat list Access level settings for channel #chat: AUTOPROTECT 10 AUTOOP 5 AUTOHALFOP (disabled) [AUTOHALFOP is disabled... all good so far] AUTOVOICE 3 [hello... AUTOVOICE is randomly reset...] AUTODEOP -1 NOJOIN -2 INVITE 5 AKICK 10 SET 10000 [SET and CLEAR - formerly disabled, are now level 10000!] CLEAR 10000 UNBAN 5 ACC-LIST 0 ACC-CHANGE 4 MEMO 10 OP-DEOP 5 VOICE 3 HALFOP 4 PROTECT 10 KICK 5 Haven't had time to look at the code, Thanks, Russ Garrett (russ@garrett.co.uk) From achurch at achurch.org Sun Feb 3 01:44:51 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] More bugs Message-ID: <3c5c18b9.06321@achurch.org> >I have a confession to make.... Last night I was bored, so I set up a >test box and linked IRCServices 5 into my "live" network. Well, to be >honest, it's not particularly live with only 15 users, but services >hasn't caused a single problem (and yes, I know services are >unsupported, and I won't whinge if anything goes wrong :), and having >it on a live net with users does make it easier to find any bugs. I'm >pretty confident that these services are beta-quality now. Well, as long as you don't complain I don't mind. (: >chanserv: It seems that the /cs set secureops option doesn't work - >it is set but it doesn't take effect - I had a (very) quick browse >through the code and couldn't find anything obviously amiss. Works for me; are you sure it wasn't just a MergeChannelModes delay? >operserv: Minor documentation bug in lang/en_us.l on line 4510: > Limited to ^BServices admins^B. >/os raw is now limited to services root, so this is wrong. Thanks, I'll fix this when I go back to the language file. (I've made a lot of typo fixes since alpha 17, and I want to keep content fixes separate to make things easier on translators. >operserv: I noticed the undocumented /os LISTIGNORE function. If this >is to remain undocumented (and I don't see why it shouldn't - it has >no non-debugging use as far as I can see - correct me if I'm wrong), >it would probably be better restricted to the services root and put >inside an #ifdef DEBUG_COMMANDS, or it should be documented. I'm aware of this; the entire ignore system is broken, and has been that way for who knows how many years. I'm hoping to get around to fixing it by the time a beta goes out, but who knows. In any case, I'll deal with this at the same time. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Sun Feb 3 01:51:13 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] A subtle levels bug Message-ID: <3c5c1b82.07351@achurch.org> >I'm running Bahamut with IRCServices 5, and I've spotted a chanserv >levels bug: > >Pertinent Channel level settings: >AUTOVOICE 0 >AUTOHALFOP 4 (although it isn't used, because Bahamut doesn't support >hop) > >A user with access level 4 enters the channel. He is not autovoiced, >despite being above the AUTOVOICE leve, because he would be be hopped if >this wasn't bahamut, so he is left with no modes. > >The bahamut protocol module needs to recognise this situation and voice >him. Protocol modules don't touch ChanServ, as they shouldn't. The CS access code is supposed to take care of this automatically by deleting the AUTOHALFOP and HALFOP levels (see access.c:init_access()) when the protocol module signals that it doesn't have halfop capability, but it doesn't seem to be working correctly. I'll look into it. >I found this one by fidding about with my last bug, and is best summed >up by this transcript (my comments in [square brackets]): > >-> ChanServ levels #chat list > Access level settings for channel #chat: > AUTOPROTECT 10 > AUTOOP 5 > AUTOHALFOP 4 > AUTOVOICE 0 [..] >-> ChanServ levels #chat DIS AUTOHALFOP > AUTOHALFOP disabled on channel #chat. > >-> ChanServ levels #chat list > Access level settings for channel #chat: > AUTOPROTECT 10 > AUTOOP 5 > AUTOHALFOP (disabled) [AUTOHALFOP is disabled... all good so far] > AUTOVOICE 3 [hello... AUTOVOICE is randomly reset...] > AUTODEOP -1 > NOJOIN -2 > INVITE 5 > AKICK 10 > SET 10000 [SET and CLEAR - formerly disabled, are now level 10000!] > CLEAR 10000 Fixed (logic bug in LEVELS DISABLE), thanks for the report. Incidentally, the "10000" should read "(founder only)", and that's already fixed for the next release. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Sun Feb 3 02:09:27 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Error in Logon News Adding Message-ID: <3c5c1d53.07617@achurch.org> Fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ >Hey, > >This Following Thing Occured on my server after adding Logon News #3 > >[12:14] -OperServ- 1 (Jan 30 16:50:33 2002 CST by Kevc) >[12:14] -OperServ- Blah Blah Blah >[12:14] -OperServ- 2 (Jan 31 05:29:58 2002 CST by Kevc) >[12:14] -OperServ- Welcome to The Blah Blah Blah >[12:14] -OperServ- 2 (Jan 31 06:13:42 2002 CST by Kevc) >[12:14] -OperServ- Blah Blah Blah > >Also When adding the news, it shows the following > >(Didnt Record the Logonnews #1 Message) > >[11:30] -OperServ- Added new logon news item (#2). > >[12:13] -OperServ- Added new logon news item (#2). > >Guess #3 Disappeared, so i tried adding another and got the following, > >-> [msg(operserv)] logonnews add blah >[12:19] -OperServ- Added new logon news item (#2). > >Now.... to try deleting #2 > >.. Nothing happened, i got the message >[12:20] -OperServ- Logon news item #2 deleted. > >But when i did a list, all three #2's were intact. > > > >Regards, > >-- > >Kevin Conlin >BT Operator >http://www.darkserv.net >Kevc@gmx.co.uk >Running The Bat! 1.54 Beta/18 on Windows XP 5.1 > >-- > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Sun Feb 3 02:10:30 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Exceptions Message-ID: <3c5c1e3b.07745@achurch.org> >Why can't you use user@host masks in exceptions? This would be helpful for >things like limiting the number of connections from a host not running >ident. I assume that "not" is extraneous, but seeing as how 99.9% of hosts don't run ident (or at least a _useful_ ident), and supporting it would just make exception lists longer and exception processing take more time, I don't see the point. --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Sat Feb 2 10:19:26 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Exceptions In-Reply-To: <3c5c1e3b.07745@achurch.org> Message-ID: On Sun, 3 Feb 2002, Andrew Church wrote: > >Why can't you use user@host masks in exceptions? This would be helpful for > >things like limiting the number of connections from a host not running > >ident. > > I assume that "not" is extraneous, but seeing as how 99.9% of hosts > don't run ident (or at least a _useful_ ident), and supporting it would > just make exception lists longer and exception processing take more time, I > don't see the point. The reason I request this is because of a recent attack on one of the networks I operate. We had > 50 clones from 15 different proxies. If we could have set a 1 limit for ~*@*, they would have been killed off very quickly. As it was, the proxy scanner couldn't kill them off fast enough and the whole net was down for almost an hour until the auto-zlines kicked in. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From achurch at achurch.org Sun Feb 3 03:26:43 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Exceptions Message-ID: <3c5c2f97.12602@achurch.org> >On Sun, 3 Feb 2002, Andrew Church wrote: > >> >Why can't you use user@host masks in exceptions? This would be helpful for >> >things like limiting the number of connections from a host not running >> >ident. >> >> I assume that "not" is extraneous, but seeing as how 99.9% of hosts >> don't run ident (or at least a _useful_ ident), and supporting it would >> just make exception lists longer and exception processing take more time, I >> don't see the point. > >The reason I request this is because of a recent attack on one of the >networks I operate. We had > 50 clones from 15 different proxies. If we >could have set a 1 limit for ~*@*, they would have been killed off very >quickly. As it was, the proxy scanner couldn't kill them off fast enough >and the whole net was down for almost an hour until the auto-zlines kicked >in. Seems to me you could just have had your scanner add autokills for found proxies... --Andrew Church achurch@achurch.org http://achurch.org/ From rplume at cablemo.net Sat Feb 2 15:43:51 2002 From: rplume at cablemo.net (RP) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Exceptions References: <3c5c2f97.12602@achurch.org> Message-ID: <000501c1ac43$7a1d9570$9a96d741@ryan> Greetings.. I've been rather curious about IRCServices' irc_stricmp function. What does it do that the regular stricmp() doesn't, and could it be replaced safely with stricmp? From achurch at achurch.org Sun Feb 3 12:14:12 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] irc_stricmp() Message-ID: <3c5caba9.55062@achurch.org> > I've been rather curious about IRCServices' irc_stricmp function. What >does it do that the regular stricmp() doesn't, and could it be replaced >safely with stricmp? (1) stricmp() is (potentially) locale-dependent, and could conceivably behave incorrectly in certain locales. (2) RFC1459-compliant ircds treat [ and {, \ and |, ] and } as pairwise equivalent; stricmp() doesn't. --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Sat Feb 2 23:18:20 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] irc_stricmp() In-Reply-To: <3c5caba9.55062@achurch.org> Message-ID: On Sun, 3 Feb 2002, Andrew Church wrote: > > I've been rather curious about IRCServices' irc_stricmp function. What > >does it do that the regular stricmp() doesn't, and could it be replaced > >safely with stricmp? > > (1) stricmp() is (potentially) locale-dependent, and could conceivably > behave incorrectly in certain locales. > > (2) RFC1459-compliant ircds treat [ and {, \ and |, ] and } as > pairwise equivalent; stricmp() doesn't. I'd also like to point out that many systems don't *have* stricmp > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From achurch at achurch.org Sun Feb 3 16:29:39 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] irc_stricmp() Message-ID: <3c5ce796.71211@achurch.org> >On Sun, 3 Feb 2002, Andrew Church wrote: > >> > I've been rather curious about IRCServices' irc_stricmp function. What >> >does it do that the regular stricmp() doesn't, and could it be replaced >> >safely with stricmp? >> >> (1) stricmp() is (potentially) locale-dependent, and could conceivably >> behave incorrectly in certain locales. >> >> (2) RFC1459-compliant ircds treat [ and {, \ and |, ] and } as >> pairwise equivalent; stricmp() doesn't. > >I'd also like to point out that many systems don't *have* stricmp Well, they _do_ have strcasecmp() which is the same thing (and actually POSIX, I think)--I just like "stricmp" because (1) it's shorter and (2) "strcasecmp" sounds like "case-sensitive string compare" which is wrong. Out of curiosity, are there any systems that don't have either function? --Andrew Church achurch@achurch.org http://achurch.org/ From eengin at talesoft.de Sat Feb 2 23:43:54 2002 From: eengin at talesoft.de (Ekim Engin) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] irc_stricmp() In-Reply-To: <3c5ce796.71211@achurch.org> Message-ID: <004a01c1ac86$87feea70$092a14ac@hadiko.de> Some older Digital-Alpha-OSF 3.1 Systems (pre bulid 483) don't have both functions by default... Greets Ekim "Talesin" Engin PGP-Fingerprint: 8627 180C 1397 34FB 6BB0 8B65 9CBF 8ED5 456C 48F9 --- Chat begins as it ends - without reason > -----Original Message----- > From: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net] On > Behalf Of Andrew Church > Sent: Sunday, February 03, 2002 8:30 AM > To: ircservices-coding@ircservices.za.net > Subject: Re: [IRCServices Coding] irc_stricmp() > > > >On Sun, 3 Feb 2002, Andrew Church wrote: > > > >> > I've been rather curious about IRCServices' irc_stricmp > >> >function. What does it do that the regular stricmp() doesn't, and > >> >could it be replaced safely with stricmp? > >> > >> (1) stricmp() is (potentially) locale-dependent, and could > >> conceivably behave incorrectly in certain locales. > >> > >> (2) RFC1459-compliant ircds treat [ and {, \ and |, ] > and } as > >> pairwise equivalent; stricmp() doesn't. > > > >I'd also like to point out that many systems don't *have* stricmp > > Well, they _do_ have strcasecmp() which is the same > thing (and actually POSIX, I think)--I just like "stricmp" > because (1) it's shorter and (2) "strcasecmp" sounds like > "case-sensitive string compare" which is wrong. > > Out of curiosity, are there any systems that don't have > either function? > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircser> vices-coding > From achurch at achurch.org Sun Feb 3 23:42:31 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Services 5.0 alpha 18 released Message-ID: <3c5d4cdc.47342@achurch.org> Services 5.0 alpha 18 is out at the usual place. Not too much of note, but I needed an easy way to differentiate typo fixes in the language files from all the changes that will go into the next alpha. (This release is actually about a day old but got delayed due to server problems.) Changes in version 5.0a18 ------------------------- 2002/02/03 Fixed bug causing channel levels to get reset on a LEVELS DISABLE. Reported by Russ Garrett 2002/02/02 Fixed bug where founder-only channel levels would show up as "10000" in ChanServ LEVELS LIST. 2002/02/02 Added command reference and configuration file documentation. 2002/02/02 Fixed typos/formatting in language files (no content changes). 2002/02/01 Fixed bugs in news module causing ADD to use bad item numbers and DEL to not work at all. Reported by Kevin 2002/02/01 Fixed minor typos reported by Russ Garrett 2002/01/29 Fixed bug causing access levels for ChanServ commands to be incorrectly checked. Reported by Todd Punderson 2002/01/29 Added URL and E-mail fields to httpd/dbaccess channel information display. 2002/01/29 Fixed cosmetic bugs in NickServ DROPNICK output and httpd/dbaccess nickname information display. Reported by Martin Pels 2002/01/28 Fixed crash in nickserv/oldlink LISTLINKS command. --Andrew Church achurch@achurch.org http://achurch.org/ From mark at mhetherington.demon.co.uk Sun Feb 3 13:07:30 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Services 5.0 Miunor Bugs/glitches/suggestions In-Reply-To: <3c5d4cdc.47342@achurch.org> Message-ID: Version 5 is definitely coming together very well now. Been running the latest version on a production network and the following issues came up. All reported on a Network of Unreal servers running Services 5.0a18. 1) Bug: When the ChanServ and Nickserv LIST command is restricted to opers only, it still displays in the list of standard commands available to all users. It ought to be removed from the commands list when not available to a user. 2) Suggestion: A configuration file directive to remove/disable GetPass would be a welcome addition. The introduction of SendPass into the main distribution removes the main need for GetPass (password recovery) so the abiity to easily remove GetPass commands from the modules and references in helpfiles would be useful. 3) Bug: Memoserv send does not always confirm that a memo has been sent even though it has. This only seems to affect some users and I have yet to find what it is about particular users that causes this. 4) Bug: Help responses which involve 2 pseudo client names do not appear to display correctly. E.g. the /cs help register command will display the name of the ChanServ client correctly, but seemingly a random string for the NickServ client -ChanServ- Syntax: SENDPASS channel -ChanServ- -ChanServ- Sends you an E-mail message containing the password for the -ChanServ- given channel. You must be the founder of the channel to -ChanServ- use this command, and you must first identify for your -ChanServ- nickname with the xxx.xxx.xxx.xxx.xxx IDENTIFY command. (the xxx refers to a user's hostname masked for privacy which managed to become the client name for NickServ during one services run. This same host name was displayed in that place to all users on the network. Previous runs had other strings which were sometimes "random" garbage. 5) Bug: The Network statistics link in the httpd module does not operate at all. On our network we run an existing StatServ client, so the services one is named StatServ2. I could not see anything in the code/setup that would cause this to affect the httpd module but thought I should mention it in case. 6) Another "unhandled" message for the list, services reports but is unable to process /who 0 o commands (users trying to list online opers) generating: unknown message from server (:nick 4 [Did a /who 0 o]) 7) Suggestion: every hyperlink clicked in the httpd pages results in the following log entry: httpd/main: Accepted connection from xxx.xxx.xxx.xxx:nnnn This suggestion is twofold, firstly a more defined log entry specifying the access made and secondly, logging the httpd client messages to a seperate log file. It might actually be useful to log each client to it's own log file, with the central file reserved for messages related to overall operation. 8) Rehash produces an odd error message: Received SIGHUP, rehashing. sockets: select(): Interrupted system call Not sure how important this is but if it is important enough to log, it is probably something that shouldn't be happening :) 9) Not sure if this is a known problem listed anywhere but I haven't found it in the docs, Services 5 will not parse a Version 4.5.x exception.db file. The following error appears in the log file: database/version4: Read error on exception.db I think that covers everything in today's findings that I haven't found in known bugs or other comments :) Mark. From mark at mhetherington.demon.co.uk Sun Feb 3 13:44:26 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Services 5.0 Bug in oper.db In-Reply-To: Message-ID: An oper.db file originally from version 4.5.x loaded into version 5.0a18 has now grown in size from 61 bytes to 7.5K! The contents of the new files seem to be multiple copies of the os admin list and the os operator list. Andrew, please email me off list if you want copies of the both files for debugging. Mark. From mark at mhetherington.demon.co.uk Sun Feb 3 15:24:45 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Services 5.0 Bug in oper.db In-Reply-To: Message-ID: Additional information... the file keeps growing in a similar manner (up to 8K now ) so it seems that services is writing increasing copies of the lists to the file with each database save. I have included the *.db dir list for both version below since it *may* also be affecting other files given the unexpected increases in such a short space of time (chan/nick/oper): -rw------- 1 xxx xxx 315 Feb 3 02:13 akill.db -rw------- 1 xxx xxx 44628 Feb 3 02:13 chan.db -rw------- 1 xxx xxx 169 Feb 3 02:13 exception.db -rw------- 1 xxx xxx 6 Feb 3 02:13 news.db -rw------- 1 xxx xxx 116404 Feb 3 02:13 nick.db -rw------- 1 xxx xxx 61 Feb 3 02:13 oper.db -rw------- 1 xxx xxx 415 Feb 3 02:13 stats.db -rw------- 1 xxx xxx 415 Feb 3 23:14 akill.db -rw------- 1 xxx xxx 49261 Feb 3 23:14 chan.db -rw------- 1 xxx xxx 134 Feb 3 23:14 exception.db -rw------- 1 xxx xxx 404 Feb 3 23:14 news.db -rw------- 1 xxx xxx 148935 Feb 3 23:14 nick.db -rw------- 1 xxx xxx 8161 Feb 3 23:14 oper.db -rw------- 1 xxx xxx 22 Feb 3 23:14 sline.db -rw------- 1 xxx xxx 703 Feb 3 23:14 stats.db Mark. > -----Original Message----- > From: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net]On Behalf Of > Mark Hetherington > Sent: 03 February 2002 21:44 > To: ircservices-coding@ircservices.za.net > Subject: [IRCServices Coding] Services 5.0 Bug in oper.db > > > An oper.db file originally from version 4.5.x loaded into version > 5.0a18 has > now grown in size from 61 bytes to 7.5K! > > The contents of the new files seem to be multiple copies of the os admin > list and the os operator list. > > Andrew, please email me off list if you want copies of the both files for > debugging. > > Mark. > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Mon Feb 4 07:51:13 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Services 5.0 Miunor Bugs/glitches/suggestions Message-ID: <3c5dce27.54332@achurch.org> >1) Bug: When the ChanServ and Nickserv LIST command is restricted to opers >only, it still displays in the list of standard commands available to all >users. It ought to be removed from the commands list when not available to a >user. I don't consider this a bug (in fact, I think I had it that way at one point and reversed it), but it seems reasonable enough. Done. >2) Suggestion: A configuration file directive to remove/disable GetPass >would be a welcome addition. The introduction of SendPass into the main >distribution removes the main need for GetPass (password recovery) so the >abiity to easily remove GetPass commands from the modules and references in >helpfiles would be useful. Added. >3) Bug: Memoserv send does not always confirm that a memo has been sent even >though it has. This only seems to affect some users and I have yet to find >what it is about particular users that causes this. I haven't been able to reproduce this, and can't fix it without more information. >4) Bug: Help responses which involve 2 pseudo client names do not appear to >display correctly. E.g. the /cs help register command will display the name >of the ChanServ client correctly, but seemingly a random string for the >NickServ client I can't reproduce this. >5) Bug: The Network statistics link in the httpd module does not operate at >all. This is known (see the FIXME in httpd/dbaccess.c). >6) Another "unhandled" message for the list, services reports but is unable >to process /who 0 o commands (users trying to list online opers) generating: > >unknown message from server (:nick 4 [Did a /who 0 o]) This is a HELP message (the /who is processed by the client's server). I'll add it to the ignore list. >7) Suggestion: every hyperlink clicked in the httpd pages results in the >following log entry: > >httpd/main: Accepted connection from xxx.xxx.xxx.xxx:nnnn > >This suggestion is twofold, firstly a more defined log entry specifying the >access made and secondly, logging the httpd client messages to a seperate >log file. It might actually be useful to log each client to it's own log >file, with the central file reserved for messages related to overall >operation. I don't like the proliferation of log files that would create; if it bothers you to have everything in one logfile, just write a script that parses them out to separate files or something. As for the other point, an access-log-like thing is under consideration. >8) Rehash produces an odd error message: > >Received SIGHUP, rehashing. >sockets: select(): Interrupted system call This is because the signal interrupts select() which is waiting for input from the remote server, and probably shouldn't be logged as it's normal behavior. Fixed. >9) Not sure if this is a known problem listed anywhere but I haven't found >it in the docs, Services 5 will not parse a Version 4.5.x exception.db file. >The following error appears in the log file: > >database/version4: Read error on exception.db Can you send me an example database that has this problem? --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Mon Feb 4 09:02:51 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Services 5.0 Bug in oper.db Message-ID: <3c5dcfb7.55166@achurch.org> >An oper.db file originally from version 4.5.x loaded into version 5.0a18 has >now grown in size from 61 bytes to 7.5K! > >The contents of the new files seem to be multiple copies of the os admin >list and the os operator list. Fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ From mark at mhetherington.demon.co.uk Sun Feb 3 16:41:22 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Services 5.0 Miunor Bugs/glitches/suggestions In-Reply-To: <3c5dce27.54332@achurch.org> Message-ID: Thanks for the prompt response and fixes. > >3) Bug: Memoserv send does not always confirm that a memo has > been sent even > >though it has. This only seems to affect some users and I have > yet to find > >what it is about particular users that causes this. > > I haven't been able to reproduce this, and can't fix it without more > information. Trying to track this down. Any ideas as to what could cause such an issue? I get it all the time. I am services root but even when using a different non linked nickname I can still get it (using same client and setup that worked with 4.5.x). Other users that have experienced it have no "status" so I do not think my services access is affecting it in any case. I will get chance to try on a completely different system and connection tomorrow (work) and go from there. > >4) Bug: Help responses which involve 2 pseudo client names do > not appear to > >display correctly. E.g. the /cs help register command will > display the name > >of the ChanServ client correctly, but seemingly a random string for the > >NickServ client > > I can't reproduce this. Off-list email sent of config and details of a network exhibiting said problem in case it is a combination of settings which cause this. > I don't like the proliferation of log files that would create; if it > bothers you to have everything in one logfile, just write a script that > parses them out to separate files or something. As for the other > point, an > access-log-like thing is under consideration. It doesn't bother me having everything in one log file. It was mainly the lack of information in the httpd messages and their high proliferation rate compared with other modules which made me consider a seperate log file for it. Multiple log files was just an extension of the idea for discussion. The access log would solve the information in the message, but hopefully this would be coupled with a simple (configuration possibly) way to disable the standard message in the main log file. > >9) Not sure if this is a known problem listed anywhere but I > haven't found > >it in the docs, Services 5 will not parse a Version 4.5.x > exception.db file. > >The following error appears in the log file: > > > >database/version4: Read error on exception.db > > Can you send me an example database that has this problem? Sent off-list. Mark. From achurch at achurch.org Mon Feb 4 11:07:53 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Services 5.0 Miunor Bugs/glitches/suggestions Message-ID: <3c5ded2c.62352@achurch.org> >> >3) Bug: Memoserv send does not always confirm that a memo has >> been sent even >> >though it has. This only seems to affect some users and I have >> yet to find >> >what it is about particular users that causes this. >> >> I haven't been able to reproduce this, and can't fix it without more >> information. > >Trying to track this down. Any ideas as to what could cause such an issue? I >get it all the time. I am services root but even when using a different non >linked nickname I can still get it (using same client and setup that worked >with 4.5.x). Other users that have experienced it have no "status" so I do >not think my services access is affecting it in any case. I will get chance >to try on a completely different system and connection tomorrow (work) and >go from there. Out of curiosity, does this happen every time to affected users or just sometimes? Do you get any strange log messages? --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Mon Feb 4 11:09:26 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Services 5.0 Miunor Bugs/glitches/suggestions Message-ID: <3c5ded8c.62424@achurch.org> Re: the httpd issue, I went to implement a switch to turn off connection logging only to find out I'd already done it. The config directive is LogConnections, comment it out if you don't like the messages. I'll look into the access log thing later. --Andrew Church achurch@achurch.org http://achurch.org/ From rg at tcslon.com Mon Feb 4 09:53:08 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Services segfault In-Reply-To: <3c5c18b9.06321@achurch.org> Message-ID: I've found a pretty critical but easily reproducible bug: [17:13:26] -> *chanserv* set #chan restricted on [17:13:26] -apollo.final-conflict.net- *** Global -- from services.final-conflict.net: PANIC! buffer = :Russ PRIVMSG chanserv :set #chan restricted on This happens with any channel, and any user who sets restricted on on both Bahamut and Unreal. Thanks, Russ Garrett (russ@garrett.co.uk) From mark at mhetherington.demon.co.uk Mon Feb 4 12:24:18 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Services 5.0 Miunor Bugs/glitches/suggestions In-Reply-To: <3c5ded2c.62352@achurch.org> Message-ID: [snip Memoserv not sending the confirmation of sent messages] > Out of curiosity, does this happen every time to affected > users or just > sometimes? Do you get any strange log messages? Yes it happens every time to affected users. No strange log messages occur. I have now tried with a completely new nickname on a new install of MIRC on a PC previously without an IRC client installed, from a different location and had the same issue occur. The one thing that may be relevant is that the sends were sent before the nick AUTH was activated (The email didn't arrive in time for me to check post AUTH on this new machine). All other nicks so far with problems, have not been through the AUTH procedure since they existed prior to it being available. PRobably grasping at straws but could something in the AUTH be involved? I guess the only thing left to try is to add lots of log messages into memoserv and see if it is actually trying to send the message. Mark. From rplume at cablemo.net Mon Feb 4 16:12:00 2002 From: rplume at cablemo.net (RP) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Nickname linking/coding question References: Message-ID: <001301c1add9$bd51fce0$9a96d741@ryan> I'm experimenting with the nickname linking code on ircservices-4.5.37. I've been trying code it so that it links the specified nick to the current nick, rather than linking the current nickname to the specified nick. I have done this by basically reversing all of the "target" and "ni" references in do_link. However, whenever it scans the nicknames for expirations, services segfaults. Have any idea what I'm doing wrong or what could be happening... Or how I could go about doing this? Thanks From mark at mhetherington.demon.co.uk Mon Feb 4 16:15:52 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] NickServ Status "cosmetic" bug/suggestion In-Reply-To: Message-ID: (Services version 5.0a18) 'Nickserv status' on a particular user reports: -NickServ- STATUS nickname 1 'Nickserv info' on the same nick reports: -NickServ- Nick nickname isn't registered. Given the status system of: 0 - no such user online or nickname not registered 1 - user not recognized as nickname's owner 2 - user recognized as owner via access list only 3 - user recognized as owner via password identification Status 1 seems more applicable to 'no identify attempt made' or 'failed identify' for an online user than 'an online user is using a nickname that nickserv knows nothing about'. In the case I mention, the status ought to remain 0 or there should be another status of 'nickname not registered' for when a nick is online but not registered. i.e it becomes: 0 - no such user online or nickname not registered 1 - user online but nickname not registered 2 - user not recognized as nickname's owner 3 - user recognized as owner via access list only 4 - user recognized as owner via password identification I guess it largely depends on the point of the command as to which system would be preferable but a status of 'user not recognized as nickname's owner' implies a user is using a registered nickname when they may not be so is inaccurate. The command seems to combine an 'is user online' with an 'is nickname registered' command so the more information it can provide, the more useful it will become. Personally I prefer system 2 (new status level) but am open to suggestions as to the wording of the status report :) Mark. From achurch at achurch.org Tue Feb 5 09:35:33 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Services segfault Message-ID: <3c5f28e6.57315@achurch.org> >I've found a pretty critical but easily reproducible bug: > >[17:13:26] -> *chanserv* set #chan restricted on >[17:13:26] -apollo.final-conflict.net- *** Global -- from >services.final-conflict.net: PANIC! buffer = :Russ PRIVMSG chanserv >:set #chan restricted on > >This happens with any channel, and any user who sets restricted on on >both Bahamut and Unreal. Okay, that was a stupid one... fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Feb 5 09:37:15 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Services 5.0 Miunor Bugs/glitches/suggestions Message-ID: <3c5f29ee.57460@achurch.org> >[snip Memoserv not sending the confirmation of sent messages] >> Out of curiosity, does this happen every time to affected >> users or just >> sometimes? Do you get any strange log messages? > >Yes it happens every time to affected users. Can you send me (privately) a copy of your databases so I can try it out myself? (be sure to mention which nicks have problems) --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Feb 5 09:40:37 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Nickname linking/coding question Message-ID: <3c5f2a32.57515@achurch.org> >I'm experimenting with the nickname linking code on ircservices-4.5.37. I've >been trying code it so that it links the specified nick to the current nick, >rather than linking the current nickname to the specified nick. I have done >this by basically reversing all of the "target" and "ni" references in >do_link. However, whenever it scans the nicknames for expirations, services >segfaults. > >Have any idea what I'm doing wrong or what could be happening... Or how I >could go about doing this? I'd just suggest waiting for Services 5.0, which has the behavior you describe for the LINK command. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Feb 5 09:42:34 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] NickServ Status "cosmetic" bug/suggestion Message-ID: <3c5f2a89.57564@achurch.org> >(Services version 5.0a18) > >'Nickserv status' on a particular user reports: > >-NickServ- STATUS nickname 1 > >'Nickserv info' on the same nick reports: > >-NickServ- Nick nickname isn't registered. Fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ From rplume at cablemo.net Mon Feb 4 16:46:40 2002 From: rplume at cablemo.net (RP) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Nickname linking/coding question References: <3c5f2a32.57515@achurch.org> Message-ID: <003501c1adde$93a0f9f0$9a96d741@ryan> ----- Original Message ----- From: "Andrew Church" To: Sent: Monday, February 04, 2002 6:40 PM Subject: Re: [IRCServices Coding] Nickname linking/coding question > >I'm experimenting with the nickname linking code on ircservices-4.5.37. I've > >been trying code it so that it links the specified nick to the current nick, > >rather than linking the current nickname to the specified nick. I have done > >this by basically reversing all of the "target" and "ni" references in > >do_link. However, whenever it scans the nicknames for expirations, services > >segfaults. > > > >Have any idea what I'm doing wrong or what could be happening... Or how I > >could go about doing this? > > I'd just suggest waiting for Services 5.0, which has the behavior you > describe for the LINK command. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > *nods* I've already checked it out. I prefer this system over the 5.0 system because with the 5.0 system, you appear to have to specify a main nickname. My goal is to create a link system similiar to austnet's. It seems much more.... versatile. From achurch at achurch.org Tue Feb 5 09:51:48 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Nickname linking/coding question Message-ID: <3c5f2d71.60635@achurch.org> >I prefer this system over the 5.0 system because with the 5.0 system, you >appear to have to specify a main nickname. Only because channel entries have to have something to display in place of a nickgroup number; in all other respects all the nicks are the same. >My goal is to create a link system similiar to austnet's. It seems much >more.... versatile. What kind of system is that, exactly? --Andrew Church achurch@achurch.org http://achurch.org/ From rplume at cablemo.net Mon Feb 4 17:43:41 2002 From: rplume at cablemo.net (RP) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Nickname linking/coding question References: <3c5f2d71.60635@achurch.org> Message-ID: <003f01c1ade6$8aa33680$9a96d741@ryan> ----- Original Message ----- From: "Andrew Church" To: Sent: Monday, February 04, 2002 6:51 PM Subject: Re: [IRCServices Coding] Nickname linking/coding question > >I prefer this system over the 5.0 system because with the 5.0 system, you > >appear to have to specify a main nickname. > > Only because channel entries have to have something to display in > place of a nickgroup number; in all other respects all the nicks are the > same. > > >My goal is to create a link system similiar to austnet's. It seems much > >more.... versatile. > > What kind of system is that, exactly? > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > It's a system that allows all linked nicknames to still have their own memobox. When you switch to a linked nickname, it'll say how many memos you have, and how many you have on your linked nicknames. It also allows you to add links to the currently used nickname, which is what I was inquiring about. Channel entries still display the nickname that was originally was added. Basically, all of the nicknames exist on their own; they aren't copies of each other. The system itself only does two basic things: a. when you identify, it automatically identifies to all linked nicknames b. if you join a channel and have a linked nickname in the database, it'll see that and auto-op you. It also allows cross-linking. However, I'm probably going to want a system that automatically crosslinks them (which ircservices already does indirectly).. In my opinion, the new nickgroup code seems a bit of an overkill for what I'm trying to accomplish. The system I'm wanting to use could probably be built by using the original nickname structure (ni) and adding an array or something similiar to the new structure (ngi) that points to the linked nicknames and various pieces of information. I'm sure there's a better way that I haven't thought of. Suggestions are welcome. ^_^ I think I'm definitely going to stick with my current base instead of converting to the style 5.0 uses though. It seems a bit tedious to work with.. Don't get me wrong - you've done well so far and the idea of a services package with module support is a great idea, but when you have to search through function after function (and usually in 3-5 files) in unfamiliar code to find something being called, it becomes too much work. From achurch at achurch.org Tue Feb 5 10:44:26 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Nickname linking/coding question Message-ID: <3c5f39cd.63325@achurch.org> So it looks like the differences are (1) separate memos for separate nicks and (2) keeping the same nick on the channel access list. I think (1) is a PITA; (2) is a good idea and something I've been thinking about (e.g. store nickname in ChanAccess as well) but a low priority. You're of course welcome to fork Services and start your own project; that's what open source is about, after all. --Andrew Church achurch@achurch.org http://achurch.org/ >It's a system that allows all linked nicknames to still have their own >memobox. When you switch to a linked nickname, it'll say how many memos you >have, and how many you have on your linked nicknames. It also allows you to >add links to the currently used nickname, which is what I was inquiring >about. Channel entries still display the nickname that was originally was >added. > >Basically, all of the nicknames exist on their own; they aren't copies of >each other. The system itself only does two basic things: > a. when you identify, it automatically identifies to all linked >nicknames > b. if you join a channel and have a linked nickname in the database, >it'll see that and auto-op you. > >It also allows cross-linking. However, I'm probably going to want a system >that automatically crosslinks them (which ircservices already does >indirectly).. > >In my opinion, the new nickgroup code seems a bit of an overkill for what >I'm trying to accomplish. The system I'm wanting to use could probably be >built by using the original nickname structure (ni) and adding an array or >something similiar to the new structure (ngi) that points to the linked >nicknames and various pieces of information. > >I'm sure there's a better way that I haven't thought of. Suggestions are >welcome. ^_^ > >I think I'm definitely going to stick with my current base instead of >converting to the style 5.0 uses though. It seems a bit tedious to work >with.. Don't get me wrong - you've done well so far and the idea of a >services package with module support is a great idea, but when you have to >search through function after function (and usually in 3-5 files) in >unfamiliar code to find something being called, it becomes too much work. > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Tue Feb 5 23:09:13 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Services 5.0 alpha 19 released Message-ID: <3c5fe859.36777@achurch.org> Services 5.0 alpha 19 is out in the usual place, thanks in significant part to Mark Hetherington. Also (translators take note), there have been a number of changes to language file messages; the list of changed messages which need retranslation is as follows: (any message without comments should be considered completely changed; if you want a diff from alpha 18, let me know) OPER_HELP_RAW (limited to Services super-user, not admins) OPER_HELP_SET (SUPASS limited to super-user) OPER_HELP_EXCEPTION OPER_HELP_SLINE ("Combinations... are not permitted" -> "also permitted") OPER_HELP_AKILL ("Combinations... are not permitted" -> "also permitted") OPER_HELP_CLEARMODES CHAN_OPER_HELP_GETPASS (added line about encryption) CHAN_HELP_SET_MLOCK CHAN_COMMANDS_INVITE NICK_OPER_HELP_GETPASS (changed/moved line about encryption) NICK_HELP_UNSET_REQ_EMAIL NICK_HELP_UNSET NICK_HELP_SET_INFO (new message) NICK_HELP_SET (added INFO) Changes in version 5.0 alpha 19 ------------------------------- 2002/02/05 Fixed corrupted messages after REHASH. Reported by Mark Hetherington and others. 2002/02/05 Added wallops on OperServ REHASH or SIGHUP. Suggested by Mark Hetherington 2002/02/05 Fixed unregistered nicks getting a STATUS of 1. Reported by Mark Hetherington 2002/02/05 Fixed crash with ChanServ SET RESTRICTED on new channels. Reported by Russ Garrett 2002/02/04 Fixes and changes suggested by Mark Hetherington : - LIST command no longer shown to non-opers if ListOpersOnly enabled. - GETPASS can now be disabled. - HELP messages on Unreal no longer cause errors. - Signals no longer cause select() messages in log. - Fixed bug causing oper.db to grow relentlessly. - Fixed bug in reading/writing exception.db. 2002/02/03 Renamed ChanServ SET TOPIC command to TOPIC. Suggested by Jollino 2002/02/03 Fixed bug causing autovoice to break on servers without halfops. Reported by Russ Garrett 2002/02/03 Updated numerous help messages. --Andrew Church achurch@achurch.org http://achurch.org/ From eengin at talesoft.de Tue Feb 5 06:31:51 2002 From: eengin at talesoft.de (Ekim Engin) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Suggestion for sessionlimit exception Message-ID: <004301c1ae51$daa03140$092a14ac@hadiko.de> Hi, There are a lot of companies and cybercafe's which do not have a static ip/host. The idea would be to allow nicks to be included into the exception list resulting in the following: If one of the nicks on the session limit nick list identifies the sessionlimit for the host of this nick is set to a preset value. e.g. - defaut session limit is 5 connections - the session limit for the nick foobar is 10 nick foobar identifies from foobar!blah@blups.blips.org ==> blups.blips.org gets a sessionlimit of 10 this modified limit of 10 is set as the sessionlimit for blups.blips.org until foobar identifes from a different host Greets Ekim "Talesin" Engin PGP-Fingerprint: 8627 180C 1397 34FB 6BB0 8B65 9CBF 8ED5 456C 48F9 --- Chat begins as it ends - without reason From siliconai at aus3d.net Tue Feb 5 06:43:56 2002 From: siliconai at aus3d.net (SiliconAI) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Nickserv Segmentation fault In-Reply-To: <004301c1ae51$daa03140$092a14ac@hadiko.de> References: <004301c1ae51$daa03140$092a14ac@hadiko.de> Message-ID: <1683.144.132.15.170.1012920236.squirrel@webmail.aus3d.net> One of my staff found this in alpha 17 a few days ago, just compiled alpha 19 and it still happens: [Feb 06 01:36:38 2002] PANIC! buffer = :SiliconAI PRIVMSG nickserv :sendpass [Feb 06 01:36:38 2002] Services terminating: Segmentation fault The mail still gets sent out though. -- SiliconAI From andrewk at isdial.net Tue Feb 5 06:46:26 2002 From: andrewk at isdial.net (Andrew Kempe) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Suggestion for sessionlimit exception References: <004301c1ae51$daa03140$092a14ac@hadiko.de> Message-ID: <00e401c1ae53$e38b2470$9c011ac4@africa.didata.local> Can you give me some example real hosts this would happen for? I just want to see what they look like. Thanks, Andrew ----- Original Message ----- From: "Ekim Engin" To: Sent: Tuesday, February 05, 2002 4:31 PM Subject: [IRCServices Coding] Suggestion for sessionlimit exception > Hi, > > There are a lot of companies and cybercafe's which do not have > a static ip/host. The idea would be to allow nicks to be included > into the exception list resulting in the following: > > If one of the nicks on the session limit nick list identifies > the sessionlimit for the host of this nick is set to a preset > value. e.g. > > - defaut session limit is 5 connections > - the session limit for the nick foobar is 10 > > nick foobar identifies from foobar!blah@blups.blips.org > ==> blups.blips.org gets a sessionlimit of 10 > this modified limit of 10 is set as the sessionlimit for > blups.blips.org until foobar identifes from a different host > > Greets > > Ekim "Talesin" Engin > > PGP-Fingerprint: 8627 180C 1397 34FB 6BB0 8B65 9CBF 8ED5 456C 48F9 > > --- > Chat begins as it ends - without reason > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > From eengin at talesoft.de Tue Feb 5 07:02:25 2002 From: eengin at talesoft.de (Ekim Engin) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Suggestion for sessionlimit exception In-Reply-To: <00e401c1ae53$e38b2470$9c011ac4@africa.didata.local> Message-ID: <004c01c1ae56$1f738750$092a14ac@hadiko.de> Most of them do not resolve at all, but as an example: abn5-25.ist-avrupa-ports.kablonet.net.tr (resolves into: 195.174.5.25) when this user disconnected his cable modem and reconnected he got abn5-29.ist-avrupa-ports.kablonet.net.tr (resolves into: 195.174.5.29) but i do not get the point why it is important how they look like :) Greets Ekim > -----Original Message----- > From: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net] On > Behalf Of Andrew Kempe > Sent: Tuesday, February 05, 2002 3:46 PM > To: ircservices-coding@ircservices.za.net > Subject: Re: [IRCServices Coding] Suggestion for sessionlimit > exception > > > Can you give me some example real hosts this would happen > for? I just want to see what they look like. > > Thanks, Andrew > > ----- Original Message ----- > From: "Ekim Engin" From andrewk at isdial.net Tue Feb 5 07:08:49 2002 From: andrewk at isdial.net (Andrew Kempe) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Suggestion for sessionlimit exception References: <004c01c1ae56$1f738750$092a14ac@hadiko.de> Message-ID: <010201c1ae57$0415a640$9c011ac4@africa.didata.local> I'm trying to see an easy way of solving your problem. I'm just not sure how many people have this problem too. Andrew ----- Original Message ----- From: "Ekim Engin" To: Sent: Tuesday, February 05, 2002 5:02 PM Subject: RE: [IRCServices Coding] Suggestion for sessionlimit exception > Most of them do not resolve at all, > > but as an example: > abn5-25.ist-avrupa-ports.kablonet.net.tr (resolves into: > 195.174.5.25) > when this user disconnected his cable modem and reconnected he got > abn5-29.ist-avrupa-ports.kablonet.net.tr (resolves into: > 195.174.5.29) > > but i do not get the point why it is important how they look like :) > > Greets Ekim > > > -----Original Message----- > > From: ircservices-coding-admin@ircservices.za.net > > [mailto:ircservices-coding-admin@ircservices.za.net] On > > Behalf Of Andrew Kempe > > Sent: Tuesday, February 05, 2002 3:46 PM > > To: ircservices-coding@ircservices.za.net > > Subject: Re: [IRCServices Coding] Suggestion for sessionlimit > > exception > > > > > > Can you give me some example real hosts this would happen > > for? I just want to see what they look like. > > > > Thanks, Andrew > > > > ----- Original Message ----- > > From: "Ekim Engin" > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > From mark at mhetherington.demon.co.uk Tue Feb 5 15:41:55 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] A few new bugs/suggestions Message-ID: 1) EnableGetPass setting in Services 5.0a19 problem. The help removal when not enabled works perfectly but the directive only affects the help messages at the moment. The command itself is still accessible. Basically it is missing an if (EnableGetpass) around the code in chanserv and nickserv main.c, or an if (!EnableGetpass) possibly_do_some_message_then_return; 2) Minor cosmetic issue with the new oper only mention of the list command on the Chanserv help display. Since CHAN_OPER_HELP_COMMANDS_FORBID includes 4 commands and then a reference to extra powers on DROP etc, it might look better if the list command check and print was before the forbid command in the help display so that the text flows correctly. 3) This problem actually happened on 5.0a18 but I have been unable to reproduce on that version so it might still be in 5.0a19. I am reporting for the record while I research further. From the log file: PANIC! buffer = :gaspode2 PRIVMSG ChanServ@services.ctcp.net :akick #xdigital add *~woody@*!* Services terminating: Segmentation fault When trying to reproduce myself, I did notice that services reformats the mask to: *~woody@*!*@* Looking at the code, it is easy to see why it reformats in this manner, but I wonder if this was at all contributory to the crash. This creates a couple of suggestions in addition to the crash report. A) Maybe it would be possible to check for the ordering of *!*@* and reject immediately rather than creating an even more erroneous mask for entry into the akick list. This would be helpful to users creating masks. B) Could the mask format be added to the help for AKICK or at least a reference to another help reference available to users that describes masks accurately. Maybe some examples similar to those for nickserv access lists. I will try and get as many people as possible testing the akick comand to attempt to get a reproducable case. While writing this, I have managed to get a different user reproducing it with pretty much any other user. I am not sure what the pattern is since I am still unable to produce the problem myself. An IRCop/Services Admin with a Nickserv status of 0 can obviously manipulate the akick list of any channel and this will produce the problem everytime. For users to have the problem, it seems that they need to be NS status 2 (recognised by access list but not by password) to reproduce the problem. I am still working on the exact scenario, but it does seem to be related to NickServ level when issuing the command. 4) Although documented as an issue wrt to the httpd display, the channel '#' seems to have various other problems that are possibly related to IRCd and clients (for example invisible to /list regardless of oper level). This seems to make it preferable that the channel is not actually supported by services at all particularly if is has problems with any area of services functionality (e.g. httpd module). I know the simple workaround is to forbid the channel but on a new installation, anything potentially erroneous ought to be guarded against. The user on our network who registered that channel did it purely because it is usually banned on networks or causes severe problems with other services packages and appears to be an exploit that various people try to abuse. It is encouraging that it has so little effect wrt IRCServices, but if there are any potential long term problems, IMO it is worth addressing sooner rather than later. Mark. From achurch at achurch.org Wed Feb 6 10:24:30 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Suggestion for sessionlimit exception Message-ID: <3c60862a.66722@achurch.org> I thought I already went over this once (though maybe it was in private mail, I don't recall): I don't want to do this because it would complicate and slow down session checking even more for little gain. Really, what use is there for allowing more than 3 or 5 sessions for a _single user_? --Andrew Church achurch@achurch.org http://achurch.org/ >Hi, > >There are a lot of companies and cybercafe's which do not have >a static ip/host. The idea would be to allow nicks to be included >into the exception list resulting in the following: > >If one of the nicks on the session limit nick list identifies >the sessionlimit for the host of this nick is set to a preset >value. e.g. > >- defaut session limit is 5 connections >- the session limit for the nick foobar is 10 > >nick foobar identifies from foobar!blah@blups.blips.org >==> blups.blips.org gets a sessionlimit of 10 >this modified limit of 10 is set as the sessionlimit for >blups.blips.org until foobar identifes from a different host > >Greets > >Ekim "Talesin" Engin > >PGP-Fingerprint: 8627 180C 1397 34FB 6BB0 8B65 9CBF 8ED5 456C 48F9 > >--- >Chat begins as it ends - without reason > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From eengin at talesoft.de Tue Feb 5 17:45:30 2002 From: eengin at talesoft.de (Ekim Engin) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Suggestion for sessionlimit exception In-Reply-To: <3c60862a.66722@achurch.org> Message-ID: <000201c1aeaf$f58be360$092a14ac@hadiko.de> The idea behind was to allow a cybercafe with e.g. 20 computers to connect while limiting clonebots from others. It i a feature i use on my network with an eggdrop bot watching the services log and adding the nedded exceptions, after all it was just a suggestion... Grets Ekim > -----Original Message----- > From: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net] On > Behalf Of Andrew Church > Sent: Wednesday, February 06, 2002 2:25 AM > To: ircservices-coding@ircservices.za.net > Subject: Re: [IRCServices Coding] Suggestion for sessionlimit > exception > > > I thought I already went over this once (though maybe it was in > private mail, I don't recall): I don't want to do this > because it would > complicate and slow down session checking even more for little gain. > Really, what use is there for allowing more than 3 or 5 sessions for a > _single user_? > > --Andrew Church > achurch@achurch.org > http://achurch.org/ From achurch at achurch.org Wed Feb 6 23:15:55 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Nickserv Segmentation fault Message-ID: <3c613aa3.26043@achurch.org> Fixed, thanks. >One of my staff found this in alpha 17 a few days ago, just compiled alpha >19 and it still happens: > >[Feb 06 01:36:38 2002] PANIC! buffer = :SiliconAI PRIVMSG nickserv :sendpass >[Feb 06 01:36:38 2002] Services terminating: Segmentation fault > >The mail still gets sent out though. > >-- >SiliconAI > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Thu Feb 7 00:58:44 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] A few new bugs/suggestions Message-ID: <3c615a55.40167@achurch.org> >1) EnableGetPass setting in Services 5.0a19 problem. The help removal when >not enabled works perfectly but the directive only affects the help messages >at the moment. The command itself is still accessible. Basically it is >missing an > if (EnableGetpass) >around the code in chanserv and nickserv main.c, or an > if (!EnableGetpass) possibly_do_some_message_then_return; Fixed (I completely forgot about doing this, stupid mistake). >2) Minor cosmetic issue with the new oper only mention of the list command >on the Chanserv help display. Since CHAN_OPER_HELP_COMMANDS_FORBID includes >4 commands and then a reference to extra powers on DROP etc, it might look >better if the list command check and print was before the forbid command in >the help display so that the text flows correctly. Fixed. >3) This problem actually happened on 5.0a18 but I have been unable to >reproduce on that version so it might still be in 5.0a19. I am reporting for >the record while I research further. From the log file: > >PANIC! buffer = :gaspode2 PRIVMSG ChanServ@services.ctcp.net :akick >#xdigital add *~woody@*!* >Services terminating: Segmentation fault Hm, not sure why this would segfault, but I've added checks as you suggest to prevent @ in the nickname part or a missing hostname. If you can pinpoint the problem (especially if it doesn't seem to be related to this) please let me know. >B) Could the mask format be added to the help for AKICK or at least a >reference to another help reference available to users that describes masks >accurately. Maybe some examples similar to those for nickserv access lists. Done. >4) Although documented as an issue wrt to the httpd display, the channel '#' >seems to have various other problems that are possibly related to IRCd and >clients (for example invisible to /list regardless of oper level). This >seems to make it preferable that the channel is not actually supported by >services at all particularly if is has problems with any area of services >functionality (e.g. httpd module). > >I know the simple workaround is to forbid the channel but on a new >installation, anything potentially erroneous ought to be guarded against. >The user on our network who registered that channel did it purely because it >is usually banned on networks or causes severe problems with other services >packages and appears to be an exploit that various people try to abuse. It >is encouraging that it has so little effect wrt IRCServices, but if there >are any potential long term problems, IMO it is worth addressing sooner >rather than later. Good idea, done (no longer allowed to be registered or forbidden; all other functions will just return "not registered"). Do you happen to recall where # was mentioned wrt the httpd stuff? (I remember writing something to that effect, I just don't recall where, and I can't seem to find it at the moment to fix it...) Thanks again for all your help and suggestions. --Andrew Church achurch@achurch.org http://achurch.org/ From p_levesque at sympatico.ca Wed Feb 6 03:51:31 2002 From: p_levesque at sympatico.ca (Philippe Levesque) Date: Sat Oct 23 23:09:13 2004 Subject: [IRCServices Coding] Suggestion for sessionlimit exception References: <000201c1aeaf$f58be360$092a14ac@hadiko.de> Message-ID: <3C6118C2.BDDD1EA6@sympatico.ca> A easy way to fix that, for a cybercafe, is simply to add a router between them and the net, so each ip gooing out will be the same for all the 20 machine, so a exception will be easy to add on a host :] And even if your ip is non static from a modem cable, you simply keep the router open, and let that ip be online for a lotta of time. :P Phil Ekim Engin wrote: > The idea behind was to allow a cybercafe with e.g. 20 computers to > connect while limiting clonebots from others. > > It i a feature i use on my network with an eggdrop bot watching the > services log and adding the nedded exceptions, > after all it was just a suggestion... > > Grets Ekim > > > -----Original Message----- > > From: ircservices-coding-admin@ircservices.za.net > > [mailto:ircservices-coding-admin@ircservices.za.net] On > > Behalf Of Andrew Church > > Sent: Wednesday, February 06, 2002 2:25 AM > > To: ircservices-coding@ircservices.za.net > > Subject: Re: [IRCServices Coding] Suggestion for sessionlimit > > exception > > > > > > I thought I already went over this once (though maybe it was in > > private mail, I don't recall): I don't want to do this > > because it would > > complicate and slow down session checking even more for little gain. > > Really, what use is there for allowing more than 3 or 5 sessions for a > > _single user_? > > > > --Andrew Church > > achurch@achurch.org > > http://achurch.org/ > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From mark at mhetherington.demon.co.uk Wed Feb 6 10:35:44 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] A few new bugs/suggestions In-Reply-To: <3c615a55.40167@achurch.org> Message-ID: > Good idea, done (no longer allowed to be registered or forbidden; all > other functions will just return "not registered"). Do you happen to > recall where # was mentioned wrt the httpd stuff? (I remember writing > something to that effect, I just don't recall where, and I can't seem to > find it at the moment to fix it...) It is in example-modules.conf - the httpd/redirect section: "Note 2: The channel "#" cannot be accessed via this module." Mark. From mark at mhetherington.demon.co.uk Wed Feb 6 13:52:13 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Akick segfault [was: A few new bugs/suggestions] In-Reply-To: <3c615a55.40167@achurch.org> Message-ID: The original user which managed to segfault services had previously issued the GHOST command on his actual nick of Gaspode from Gaspode2. Gaspode has AKICK rights on the #xdigital channel in question. However, Gaspode2 did not have ops in the channel since this nick not registered or linked to another nick. Although I cannot get hold of his /ns status report at the time, he should not have had any rights wrt the channel. I now have two 100% reproducable cases: 1) Log onto IRC, do not ident to Nickserv, Oper up. 2) Issue any /cs akick #channel command. The channel does not have to be in use but does have to be registered with Chanserv. 3) Segfault will happen. And... 1) Log onto IRC as a plain user with an unregistered nickname 2) Issue any /cs akick #channel command. The channel does not have to be in use but does have to be registered with Chanserv. 3) Segfault will happen. Basically any user using an unregistered nick can bring services down by issuing any /cs akick #channel command. Mark. From mark at mhetherington.demon.co.uk Wed Feb 6 14:40:32 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 sendmail query In-Reply-To: Message-ID: Would it be possible for the sendmail module to set the 'return path' or the 'reply to' field in the sendmail message creation to the email setup in the configuration? At present, messages from services have the 'return path' set as the user under which they run, which is not necessarily the correct address for any replies. Reply to from an email client appears to get the correct address in most cases, but we have had some responses to the account under which services runs rather than the email address used for services. Most of these seem to be from autoresponders which I can only assume used 'return path' and/or 'reply to' rather than the 'from' address. Mark. From mark at mhetherington.demon.co.uk Wed Feb 6 15:06:46 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Operserv Admin and Oper list bug In-Reply-To: Message-ID: Since version 5.0a19 (with the fix for ever increasing oper.db size), services admins are now also listed under the services operators list. Deleting a nickname from the services operator list which is duplicated in this manner will also delete that person from the services admins list. IIRC in previous versions, these lists were exclusive which I believe is the correct operation for the lists. It seems that if (ngi->os_priv >= NP_SERVOPER) should be if (ngi->os_priv == NP_SERVOPER) in modules/operserv/main.c function do_oper(). Mark. From achurch at achurch.org Thu Feb 7 14:28:24 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Akick segfault [was: A few new bugs/suggestions] Message-ID: <3c621109.76111@achurch.org> Fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ >The original user which managed to segfault services had previously issued >the GHOST command on his actual nick of Gaspode from Gaspode2. Gaspode has >AKICK rights on the #xdigital channel in question. However, Gaspode2 did not >have ops in the channel since this nick not registered or linked to another >nick. > >Although I cannot get hold of his /ns status report at the time, he should >not have had any rights wrt the channel. > >I now have two 100% reproducable cases: > >1) Log onto IRC, do not ident to Nickserv, Oper up. >2) Issue any /cs akick #channel command. The channel does not have to be in >use but does have to be registered with Chanserv. >3) Segfault will happen. > >And... > >1) Log onto IRC as a plain user with an unregistered nickname >2) Issue any /cs akick #channel command. The channel does not have to be in >use but does have to be registered with Chanserv. >3) Segfault will happen. > >Basically any user using an unregistered nick can bring services down by >issuing any /cs akick #channel command. > >Mark. > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Thu Feb 7 14:31:19 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 sendmail query Message-ID: <3c62119e.76203@achurch.org> >Would it be possible for the sendmail module to set the 'return path' [...] >field in the sendmail message creation to the email setup in the >configuration? Sendmail won't let you do this (unless it's configured to do so for the user Services is running as). Either run Services under a username valid for replies, or use the SMTP module, which is better anyway. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Thu Feb 7 14:51:52 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Operserv Admin and Oper list bug Message-ID: <3c621608.77470@achurch.org> Fixed (the fix below is wrong but the report is right). --Andrew Church achurch@achurch.org http://achurch.org/ >Since version 5.0a19 (with the fix for ever increasing oper.db size), >services admins are now also listed under the services operators list. > >Deleting a nickname from the services operator list which is duplicated in >this manner will also delete that person from the services admins list. > >IIRC in previous versions, these lists were exclusive which I believe is the >correct operation for the lists. > >It seems that > if (ngi->os_priv >= NP_SERVOPER) >should be > if (ngi->os_priv == NP_SERVOPER) > >in modules/operserv/main.c function do_oper(). > >Mark. > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From jollino at sogno.net Thu Feb 7 15:46:20 2002 From: jollino at sogno.net (Jollino) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services' segfault Message-ID: <20020207144620.B448F184D2@mail.sogno.net> Hello there, on our network we are using Services 4.5.38 (compiled for Unreal) connected to Unreal3.1.1-Darkshades. The server running services has just been victim of an attack, a syn flood I think, since it lagged and then splitted, and services just went down. This is the backtrace: Core was generated by `./services'. Program terminated with signal 11, Segmentation fault. /lib/libshow.so.0.9.5: No such file or directory. #0 0x4009cdc3 in ?? () from /lib/libc.so.6 (gdb) bt #0 0x4009cdc3 in ?? () from /lib/libc.so.6 #1 0x40019dcf in ?? () #2 0x4001a80b in ?? () #3 0x4001ba29 in ?? () #4 0x4001a8ee in ?? () #5 0x4001a41a in ?? () #6 0x805576e in close_db (f=0x8199b90) at datafiles.c:276 #7 0x8062b26 in save_os_dbase () at operserv.c:341 #8 0x8058d8b in main (ac=1, av=0xbffffca4, envp=0xbffffcac) at main.c:283 #9 0x400619cb in ?? () from /lib/libc.so.6 Everything seems fine now, but I'm wondering about what happened. The only difference from our old version of services is that we compiled in the StatServ feature. I hope I'm not off-topic :) Regards Jollino -- Jollino [jollino at sogno dot net - jollino at chieti dot ch] IRC Operator on irc.discussioni.org Webmaster of http://www.sogno.net and related services Active content provider of http://www.chieti.ch Italian Dreamer no. 2305 (www.italiandreamers.net) Longe vivu la verda stelo de Esperanto! Eg atart agap?en... ___________________________________ Inviato da Sogno.net, http://mail.sogno.net From achurch at achurch.org Fri Feb 8 00:54:38 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services' segfault Message-ID: <3c62a36b.35041@achurch.org> >Hello there, >on our network we are using Services 4.5.38 (compiled for Unreal) connected to Unreal3.1.1-Darkshades. >The server running services has just been victim of an attack, a syn flood I think, since it lagged and then splitted, and services just went down. > >This is the backtrace: >Core was generated by `./services'. >Program terminated with signal 11, Segmentation fault. >/lib/libshow.so.0.9.5: No such file or directory. >#0 0x4009cdc3 in ?? () from /lib/libc.so.6 >(gdb) bt [...] >#6 0x805576e in close_db (f=0x8199b90) at datafiles.c:276 >#7 0x8062b26 in save_os_dbase () at operserv.c:341 >#8 0x8058d8b in main (ac=1, av=0xbffffca4, envp=0xbffffcac) at main.c:283 This is bizarre, and looks like memory corruption; can you reproduce it consistently? --Andrew Church achurch@achurch.org http://achurch.org/ From jollino at sogno.net Thu Feb 7 08:21:18 2002 From: jollino at sogno.net (Jollino) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services' segfault In-Reply-To: <3c62a36b.35041@achurch.org> Message-ID: Gioved?, febbraio 7, 2002, alle 04:54 , Andrew Church ha scritto: > This is bizarre, and looks like memory corruption; can you > reproduce > it consistently? Not really. As I said, I suppose the machine on which the services are running (which also is our main hub server) was probably under attack - just like yesterday, *sigh*. The whole network froze and other servers (including mine) splitted, and when we came back there was no sign of services, just that core file. I didn't find anything strange in the logs either. I didn't check the cpu load when I logged onto the machine, but I've heard of some attacks that manage to rise the load to 100%. Could that be the case? -- Jollino [jollino at sogno dot net - jollino at chieti dot ch] IRC Operator on irc.discussioni.org Webmaster of http://www.sogno.net and related services Active content provider of http://www.chieti.ch Italian Dreamer no. 2305 (www.italiandreamers.net) Longe vivu la verda stelo de Esperanto! Eg atart agap?en... From achurch at achurch.org Fri Feb 8 01:45:48 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services' segfault Message-ID: <3c62afab.37031@achurch.org> >> This is bizarre, and looks like memory corruption; can you >> reproduce >> it consistently? > >Not really. As I said, I suppose the machine on which the services are >running (which also is our main hub server) was probably under attack - >just like yesterday, *sigh*. >The whole network froze and other servers (including mine) splitted, and >when we came back there was no sign of services, just that core file. I >didn't find anything strange in the logs either. >I didn't check the cpu load when I logged onto the machine, but I've >heard of some attacks that manage to rise the load to 100%. Could that >be the case? Such attacks are possible, but I doubt those are related to the crash. It's more likely the flood triggered a bug somewhere in Services that corrupted memory--I've heard reports of such but have never managed to track it down. Version 5.0 should be more stable in that regard, I hope. --Andrew Church achurch@achurch.org http://achurch.org/ From rplume at cablemo.net Thu Feb 7 15:24:15 2002 From: rplume at cablemo.net (RP) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services' segfault References: <3c62a36b.35041@achurch.org> Message-ID: <001701c1b02e$90b32bd0$8cfeda42@ryan> > >#6 0x805576e in close_db (f=0x8199b90) at datafiles.c:276 > >#7 0x8062b26 in save_os_dbase () at operserv.c:341 > >#8 0x8058d8b in main (ac=1, av=0xbffffca4, envp=0xbffffcac) at main.c:283 > > This is bizarre, and looks like memory corruption; can you reproduce > it consistently? > I have also had situations where what shows in the core file doesn't seem to have to do anything with the bug. I've actually been trying to fix one. I haven't even been able to locate where the bug is because the core file doesn't point it in the right place. What exactly does this mean, and what is the best way to go about finding/fixing these types of bugs? From achurch at achurch.org Fri Feb 8 08:29:06 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services' segfault Message-ID: <3c630e70.50711@achurch.org> >I have also had situations where what shows in the core file doesn't seem to >have to do anything with the bug. I've actually been trying to fix one. I >haven't even been able to locate where the bug is because the core file >doesn't point it in the right place. > >What exactly does this mean, and what is the best way to go about >finding/fixing these types of bugs? Depending on what Services was doing when it crashed and what caused the problem, gdb may not be able to get backtrace information from the stack and only print out garbage pointers. If this happens, about the only thing you can do is put in debugging statements or run Services under gdb and set breakpoints around where you think the bug is happening, and hope you manage to catch it. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Fri Feb 8 13:18:29 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 alpha 20 -- you know you want it Message-ID: <3c6354be.06157@achurch.org> Services 5.0 alpha 20 is out at the usual place. The big change this time is that channel access levels have been rescaled; they now range from -999 to 999 (1/10 of the previous range), and default levels have been spread out by a factor of 10, so it looks something like this: 100 AUTOPROTECT (SOP) 50 AUTOOP (AOP) 40 AUTOHALFOP (HOP) 30 AUTOVOICE (VOP) -10 AUTODEOP -20 NOJOIN I toyed with the idea of spreading out AOP/HOP/VOP and AUTODEOP/NOJOIN even more but figured it would be easier on people to leave them as is. At any rate, if you don't like this, tough; I'm not changing my mind. (Bribes are accepted, but will get you absolutely nothing except my gratitude. :) ) Many other bug fixes and stuff have been done too; see below. In summary, go get it now--you know you want it. Changes in version 5.0 alpha 20 ------------------------------- 2002/02/08 Mode changes from a single event are now merged into a single mode message even if MergeChannelModes isn't set. 2002/02/08 Made ChanServ STATUS command available to normal users. 2002/02/08 Rescaled access levels to make better use of the available range (itself reduced to -999..999). 2002/02/08 Fixed bug causing modes for one channel to get sent to a different one in certain cases. 2002/02/08 EnableGetpass, NSEnableRegister, and CSEnableRegister options are now properly handled on reconfigure. 2002/02/07 Marked the mail/sendmail module as DISCOURAGED in example-ircservices.conf. 2002/02/07 Prevent registration of channel names not starting with "#" to avoid problems with ircds with other channel types. 2002/02/07 Fixes and changes suggested by Mark Hetherington : - GETPASS was not actually disabled if !EnableGetpass. - Cosmetic fix to ChanServ HELP COMMANDS for IRCops. - More robust checking on autokick masks. - The channel "#" can no longer be registered or forbidden. - Fixed crash on ChanServ AKICK from unregistered nick. - Services admins no longer duplicated in operator list. 2002/02/06 Fixed crash in SENDPASS command. Reported by SiliconAI 2002/02/06 Fixed bug causing confirmation messages for MemoServ SEND to not be sent. Reported by Mark Hetherington --Andrew Church achurch@achurch.org http://achurch.org/ From ron885 at axenet.org Thu Feb 7 20:40:40 2002 From: ron885 at axenet.org (Ron885) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 alpha 20 -- you know you want it References: <3c6354be.06157@achurch.org> Message-ID: <001101c1b05a$c35901a0$b9340344@HOME> you know... i mostly just read all the posts and d/l the services and enjoy it... but i really must say this. Andrew, you RULE. --- Ron885 TechAdmin @ irc.axenet.org From jollino at sogno.net Fri Feb 8 05:39:13 2002 From: jollino at sogno.net (Jollino) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 alpha 20 -- you know you want it In-Reply-To: <3c6354be.06157@achurch.org> Message-ID: <3D01109E-1C99-11D6-804C-003065BD4458@sogno.net> /me today looks at things with a critic eye, so I'm going to suggest some other features :P Venerd?, febbraio 8, 2002, alle 05:18 , Andrew Church ha scritto: > 2002/02/08 Mode changes from a single event are now merged into a > single mode message even if MergeChannelModes isn't set. this is cool! > 2002/02/08 Made ChanServ STATUS command available to normal users. this is cool, but if the network allows use of sop/aop/hop/vop it should return "sop" or "aop" or something like that, if the user level falls into the standard value (eg. 50 for aop); this would allow users that know nothing about numeric levels to still understand what privileges someone has. > 2002/02/08 Rescaled access levels to make better use of the available > range (itself reduced to -999..999). nice < cut > 2002/02/07 Prevent registration of channel names not starting with "#" > to avoid problems with ircds with other channel types. i got a bunch of help requests by people who kept doing: /cs register channel pass description instead of /cs register #channel pass description it would be nice if services warned the user to use #channel instead of channel (or if it registered #channel if just channel was given) > - The channel "#" can no longer be registered or forbidden. mmm? why? we used to have it on our network :) that's all, i have no more critic ideas.. your work is so perfect i can't really find anything bad about it :P regards daniele -- Jollino [jollino at sogno dot net - jollino at chieti dot ch] IRC Operator on irc.discussioni.org Webmaster of http://www.sogno.net and related services Active content provider of http://www.chieti.ch Italian Dreamer no. 2305 (www.italiandreamers.net) Longe vivu la verda stelo de Esperanto! Eg atart agap?en... From achurch at achurch.org Fri Feb 8 23:03:41 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 alpha 20 -- you know you want it Message-ID: <3c63dbec.76574@achurch.org> >> 2002/02/08 Made ChanServ STATUS command available to normal users. >this is cool, but if the network allows use of sop/aop/hop/vop it should >return "sop" or "aop" or something like that, if the user level falls >into the standard value (eg. 50 for aop); this would allow users that >know nothing about numeric levels to still understand what privileges >someone has. This isn't just a problem with STATUS but with a whole bunch of stuff (help messages etc.) and I'm hoping to get to it eventually. >> 2002/02/07 Prevent registration of channel names not starting with >"#" >> to avoid problems with ircds with other channel >types. >i got a bunch of help requests by people who kept doing: > /cs register channel pass description >instead of > /cs register #channel pass description >it would be nice if services warned the user to use #channel instead of > >channel (or if it registered #channel if just channel was given) I'll think about it. >> - The channel "#" can no longer be registered or >forbidden. >mmm? why? we used to have it on our network :) It causes too many potential problems (as was pointed out, it already can't be accessed from httpd/redirect), and since several other related programs have apparently suffered from bugs with that channel, Services itself may have bugs too; easier to just shut it out entirely than try and scour 56,000 lines of source code for potential problems. And yes, I'm aware I need to filter it out of databases and xml-import too; I meant to do that for this release but forgot. >that's all, i have no more critic ideas.. your work is so perfect i >can't really find anything bad about it :P Well, for one, the module system is horribly designed, but it's the best I can do with limited time, just like everything else. I guess all I can say is look forward to version 6.0, or something (: --Andrew Church achurch@achurch.org http://achurch.org/ From jollino at sogno.net Fri Feb 8 07:32:08 2002 From: jollino at sogno.net (Jollino) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 alpha 20 -- you know you want it In-Reply-To: <3c63dbec.76574@achurch.org> Message-ID: <036646B0-1CA9-11D6-804C-003065BD4458@sogno.net> Venerd?, febbraio 8, 2002, alle 03:03 , Andrew Church ha scritto: >>> 2002/02/08 Made ChanServ STATUS command available to normal users. >> this is cool, but if the network allows use of sop/aop/hop/vop it >> should >> return "sop" or "aop" or something like that, if the user level falls >> into the standard value (eg. 50 for aop); this would allow users that >> know nothing about numeric levels to still understand what privileges >> someone has. > > This isn't just a problem with STATUS but with a whole bunch of > stuff > (help messages etc.) and I'm hoping to get to it eventually. well, about the status (forgive the little off-topic here), wouldn't something like this work? level = status(nick, channel); /* ok i haven't read the code, but level is the numeric level ;) */ if (level == chanlevel(autoop, channel)) strlevel = "aop"; [what strange language is this? :P] >> that's all, i have no more critic ideas.. your work is so perfect i >> can't really find anything bad about it :P > > Well, for one, the module system is horribly designed, but it's the > best I can do with limited time, just like everything else. I guess > all I > can say is look forward to version 6.0, or something (: and i still use 4.5.38 :D btw, YAFS (yet another feature suggestion): wouldn't it be cool if statserv generated html pages about the status of the network during time, maybe with graphics? pretty much like netsplit.de does, but with smaller time intervals (e.g. every 15 mins or so), to get a real idea of how the network is doing. c'ya! -- Jollino [jollino at sogno dot net - jollino at chieti dot ch] IRC Operator on irc.discussioni.org Webmaster of http://www.sogno.net and related services Active content provider of http://www.chieti.ch Italian Dreamer no. 2305 (www.italiandreamers.net) Longe vivu la verda stelo de Esperanto! Eg atart agap?en... From martinpels at hotmail.com Fri Feb 8 10:03:53 2002 From: martinpels at hotmail.com (Martin Pels) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 alpha 20 -- you know you want it References: <3c6354be.06157@achurch.org> Message-ID: > The big change this > time is that channel access levels have been rescaled; they now range from > -999 to 999 (1/10 of the previous range), and default levels have been > spread out by a factor of 10, so it looks something like this: > > 100 AUTOPROTECT (SOP) > 50 AUTOOP (AOP) > 40 AUTOHALFOP (HOP) > 30 AUTOVOICE (VOP) > -10 AUTODEOP > -20 NOJOIN > Shouldn't this be changed in the language file too? There's a lot of stuff in there like: "By default, limited to users with level 10 access and above on the channel" From mark at mhetherington.demon.co.uk Fri Feb 8 13:42:33 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 alpha 20 Bug with handling of channel '#' In-Reply-To: <3c6354be.06157@achurch.org> Message-ID: Starting Services 5 with the channel '#' in the database will result in the deletion of all registered channels. It seems the code for checking for the '#' channel will set ci to NULL thereby triggering the failure flag resulting in the rest of the channel database not being read. As a workaround, drop the channel '#' before starting services 5.0a20. Mark. From mark at mhetherington.demon.co.uk Fri Feb 8 16:03:03 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 alpha 20 Segfault Bug with /cs info #channel In-Reply-To: Message-ID: A channel which was suspended tonight on Services 5.0a20 produces the following in response to /cs info #bots by a user who is not registered with nickserv: PANIC! buffer = :testing PRIVMSG ChanServ@services.ctcp.net :info #bots Services terminating: Segmentation fault Such a user gets the following text before the segfault: -ChanServ- Founder: Mark -ChanServ- Description: Bots -ChanServ- Registered: Oct 29 00:33:05 2000 BST -ChanServ- Last used: Feb 08 23:23:03 2002 GMT This has also happened with channels which are not suspended: PANIC! buffer = :testing PRIVMSG ChanServ@services.ctcp.net :info #trivia Services terminating: Segmentation fault in which case the user sees: -ChanServ- Founder: Mark -ChanServ- Description: Trivia Channel -ChanServ- Registered: Feb 16 23:14:55 2001 GMT -ChanServ- Last used: Dec 06 00:05:32 2001 GMT -ChanServ- Last topic: Trivial Pursuit - join and type 'tt help' for more info -ChanServ- Topic set by: M This channel was ot in use at the time. However, another channel which is not susupended and is in use produces: PANIC! buffer = :testing PRIVMSG ChanServ@services.ctcp.net :info #opers Services terminating: Segmentation fault -ChanServ- Information for channel #opers: -ChanServ- Founder: Mark -ChanServ- Description: Help Channel -ChanServ- Registered: Sep 25 23:30:11 2000 BST -ChanServ- Last used: Feb 08 21:38:22 2002 GMT -ChanServ- Last topic: Help channel -ChanServ- Topic set by: M The crash appears to happen around where Options and/or Mode lock should be printed so I assume it is specific options which cause the crash. Mark. From mark at mhetherington.demon.co.uk Fri Feb 8 16:23:26 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 alpha 20 Small Bug with new channel auto mode merge In-Reply-To: Message-ID: Since the introduction of automatic merging of modes regardless of the merge modes setting in the configuration, Chanserv will often produce the following: *** ChanServ sets mode: +oa nickname nickname Although this would be useful in a case of *** ChanServ sets mode: +oo nickname1 nickname2 for multiple modes on one user, it would be preferable to only display the nickname once. Mark. From kevc at gmx.co.uk Fri Feb 8 21:35:52 2002 From: kevc at gmx.co.uk (Kevin) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Memoserv Suggestion In-Reply-To: References: Message-ID: <02020900355201.03499@localhost.localdomain> Hi All, After trying to send a Memo to a Colleague on our network, I wasnt sure if it was sent because memoserv never actually said anything... Couldnt there be a Confirmation Notice for example, "Memo sent to nickname" I didnt seem to receive anything and wasnt sure if it was sent... although it was thanks, Regards, -- Kevin Conlin BT UK Operator DarkServ IRC Chat Admin [Irc.DarkServ.Net] - http://www.DarkServ.Net From mark at mhetherington.demon.co.uk Fri Feb 8 16:43:31 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 alpha 20 New levels - missing help text In-Reply-To: Message-ID: With the introduction of the new access levels, some levels appear to have got lost in the help text. -ChanServ- 100 Access to AKICK command; automatic opping. -ChanServ- 50 Automatic opping. -ChanServ- 30 Automatic voicing. needs the addition of -ChanServ- 40 Automatic half-opping. for IRCds which support it. Also, since there are only two default - levels, could they not also be listed in help? Mark. From mark at mhetherington.demon.co.uk Fri Feb 8 16:53:34 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Memoserv Suggestion In-Reply-To: <02020900355201.03499@localhost.localdomain> Message-ID: What version of Services? This is fixed for me in 5.0a20. Mark. > -----Original Message----- > From: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net]On Behalf Of Kevin > Sent: 09 February 2002 05:36 > To: ircservices-coding@ircservices.za.net > Subject: [IRCServices Coding] Memoserv Suggestion > > > Hi All, > > After trying to send a Memo to a Colleague on our network, I > wasnt sure if it > was sent because memoserv never actually said anything... > > Couldnt there be a Confirmation Notice for example, "Memo sent to > nickname" > > I didnt seem to receive anything and wasnt sure if it was sent... > although it > was > > thanks, > Regards, > > -- > Kevin Conlin > BT UK Operator > DarkServ IRC Chat Admin > [Irc.DarkServ.Net] - http://www.DarkServ.Net > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From griever at t2n.org Fri Feb 8 16:53:11 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 alpha 20 Small Bug with new channel auto mode merge In-Reply-To: Message-ID: On Sat, 9 Feb 2002, Mark Hetherington wrote: > Since the introduction of automatic merging of modes regardless of the merge > modes setting in the configuration, Chanserv will often produce the > following: > > *** ChanServ sets mode: +oa nickname nickname > > Although this would be useful in a case of > > *** ChanServ sets mode: +oo nickname1 nickname2 > > for multiple modes on one user, it would be preferable to only display the > nickname once. This has nothing to do with services and is impossible anyway > > Mark. > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From rplume at cablemo.net Fri Feb 8 19:18:03 2002 From: rplume at cablemo.net (RP) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] suggestion References: Message-ID: <000901c1b118$635f0e70$8cfeda42@ryan> Good for debugging... Set a maximum size for the services logfile. Recently, I've been outputting a lot of information to the logfile and it's built up faster than I thought -- to the point where it took up every bit of disk space. If services' were to remove the first line and append the new line, that'd be helpful. Or if it just stopped completely. From achurch at achurch.org Sat Feb 9 13:54:04 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 alpha 20 -- you know you want it Message-ID: <3c64ab9d.37565@achurch.org> >> The big change this >> time is that channel access levels have been rescaled; they now range from >> -999 to 999 (1/10 of the previous range), and default levels have been >> spread out by a factor of 10, so it looks something like this: >> >> 100 AUTOPROTECT (SOP) >> 50 AUTOOP (AOP) >> 40 AUTOHALFOP (HOP) >> 30 AUTOVOICE (VOP) >> -10 AUTODEOP >> -20 NOJOIN > >Shouldn't this be changed in the language file too? >There's a lot of stuff in there like: "By default, limited to users with >level 10 access and above on the channel" Oops, I knew I was forgetting something... that's what I get for trying to push an alpha out during lunch break. Fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Sat Feb 9 14:33:29 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 alpha 20 Bug with handling of channel '#' Message-ID: <3c64b4b3.44752@achurch.org> >Starting Services 5 with the channel '#' in the database will result in the >deletion of all registered channels. > >It seems the code for checking for the '#' channel will set ci to NULL >thereby triggering the failure flag resulting in the rest of the channel >database not being read. > >As a workaround, drop the channel '#' before starting services 5.0a20. Already found and being fixed. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Sat Feb 9 14:34:52 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] suggestion Message-ID: <3c64b52e.45030@achurch.org> >Good for debugging... > >Set a maximum size for the services logfile. Recently, I've been outputting >a lot of information to the logfile and it's built up faster than I >thought -- to the point where it took up every bit of disk space. If >services' were to remove the first line and append the new line, that'd be >helpful. Or if it just stopped completely. Removing the first lines when the file got full would require massive disk activity and slow down Services to the point of being unusable; not logging at all has major security implications. No to both. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Sat Feb 9 14:35:58 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 alpha 20 -- you know you want it Message-ID: <3c64b558.45055@achurch.org> >btw, YAFS (yet another feature suggestion): wouldn't it be cool if >statserv generated html pages about the status of the network during >time, maybe with graphics? pretty much like netsplit.de does, but with >smaller time intervals (e.g. every 15 mins or so), to get a real idea of >how the network is doing. Nice idea, I'll think about it. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Sat Feb 9 14:37:16 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 alpha 20 New levels - missing help text Message-ID: <3c64b5b0.45125@achurch.org> >With the introduction of the new access levels, some levels appear to have >got lost in the help text. > >-ChanServ- 100 Access to AKICK command; automatic opping. >-ChanServ- 50 Automatic opping. >-ChanServ- 30 Automatic voicing. > >needs the addition of > >-ChanServ- 40 Automatic half-opping. > >for IRCds which support it. Known and being worked on. >Also, since there are only two default - levels, could they not also be >listed in help? I'm actually thinking of removing those because they require a lot of special-casing (= complex code). --Andrew Church achurch@achurch.org http://achurch.org/ From thebeast at xs4all.nl Sat Feb 9 04:13:04 2002 From: thebeast at xs4all.nl (thebeast) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 alpha 20 -- you know you want it References: <3c64b558.45055@achurch.org> Message-ID: <3C651250.45050EEB@xs4all.nl> Andrew Church schreef: > > >btw, YAFS (yet another feature suggestion): wouldn't it be cool if > >statserv generated html pages about the status of the network during > >time, maybe with graphics? pretty much like netsplit.de does, but with > >smaller time intervals (e.g. every 15 mins or so), to get a real idea of > >how the network is doing. you mean like this page's http://rc5proxy.dhs.org/cgi-bin/irccounter.cgi http://rc5proxy.dhs.org/cgi-bin/irccounter.cgi?log=irc -- Grtzz Hans v Steenbergen Mail me at thebeast@xs4all.nl Tech Admin on rc5proxy.mp3crew.nu www.mp3crew.nu for info about this irc server. mail to admins@mp3crew.nu for info The only one who got his work done by friday was R.Crusoe 1:05pm up 31 days, 18:41, 1 user, load average: 2.37, 2.50, 1.92 From jollino at sogno.net Sat Feb 9 04:42:59 2002 From: jollino at sogno.net (Jollino) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 alpha 20 -- you know you want it In-Reply-To: <3C651250.45050EEB@xs4all.nl> Message-ID: <8CC04B5C-1D5A-11D6-AA9A-003065BD4458@sogno.net> Sabato, febbraio 9, 2002, alle 01:13 , thebeast ha scritto: >>> btw, YAFS (yet another feature suggestion): wouldn't it be cool if >>> statserv generated html pages about the status of the network during >>> time, maybe with graphics? pretty much like netsplit.de does, but with >>> smaller time intervals (e.g. every 15 mins or so), to get a real idea >>> of >>> how the network is doing. > > you mean like this page's > > http://rc5proxy.dhs.org/cgi-bin/irccounter.cgi > http://rc5proxy.dhs.org/cgi-bin/irccounter.cgi?log=irc Yes, something like that! -- Jollino [jollino at sogno dot net - jollino at chieti dot ch] IRC Operator on irc.discussioni.org Webmaster of http://www.sogno.net and related services Active content provider of http://www.chieti.ch Italian Dreamer no. 2305 (www.italiandreamers.net) Longe vivu la verda stelo de Esperanto! Eg atart agap?en... From mark at mhetherington.demon.co.uk Sat Feb 9 18:37:18 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5 - Suggestions/Queries In-Reply-To: <8CC04B5C-1D5A-11D6-AA9A-003065BD4458@sogno.net> Message-ID: 1) Suggestion: When a qline is set on the ircd, the error reported to the user is formatted as follows: Guest781361765 Erroneous Nickname: Reserved for Services However, sqlines set in services merely report: testsqline Erroneous Nickname: Reserved nickname A better response would be: testsqline Erroneous Nickname: (reason set in services) 2) Suggestion/Query: The sline modules provides a very useful central repository for qlines/zlines etc that remove the need for individual ircd.conf changes when a new sline is required. However, in the qline example above, services does not seem to have added the qline to the list used by the ircd. In the event of any downtime, this would mean that the qlines would no longer remain in operation even though some services set options (e.g. akills) would likely survive the downtime. I appreciate that this maybe be largely an IRCd issue but if services were to provide a framework for interaction with the IRCd, I am sure it should be possible to add IRCd level support so identifying the appropriate area would be a good first step. 3) Suggestion/Query: With the s(z)line support, I am not sure of the exact manner in which Services determines what level of support is available in the ircd (i.e. whether it is the appropriate protocol module or the sline module which makes the decision and how). I notice for Unreal, services reports in the log a lack of IP information as being of relevance to the szline support. If this is determined by say the protocol module, then I guess the operation is fixed by that module, but if it is down to some sort of real time startup test, I would assume that the Unreal "connection message" which is lacking in IP is the cause. Since this is a relatively trivial issue to address on the IRCd, it would be useful to have some way to have services recognise the support. This largely depends on the method(s) services uses to determine the level of support. If the protocol module does fix this operation, the suggestion would be to have some type of configuration directive to override this operation for a server modified to be more "services friendly". If it does check the connection message format, I can safely update that portion of code and services have access to IP addresses in the manner it desires. A number of "tools" cite Unreal's connection message as a bug so it may ultimately be addressed in the new version as it progresses through beta. However, if neither of these options is in force, then I guess I am loooking for some long term solution to this based on how the current operation determines support. Mark. From griever at t2n.org Sat Feb 9 19:57:03 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5 - Suggestions/Queries In-Reply-To: Message-ID: On Sun, 10 Feb 2002, Mark Hetherington wrote: > 1) Suggestion: When a qline is set on the ircd, the error reported to the > user is formatted as follows: > > Guest781361765 Erroneous Nickname: Reserved for Services > > However, sqlines set in services merely report: > > testsqline Erroneous Nickname: Reserved nickname > > A better response would be: > > testsqline Erroneous Nickname: (reason set in services) Change SQlineReason to "%s" > > 2) Suggestion/Query: The sline modules provides a very useful central > repository for qlines/zlines etc that remove the need for individual > ircd.conf changes when a new sline is required. However, in the qline > example above, services does not seem to have added the qline to the list > used by the ircd. In the event of any downtime, this would mean that the > qlines would no longer remain in operation even though some services set > options (e.g. akills) would likely survive the downtime. I appreciate that > this maybe be largely an IRCd issue but if services were to provide a > framework for interaction with the IRCd, I am sure it should be possible to > add IRCd level support so identifying the appropriate area would be a good > first step. bahamut and unreal allow this, what are you using? > > 3) Suggestion/Query: With the s(z)line support, I am not sure of the exact > manner in which Services determines what level of support is available in > the ircd (i.e. whether it is the appropriate protocol module or the sline > module which makes the decision and how). > > I notice for Unreal, services reports in the log a lack of IP information as > being of relevance to the szline support. If this is determined by say the > protocol module, then I guess the operation is fixed by that module, but if > it is down to some sort of real time startup test, I would assume that the > Unreal "connection message" which is lacking in IP is the cause. Since this > is a relatively trivial issue to address on the IRCd, it would be useful to > have some way to have services recognise the support. IP information is only in bahamut > > This largely depends on the method(s) services uses to determine the level > of support. If the protocol module does fix this operation, the suggestion > would be to have some type of configuration directive to override this > operation for a server modified to be more "services friendly". > > If it does check the connection message format, I can safely update that > portion of code and services have access to IP addresses in the manner it > desires. A number of "tools" cite Unreal's connection message as a bug so it > may ultimately be addressed in the new version as it progresses through > beta. > > However, if neither of these options is in force, then I guess I am loooking > for some long term solution to this based on how the current operation > determines support. > > > Mark. > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From eengin at talesoft.de Sun Feb 10 04:24:16 2002 From: eengin at talesoft.de (Ekim Engin) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5 - Suggestions/Queries In-Reply-To: Message-ID: <00b801c1b22d$e1d30520$092a14ac@hadiko.de> > -----Original Message----- > From: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net] On > Behalf Of Mark Hetherington > Sent: Sunday, February 10, 2002 3:37 AM > To: ircservices-coding@ircservices.za.net > Subject: [IRCServices Coding] Services 5 - Suggestions/Queries > > > 1) Suggestion: When a qline is set on the ircd, the error > reported to the user is formatted as follows: > > Guest781361765 Erroneous Nickname: Reserved for Services > > However, sqlines set in services merely report: > > testsqline Erroneous Nickname: Reserved nickname > > A better response would be: > > testsqline Erroneous Nickname: (reason set in services) > This is a ircd matter and not services. > [...] > > > Mark. > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From eengin at talesoft.de Sun Feb 10 04:28:12 2002 From: eengin at talesoft.de (Ekim Engin) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5 - Suggestions/Queries In-Reply-To: <00b801c1b22d$e1d30520$092a14ac@hadiko.de> Message-ID: <00bf01c1b22e$6ced5f20$092a14ac@hadiko.de> Ops Sorry, should not post when drunk ;-) My failure Greets Ekim > -----Original Message----- > From: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net] On > Behalf Of Ekim Engin > Sent: Sunday, February 10, 2002 1:24 PM > To: ircservices-coding@ircservices.za.net > Subject: RE: [IRCServices Coding] Services 5 - Suggestions/Queries From mark at mhetherington.demon.co.uk Sun Feb 10 05:50:29 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5 - Suggestions/Queries In-Reply-To: Message-ID: > Finny Merrill wrote [Re SQLine reasons] > Change SQlineReason to "%s" /me kicks himself. Thanks. That will teach me to configure stuff at nearly 3am :) So, a change to the suggestion. The SZLine reason has both options in the example configuration, one is commented out by default. Perhaps both options could be presented in a similar manner for SQLINE and SGLINE. [Adding SQLines to the current IRCd list] > bahamut and unreal allow this, what are you using? Unreal. But the QLines reported by the IRCd remain those in it's own configuration files and do not include services set ones. [IP information for SZLINE] > IP information is only in bahamut What are you basing this on? If it is the format of the "connecting from" message as discussed in my post, then this is relatively trivial to change in Unreal. The question posed was more how does services determine the support in the IRCd and what information does it require that is not present. Mark. From mark at mhetherington.demon.co.uk Sun Feb 10 06:32:33 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5 - AKILL expiry In-Reply-To: Message-ID: Services version 5.0a20. Use of the killclones command sets a temporary AKILL on that user. However, these akills do not seem to be removed automatically. For example, from our AKILL list: Reason: Temporary KILLCLONES akill. Set on: Feb 09 18:53:47 2002 Expires on: Feb 09 19:23:47 2002 This AKILL should have expired and be removed from the list of AKILLs on the network. Since the clone has not returned, I cannot say whether this AKILL still triggers against the offending user. (Note: this akill expiry problems actually seems to be present on all akills since I have just found one non automatic AKILL which should have expired this morning and has not). Mark. From achurch at achurch.org Sun Feb 10 23:26:55 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5 - Suggestions/Queries Message-ID: <3c668612.26033@achurch.org> 1) SQlineReason "%s" (and your point about the examples being incosistent is a valid one, I'll look into it). 2) This is an ircd issue (Unreal, at least, propogates all S-lines so this does not occur). If you want S-lines propogated immediately rather than waiting for Services to detect a violation, use ImmediatelySendSline. 3) If the protocol module provides an IP address to users.c:do_nick(), then IP addresses are deemed available, else they're deemed unavailable. Unreal doesn't send IP addresses, so you get the warning. --Andrew Church achurch@achurch.org http://achurch.org/ >1) Suggestion: When a qline is set on the ircd, the error reported to the >user is formatted as follows: > >Guest781361765 Erroneous Nickname: Reserved for Services > >However, sqlines set in services merely report: > >testsqline Erroneous Nickname: Reserved nickname > >A better response would be: > >testsqline Erroneous Nickname: (reason set in services) > >2) Suggestion/Query: The sline modules provides a very useful central >repository for qlines/zlines etc that remove the need for individual >ircd.conf changes when a new sline is required. However, in the qline >example above, services does not seem to have added the qline to the list >used by the ircd. In the event of any downtime, this would mean that the >qlines would no longer remain in operation even though some services set >options (e.g. akills) would likely survive the downtime. I appreciate that >this maybe be largely an IRCd issue but if services were to provide a >framework for interaction with the IRCd, I am sure it should be possible to >add IRCd level support so identifying the appropriate area would be a good >first step. > >3) Suggestion/Query: With the s(z)line support, I am not sure of the exact >manner in which Services determines what level of support is available in >the ircd (i.e. whether it is the appropriate protocol module or the sline >module which makes the decision and how). > >I notice for Unreal, services reports in the log a lack of IP information as >being of relevance to the szline support. If this is determined by say the >protocol module, then I guess the operation is fixed by that module, but if >it is down to some sort of real time startup test, I would assume that the >Unreal "connection message" which is lacking in IP is the cause. Since this >is a relatively trivial issue to address on the IRCd, it would be useful to >have some way to have services recognise the support. > >This largely depends on the method(s) services uses to determine the level >of support. If the protocol module does fix this operation, the suggestion >would be to have some type of configuration directive to override this >operation for a server modified to be more "services friendly". > >If it does check the connection message format, I can safely update that >portion of code and services have access to IP addresses in the manner it >desires. A number of "tools" cite Unreal's connection message as a bug so it >may ultimately be addressed in the new version as it progresses through >beta. > >However, if neither of these options is in force, then I guess I am loooking >for some long term solution to this based on how the current operation >determines support. > > >Mark. > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Sun Feb 10 23:39:52 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5 - AKILL expiry Message-ID: <3c668666.26076@achurch.org> The autokill will be properly cleared if a user matching it connects. Besides, I'm rewriting the expire stuff anyway. --Andrew Church achurch@achurch.org http://achurch.org/ >Services version 5.0a20. > >Use of the killclones command sets a temporary AKILL on that user. However, >these akills do not seem to be removed automatically. For example, from our >AKILL list: > >Reason: Temporary KILLCLONES akill. >Set on: Feb 09 18:53:47 2002 >Expires on: Feb 09 19:23:47 2002 > >This AKILL should have expired and be removed from the list of AKILLs on the >network. > >Since the clone has not returned, I cannot say whether this AKILL still >triggers against the offending user. > >(Note: this akill expiry problems actually seems to be present on all akills >since I have just found one non automatic AKILL which should have expired >this morning and has not). > >Mark. > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From mark at mhetherington.demon.co.uk Sun Feb 10 08:51:04 2002 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Making Services 5 friendly external pseudo clients In-Reply-To: <3c668666.26076@achurch.org> Message-ID: Currently on our network we have a couple of psuedo clients which are not part of IRC Services but have similar "powers" as +S psudeo clients on ulined servers. This includes a StatServ client that we had been running for some time prior to the first StatServ appearing in IRC Services and an open proxy monitor. Although they generally live happily together, since Services does not recognise these external psuedo clients, occasionally they tend to "fight". Using our StatServ as an example, this basically sits in a channel announcing various information about the network for the use of IRCops. Ideally we would like this channel locked to be an oper only channel but currently have to rely on an eggdrop bot to enforce this rather than ChanServ. The problems are twofold. Firstly, since Services has no way of recognising an external psuedo client, when StatServ ops itself, Chanserv will immediately deop it. Secondly, if the channel mode is set to mode +O, StatServ can happily join the channel (as a +S user), but services will enforce the mode and kick StatServ as a non-oper. This results in a vicious flood of join/kicks as they both fight for their rights :) Hopefully, the built-in StatServ will eventually provide most if not all of the functionality of our existing StatServ and anything it doesn't provide we can develop into a custom module of services. But, until that time, we need to maintain StatServ as an external pseudo client. The simplest way seems to be some recognition within services for other ulined servers possibly by detecting the +S user mode in a similar way that our StatServ will recognise each Services pseudo client as such. Is there anything in current versions of services that would allow the two servers to live together or anything we could set in our external pseudo clients which would cause services to ignore their actions? Mark. From beng at nc.rr.com Sun Feb 10 10:38:57 2002 From: beng at nc.rr.com (Ben Goldstein) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] SMTP debug Message-ID: <008401c1b262$50124bc0$0300a8c0@asi200> This might be a configuration problem on my end, but if services is debugging, after the SMTP error, logfiles grow huge in seconds. And SMTP isn't working ;) [Feb 10 13:25:46.331579 2002] debug: Received: :beng PRIVMSG nickserv :register anypassworcd beng@nc.rr.com [Feb 10 13:25:46.332424 2002] mail/main: debug: sendmail: from=beng@nc.rr.com to=beng@nc.rr.com subject=[Authorization code for beng] [Feb 10 13:25:46.332739 2002] mail/main: debug: sendmail: body=[The authorization code for your nickname (beng) is: 184813122 Please submit this code to NickServ with the command: /msg NickServ AUTH 184813122 This message was sent by NickServ in response to registration by bstu@192.168.0.3.] [Feb 10 13:25:46.340067 2002] debug: Sent: :NickServ NOTICE beng :Nickname beng has been registered to you. [Feb 10 13:25:46.340481 2002] debug: Sent: :NickServ NOTICE beng :An authorization code for your nickname has been sent to beng@nc.rr.com. [Feb 10 13:25:46.340850 2002] debug: Sent: :NickServ NOTICE beng :When you receive this message, type /msg NickServ AUTH code (replace code with the authorization code in the message) to complete your nickname registration. [Feb 10 13:25:46.341231 2002] nickserv/main: beng registered by bstu@192.168.0.3 (beng@nc.rr.com) [Feb 10 13:25:46.341640 2002] debug: Sent: :NickServ NOTICE beng :Your password is anypassworcd -- remember this for later use. [Feb 10 13:25:46.341930 2002] debug: Top of main loop [Feb 10 13:25:46.351636 2002] debug: sockets: connect on fd 1 returned [Feb 10 13:25:46.351989 2002] debug: sockets: connect(1 -> 24.93.67.206:25): Socket is already connected [Feb 10 13:25:46.352282 2002] mail/smtp: Connection to server failed for socket 0x8162400 [Feb 10 13:25:46.352837 2002] debug: Top of main loop [Feb 10 13:25:46.353119 2002] sockets: select(): Bad file descriptor [Feb 10 13:25:46.353374 2002] debug: Top of main loop [Feb 10 13:25:46.353617 2002] sockets: select(): Bad file descriptor [Feb 10 13:25:46.354961 2002] debug: Top of main loop [Feb 10 13:25:46.355203 2002] sockets: select(): Bad file descriptor [Feb 10 13:25:46.355455 2002] debug: Top of main loop [Feb 10 13:25:46.355698 2002] sockets: select(): Bad file descriptor [Feb 10 13:25:46.355949 2002] debug: Top of main loop [Feb 10 13:25:46.356190 2002] sockets: select(): Bad file descriptor [Feb 10 13:25:46.356442 2002] debug: Top of main loop [Feb 10 13:25:46.356681 2002] sockets: select(): Bad file descriptor -- Ben Goldstein (beng@nc.rr.com) ircservices-5.0a20 FreeBSD raider 4.4-20010827-RC2 FreeBSD 4.4-20010827-RC2 #4: Fri Nov 16 14:57:04 EST 2001 root@raider:/usr/obj/usr/src/sys/BG1 i386 From martinpels at hotmail.com Sun Feb 10 11:03:23 2002 From: martinpels at hotmail.com (Martin Pels) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] ChanServ suggestion Message-ID: I think it would be a good idea to make the ChanServ OP, DEOP, etc. commands available to users in the Services Oper and Admin list for every channel. Users in these lists can allready use the OperServ MODE and KICK commands, why not give them the ability to do the same with ChanServ? From achurch at achurch.org Mon Feb 11 04:03:18 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] SMTP debug Message-ID: <3c66c4b1.42752@achurch.org> Log problem fixed, thanks. I can't reproduce the connection error; it might be a FreeBSD specific thing--I'll check when I have a chance. (Is anyone else successfully using mail/smtp with FreeBSD?) --Andrew Church achurch@achurch.org http://achurch.org/ >This might be a configuration problem on my end, but if services is >debugging, after the SMTP error, logfiles grow huge in seconds. And SMTP >isn't working ;) > >[Feb 10 13:25:46.331579 2002] debug: Received: :beng PRIVMSG nickserv >:register anypassworcd beng@nc.rr.com >[Feb 10 13:25:46.332424 2002] mail/main: debug: sendmail: >from=beng@nc.rr.com to=beng@nc.rr.com subject=[Authorization code for beng] >[Feb 10 13:25:46.332739 2002] mail/main: debug: sendmail: body=[The >authorization code for your nickname (beng) is: 184813122 >Please submit this code to NickServ with the command: > /msg NickServ AUTH 184813122 > >This message was sent by NickServ in response to registration by >bstu@192.168.0.3.] >[Feb 10 13:25:46.340067 2002] debug: Sent: :NickServ NOTICE beng :Nickname >beng has been registered to you. >[Feb 10 13:25:46.340481 2002] debug: Sent: :NickServ NOTICE beng :An >authorization code for your nickname has been sent to beng@nc.rr.com. >[Feb 10 13:25:46.340850 2002] debug: Sent: :NickServ NOTICE beng :When you >receive this message, type /msg NickServ AUTH code (replace code with >the authorization code in the message) to complete your nickname >registration. >[Feb 10 13:25:46.341231 2002] nickserv/main: beng registered by >bstu@192.168.0.3 (beng@nc.rr.com) >[Feb 10 13:25:46.341640 2002] debug: Sent: :NickServ NOTICE beng :Your >password is anypassworcd -- remember this for later use. >[Feb 10 13:25:46.341930 2002] debug: Top of main loop >[Feb 10 13:25:46.351636 2002] debug: sockets: connect on fd 1 returned >[Feb 10 13:25:46.351989 2002] debug: sockets: connect(1 -> 24.93.67.206:25): >Socket is already connected >[Feb 10 13:25:46.352282 2002] mail/smtp: Connection to server failed for >socket 0x8162400 >[Feb 10 13:25:46.352837 2002] debug: Top of main loop >[Feb 10 13:25:46.353119 2002] sockets: select(): Bad file descriptor >[Feb 10 13:25:46.353374 2002] debug: Top of main loop >[Feb 10 13:25:46.353617 2002] sockets: select(): Bad file descriptor >[Feb 10 13:25:46.354961 2002] debug: Top of main loop >[Feb 10 13:25:46.355203 2002] sockets: select(): Bad file descriptor >[Feb 10 13:25:46.355455 2002] debug: Top of main loop >[Feb 10 13:25:46.355698 2002] sockets: select(): Bad file descriptor >[Feb 10 13:25:46.355949 2002] debug: Top of main loop >[Feb 10 13:25:46.356190 2002] sockets: select(): Bad file descriptor >[Feb 10 13:25:46.356442 2002] debug: Top of main loop >[Feb 10 13:25:46.356681 2002] sockets: select(): Bad file descriptor > > >-- Ben Goldstein (beng@nc.rr.com) >ircservices-5.0a20 >FreeBSD raider 4.4-20010827-RC2 FreeBSD 4.4-20010827-RC2 #4: Fri Nov 16 >14:57:04 EST 2001 root@raider:/usr/obj/usr/src/sys/BG1 i386 > > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Mon Feb 11 04:06:42 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] ChanServ suggestion Message-ID: <3c66c4db.43001@achurch.org> >I think it would be a good idea to make the ChanServ OP, DEOP, etc. commands >available to users in the Services Oper and Admin list for every channel. >Users in these lists can allready use the OperServ MODE and KICK commands, >why not give them the ability to do the same with ChanServ? Why _give_ them the ability when they have MODE/KICK already? It's added complexity for no purpose. --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Sun Feb 10 12:12:58 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5 - Suggestions/Queries In-Reply-To: Message-ID: On Sun, 10 Feb 2002, Mark Hetherington wrote: > > Finny Merrill wrote > [Re SQLine reasons] > > Change SQlineReason to "%s" > > /me kicks himself. > Thanks. That will teach me to configure stuff at nearly 3am :) > > So, a change to the suggestion. The SZLine reason has both options in the > example configuration, one is commented out by default. Perhaps both options > could be presented in a similar manner for SQLINE and SGLINE. > > [Adding SQLines to the current IRCd list] > > bahamut and unreal allow this, what are you using? > > Unreal. But the QLines reported by the IRCd remain those in it's own > configuration files and do not include services set ones. /stats q with a lowercase q > > [IP information for SZLINE] > > IP information is only in bahamut > > What are you basing this on? If it is the format of the "connecting from" > message as discussed in my post, then this is relatively trivial to change > in Unreal. The question posed was more how does services determine the > support in the IRCd and what information does it require that is not > present. Services determines that IP information is available if a) You are using the bahamut protocol module b) The bahamut version sends a certain number of parameters for the NICK command > > Mark. > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From uhc0 at rz.uni-karlsruhe.de Sun Feb 10 14:05:18 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:14 2004 Subject: AW: [IRCServices Coding] Services 5 - Suggestions/Queries In-Reply-To: Message-ID: <000101c1b27f$06decce0$0264a8c0@nygmatech.local> > Services determines that IP information is available if a) You > are using the bahamut protocol module b) The bahamut version sends > a certain number of parameters for the NICK command There are other ircds like tr-ircd4 as well, which do support IP information via NICK line. SCNR, yusuf. ---------------------------------------------------------------------- | Yusuf Iskenderoglu | You get to meet all sorts, | | eMail - uhc0@stud.uni-karlsruhe.de| in this line of work... | | eMail - s_iskend@ira.uka.de | | | ICQ UIN : 20587464 \ TimeMr14C | | ---------------------------------------------------------------------- From p_levesque at sympatico.ca Sun Feb 10 09:24:21 2002 From: p_levesque at sympatico.ca (Philippe Levesque) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] ChanServ suggestion References: Message-ID: <3C66ACC5.61B6504E@sympatico.ca> If im rigth, you simply send a raw command to ChanServ, and it will make whatever u want.., I seen MemoServ kicking some user some day ago :P, any oper that got access to the raw command can make services act like they want Martin Pels wrote: > I think it would be a good idea to make the ChanServ OP, DEOP, etc. commands > available to users in the Services Oper and Admin list for every channel. > Users in these lists can allready use the OperServ MODE and KICK commands, > why not give them the ability to do the same with ChanServ? > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From mark at ctcp.net Wed Feb 13 11:25:56 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0a20 httpd bugs Message-ID: <1417.193.237.130.98.1013628356.squirrel@secure.uksolutions.co.uk> 1) When viewing the registered nickname and channels lists, httpd has no concept of suspension and will display suspended nicknames and channels as if they were usable. Although being able to see the information is useful, there needs to be an additional note stating that the nickname or channel is suspended and the new suspension reason field should be displayed. 2) XML Download fails a few nicknames into my database. It appears to be parsing a hostmask as a memo but seems to fail in different places around the same entry each time. Refreshing the page or retrying from the menu will usually alter the error slightly. Andrew you have a pretty recent copy of my databases, but if you want the latest ones to try this on please let me know. 3) Suggestion - While StatServ pages are unimplemented within the httpd module, could a temporary page be returned as a placeholder with a title and "previous menu" hyperlink. Although it may seem to have little benefit, since the only documentation of it not working is the FIXME comment in the code, it would provide a more useful method to point out the work in progress status. Long term, it could well be worth keeping the simple code for this as a template for custom page additions to the module, part of the technical documentation, or even a permanent "under construction" page function for the module. -- Mark. From griever at t2n.org Wed Feb 13 11:55:00 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Idea Message-ID: Why not allow multiple nicks and/or channels in the chanserv OP and friends commands? From mark at ctcp.net Wed Feb 13 13:17:43 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Auth Module - SETAUTH command suggestion Message-ID: <1688.193.237.130.98.1013635063.squirrel@secure.uksolutions.co.uk> One thing that seems to be missing from the AUTH modules, is the ability to put a nick into auth mode. The reasons that I feel this command is required are listed below: 1) We have a number of nicknames that were registered before the introduction of the AUTH modules, so although we have always insisted on email addresses, not all are verified. Some are obviously made up purely for the purpose of registration. At present, the only guaranteed solution is to drop the nick name and force it to be registered under the new AUTH system. However, since this would be more than a minor inconvenience for some users as it dropped channels, linked nicks and access rights in channels, it is something that I would prefer a more user friendly solution to. For anyone changing over from an older version of services or a competitor without nickname validation, a SETAUTH feature would be useful in validating existing registrations. 2) Services Admins are able to change the email address of a user without triggering the AUTH module. Unless the Services Admin manually verifies the address, or knows the address to be valid, this creates a situation where an email address can be entered into a new database which is not validated. A SETAUTH command would address this for an email address which cannot be verfied manually. This could be acheived by always triggering AUTH on set email, but since there are cases where auth may not be required, SETAUTH provides this as an option. 3) When importing users from another services database, for example during a network merge, again there is the potential for importing unvalidated addresses. SETAUTH would allow a Services Admin to flag nicknames as unauthorised so that validation could occur. Again, this could be automatically flagged during import, but as with 2, I think a command is better to make the AUTH optional. One issue with the command, is it would likely require an unlimited AUTH time (until normal nick expiration at least) since in scenario 3 above, it is possible that not all users would log on before the main AUTH expiry time kicked in. It seems that the SET EMAIL authorisation already works in this manner so this may be trivial to address. -- Mark. From mark at ctcp.net Wed Feb 13 13:27:36 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] TODO update Message-ID: <21028.193.237.130.98.1013635656.squirrel@secure.uksolutions.co.uk> Minor thing, so low priority I guess, but any chance of an update to the TODO file in the next alpha? The current one has some things included that have been implemented (e.g. CS KICK) and does not have some things I have seen discussed on the list as potentials. Andrew, I guess you have an "internal" list of things, so maybe that would suffice for the alpha period to save time creating the specific file for it. Also, any additional information on the plans for StatServ would be useful. I would like to start putting our external StatServ features into a module, but don't want to repeat functionality so just intend to implement those things that probably won't make into the ircservices one. -- Mark. From mark at ctcp.net Wed Feb 13 15:03:07 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] More bugs and suggestions for Version 5.0 Message-ID: <21029.193.237.130.98.1013641387.squirrel@secure.uksolutions.co.uk> 1) Suggestion: httpd module - nickname and channel lists - add an indicator for noexpire, forbidden, suspended etc to the lists in a similar way to the in IRC list command. 2) Suggestion: /cs list and /ns list - add option to list suspended nicknames and channels to bring in line with the forbidden and noexpire options currently available. 3) Bug: Services allows some commands to operate on #nickname. It is possible for example to forbid #nickname. /ns forbid #nickname -NickServ- Nick #nickname is now forbidden. /ns dropnick #nickname -NickServ- Internal error--unable to process request. /ns info will operate on an invlaid nick e.g. Nick #nick isn't registered. Where commands are used including a # character, or indeed any unsupported character, the response might be better as: -NickServ- Nick invalidnickname may not be registered or used. or -NickServ- Nick invalidnickname contains invalid characters. then supply list of valid characters Services should explicitly not support # in all nickserv commands to avoid confusion. Finally, maybe services could also do a similar thing to the '#' channel on startup to clear out these nicks that are now stuck in my database :) 4) Suggestion: /cs forbid and /ns forbid - introduce reason field for forbid in a similar manner to the suspend command. 5) Suggestion: Services admin /cs drop and /ns dropnick - Add a reason field which is broadcast through globops and logged along with the drop command. Useful for working out later why a channel or nickname was dropped. 6) Text bug: '/cs drop channel' produces: -ChanServ- Syntax: FORBID channel -ChanServ- Type /msg ChanServ HELP FORBID for more information. Suggest that it be changed to "FORBID #channel", and/or additional information explaining that a # prefix is required for channel names. 7) Text bug related to 6 - /cs drop channel produces: -ChanServ- Channel channel isn't registered. which although correct, to be consistent with the requirement of the prefix # ought to produce a failure message and the suggested additional information about the prefix listed in 6. 8) Bug - either in text or operation - /cs help suspend produces the following information: -ChanServ- Unlike a forbidden channel, a suspended one does not -ChanServ- lose its information and will expire! However, such channels do not seem to expire. As an example, a channel that was registered and suspended in November 2001 still remains suspended today. -ChanServ- Registered: Nov 22 10:11:24 2001 GMT -ChanServ- Last used: Nov 22 23:53:18 2001 GMT -ChanServ- Channel #modshack is suspended and may not be used or identified for. If the help text means that they would expire if unsuspended, then the text ought to be changed to reflect this. The problem appears to be in the version 4.5.x series as well as version 5 since the channels I have noticed it on were originally suspended under a version of 4.5.x and remained unexpired after migrating to 5.0. 9) Suggested config option to limit guest nick length. The new guest nicks can end up using a full 9 digit precision depending on IRCd limits which on smaller networks makes them seem a little excessive. It would be nice if there was a configuration ption to limit this. Obviously such option would have to be accompanied by information on the minimum length requirement. 10) Suggestion wrt IDENTIFY command: Although generally I have not found any reasons to consider or suggest aliases for existing services commands since they can generally be scripted client side and merely add confusion to the command list, I have found one "alias" that I do implement within our services which might prove useful to everyone. That is the addition of the command 'ID' to perform the job of 'IDENTIFY' with nickserv and chanserv. The main benefit I have found is since this is a command which the majority of users will use every time they log on, is that people coming from other networks and services packages have the option of both so can quite easily use this primary services command in the form they already know to identify without having to rescript. It has helped groups of people move from other networks very easily and I find once their basics are shown to just work, they do not mind so much if commands for say access list management are different. The xOP module has also been very helpful for such groups. There is also an advantage of being simple to provide appropriate help text for since it will not affect current translations. The other maybe less obvious benefit is less typing for people like myself that avoid scripts and automatic identification. :) Well I think that's it ... for today at least :) -- Mark. From beng at nc.rr.com Wed Feb 13 15:49:47 2002 From: beng at nc.rr.com (Ben Goldstein) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Re: [IRCServices] Services 4.5.38 released References: <3c62653c.16004@achurch.org> Message-ID: <014401c1b4e9$4dec8390$0300a8c0@asi200> What actually causes this? I'm not familiar with this problem, could someone explain? -- Ben Goldstein (beng@nc.rr.com) > Also, it has been reported and confirmed that failure to install Q:lines on > all of your servers when nick changing (NSForceNickChange) is in use can > allow users to escape Services' notice and use others' nicks without fear > of retaliation via nick kills or the GHOST command. A workaround is being > worked on for version 5.0; in the meantime, make sure you have Q:lines > installed on all of your servers for "Guest*" (or whatever you use for > guest nicks). From p_levesque at sympatico.ca Wed Feb 13 13:52:01 2002 From: p_levesque at sympatico.ca (Philippe Levesque) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] More bugs and suggestions for Version 5.0 References: <21029.193.237.130.98.1013641387.squirrel@secure.uksolutions.co.uk> Message-ID: <3C6AE001.825C220A@sympatico.ca> > > 6) Text bug: '/cs drop channel' produces: > -ChanServ- Syntax: FORBID channel > -ChanServ- Type /msg ChanServ HELP FORBID for more information. > Suggest that it be changed to "FORBID #channel", and/or additional > information explaining that a # prefix is required for channel names. > > 7) Text bug related to 6 - /cs drop channel produces: > -ChanServ- Channel channel isn't registered. > which although correct, to be consistent with the requirement of the prefix > # ought to produce a failure message and the suggested additional > information about the prefix listed in 6. some ircd allow channel name to not start with a #, so making services only restrict channel management to channel that start with a # can be a draw back. like on efnet, some channel here on my list start with a &. :P Phil From griever at t2n.org Wed Feb 13 19:56:58 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] More bugs and suggestions for Version 5.0 In-Reply-To: <3C6AE001.825C220A@sympatico.ca> Message-ID: On Wed, 13 Feb 2002, Philippe Levesque wrote: > > > > 6) Text bug: '/cs drop channel' produces: > > -ChanServ- Syntax: FORBID channel > > -ChanServ- Type /msg ChanServ HELP FORBID for more information. > > Suggest that it be changed to "FORBID #channel", and/or additional > > information explaining that a # prefix is required for channel names. > > > > 7) Text bug related to 6 - /cs drop channel produces: > > -ChanServ- Channel channel isn't registered. > > which although correct, to be consistent with the requirement of the prefix > > # ought to produce a failure message and the suggested additional > > information about the prefix listed in 6. > > some ircd allow channel name to not start with a #, so making services only > restrict channel management to channel that start with a # can be a draw back. > > like on efnet, some channel here on my list start with a &. :P & channels are server local, and therefore services cant use them, + channels are modeless and using services on them has no point. > > Phil > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From ShadowMaster at Shadow-Realm.org Wed Feb 13 20:01:39 2002 From: ShadowMaster at Shadow-Realm.org (Thomas J. =?iso-8859-1?q?Stens=E5s?=) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] More bugs and suggestions for Version 5.0 In-Reply-To: <3C6AE001.825C220A@sympatico.ca> References: <21029.193.237.130.98.1013641387.squirrel@secure.uksolutions.co.uk> <3C6AE001.825C220A@sympatico.ca> Message-ID: <200202140401.g1E41fZ76750@villageirc.net> On Wednesday 13 February 2002 22:52, you wrote: > some ircd allow channel name to not start with a #, so making services only > restrict channel management to channel that start with a # can be a draw > back. > > like on efnet, some channel here on my list start with a &. :P And like on EFnet, &Channels are local channels to your server only. Hence services cant manage them since the channel does not exsist outside the server you are on. If you join a second server on the same network, joining the same &Channel will in fact be a different channel, and you wont see anyone from the &Channel with an identical name on the first server. + and ! are other used channel prefixes, but wheter services should allow management of such global channels have to be considered out from their function. -- Yours Sincerely Thomas Juberg Stens?s -- What we do in life echoes in eternity. DMCA? Who cares? http://thefreeworld.net/ From andrewk at isdial.net Thu Feb 14 00:52:23 2002 From: andrewk at isdial.net (Andrew Kempe) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] More bugs and suggestions for Version 5.0 References: <21029.193.237.130.98.1013641387.squirrel@secure.uksolutions.co.uk> Message-ID: <003001c1b534$eb751410$9c011ac4@africa.didata.local> Comments are inline... > 8) Bug - either in text or operation - /cs help suspend produces the > following information: > -ChanServ- Unlike a forbidden channel, a suspended one does not > -ChanServ- lose its information and will expire! [snip] > version 4.5.x series as well as version 5 since the channels I have noticed > it on were originally suspended under a version of 4.5.x and remained > unexpired after migrating to 5.0. Do these nicknames expire on the 4.5.x branch? What is the output of: /ns info ALL This should either indicate the expiration date/time or "does not expire". Please can you confirm the setting in your config file regarding default expiration times for suspended nicks. (both in 4.5.x and 5.x) > 9) Suggested config option to limit guest nick length. The new guest nicks > can end up using a full 9 digit precision depending on IRCd limits which on > smaller networks makes them seem a little excessive. It would be nice if > there was a configuration ption to limit this. Obviously such option would > have to be accompanied by information on the minimum length requirement. The ID is not a simple number. A simple counter would be too easy to predict making it possible to collide nicks off the network. The current algorithm uses a counter and the time to generate the ID. This results in a very big number. So basically, a new algorithm needs to be used if you want to make the length of the guest ID shorter. > 10) Suggestion wrt IDENTIFY command: Although generally I have not found > any reasons to consider or suggest aliases for existing services commands > since they can generally be scripted client side and merely add confusion > to the command list, I have found one "alias" that I do implement within [snip] > The other maybe less obvious benefit is less typing for people like myself > that avoid scripts and automatic identification. :) If you have one alias, more will follow. This just clutters up Services as more people hack the aliases to their own liking. Over time it will become more and more difficult to have a common set of commands. Support also becomes more tricky and users more confused. I see your point, and yes, an ID alias would be nice, but my personal feeling is that aliases are not a good thing (tm) :). If you really want the ID alias - make a wrapper for the IDENTIFY function. Andrew From v13 at it.teithe.gr Wed Feb 13 15:09:49 2002 From: v13 at it.teithe.gr (,,,) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] lists Message-ID: <200202132309.BAA06419@ppp700.the.forthnet.gr> Is it possible to add regexp support to access lists, akill list etc? Many clones in our network use nicknames or userids tha can be described with regexps but not with *? masks.. We could realy use akills with regexps on userids during the past 3 months and i believe akick lists will be much more efficient. An 'easy' way whould be to flag regexp entries and use the system's regexp functions (they are very fast) when matching them. <> From andrewk at isdial.net Thu Feb 14 01:50:21 2002 From: andrewk at isdial.net (Andrew Kempe) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] lists References: <200202132309.BAA06419@ppp700.the.forthnet.gr> Message-ID: <009701c1b53d$049f8440$9c011ac4@africa.didata.local> The problem with regexps is that it is possible to get the parser into a loop. Obviously coders try to avoid this on their own systems, but users have a habbit of valliantly trying to break things on services. Poorly formed regexps can also take ages to run. Again, this would be something users would try to exploit. Andrew ----- Original Message ----- From: ",,," To: Sent: Thursday, February 14, 2002 1:09 AM Subject: [IRCServices Coding] lists Is it possible to add regexp support to access lists, akill list etc? Many clones in our network use nicknames or userids tha can be described with regexps but not with *? masks.. We could realy use akills with regexps on userids during the past 3 months and i believe akick lists will be much more efficient. An 'easy' way whould be to flag regexp entries and use the system's regexp functions (they are very fast) when matching them. <> ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From mark at ctcp.net Thu Feb 14 02:35:53 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] More bugs and suggestions for Version 5.0 Message-ID: <1127.195.92.144.170.1013682953.squirrel@secure.uksolutions.co.uk> [snip bug with suspended channels expiry) > Do these nicknames expire on the 4.5.x branch? > What is the output of: /ns info ALL > This should either indicate the expiration date/time or "does > not expire". I was discussing channels. I have not actually checked whether nicknames operate correctly. I pasted in my original email sufficient output from /cs info to show that the channel should have expired sometime between November (last used time) and today. Do not expire is not set on the channels that have problems. Since this database ran under 4.5.x for the whole of December and much of January, they do not expire under 4.5.x either as I said in my post. > Please can you confirm the setting in your config file > regarding default > expiration times for suspended nicks. (both in 4.5.x and 5.x) The nickname setting should have no effect on channel expiration so I will assume you mean channel. In version 5, suspended channel expiry time time is set to the default: CSSuspendExpire 12d 2d. For version 4.5.x, I will have to extract from backup so will check this evening, however, I imagine it was the default setting. [snip guest nick limiter] > making it possible to collide nicks off the network. The > current algorithm > uses a counter and the time to generate the ID. This results > in a very big > number. So basically, a new algorithm needs to be used if you > want to make > the length of the guest ID shorter. Since Services 5 already supports a smaller guest number (depending in the IRCds nickmax setting) in the current algorithm, I do not see how a configuration option requires a different algorithm for acheiving a similar aim. There are also several comments in the code suggesting why time is *not* used in guest nick generation. The guest nick number is generated from a rollover counter which is initialised with a value of rand(). [snip ID command] > I see your point, and yes, an ID alias would be nice, but my personal > feeling is that aliases are not a good thing (tm) :). If you > really want the > ID alias - make a wrapper for the IDENTIFY function. As I said in my post, I already have my own version of ID in each version of services we use. I agree that aliases in general are not a good thing as I said previously, I just thought this one was something that might be useful to have in the main distribution. After all, there is already SIDENTIFY which is, to all intents and purposes, an alias for IDENTIFY. -- Mark. From andrewk at isdial.net Thu Feb 14 02:56:30 2002 From: andrewk at isdial.net (Andrew Kempe) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] More bugs and suggestions for Version 5.0 References: <1127.195.92.144.170.1013682953.squirrel@secure.uksolutions.co.uk> Message-ID: <00ea01c1b546$45c23c20$9c011ac4@africa.didata.local> 1. Suspension problems: Please ignore the utter crap that I spoke in my reply. I misread the question entirely!! 2. Again, I spoke utter rubbish... I forgot the changes in v5. I will now confine myself to the corner.... Andrew From mark at ctcp.net Thu Feb 14 15:49:12 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 - NickServ register text suggestion Message-ID: <21024.193.237.130.98.1013730552.squirrel@secure.uksolutions.co.uk> When NSRequireEmail is set, /ns help register will display: -NickServ- You must include an E-mail address when registering your -NickServ- nickname.... (trimmed for brevity) I would like to suggest that this is changed to state that the email address must be valid or active or something which indicates to a user than when the AUTH module is in use, a fake email address will not allow a registration to complete. It might also be useful to include such a disclaimer in the confirmation command for users that did not view the help text. After 30+ attempts, one user still hasn't got the message that a made up address is not going to allow his registration to be processed hence my suggestion of "dumbing down" this process. Mark. From p_levesque at sympatico.ca Thu Feb 14 10:46:41 2002 From: p_levesque at sympatico.ca (Philippe Levesque) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] More bugs and suggestions for Version 5.0 References: Message-ID: <3C6C0611.8A60DC17@sympatico.ca> > > & channels are server local, and therefore services cant use them, + > channels are modeless and using services on them has no point. well, if in some case someone start a channel "+" or "!", and put a topic like : "come to my network xxxx.com" or "14 years old xxx pics....." , or anything like that, it's handy to be able to close those channel permanently. From achurch at achurch.org Fri Feb 15 22:20:20 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Making Services 5 friendly external pseudo clients Message-ID: <3c6d0b2e.62623@achurch.org> Is +S essentially treated as an oper, admin, or what, and on what ircd? --Andrew Church achurch@achurch.org http://achurch.org/ >Currently on our network we have a couple of psuedo clients which are not >part of IRC Services but have similar "powers" as +S psudeo clients on >ulined servers. This includes a StatServ client that we had been running for >some time prior to the first StatServ appearing in IRC Services and an open >proxy monitor. > >Although they generally live happily together, since Services does not >recognise these external psuedo clients, occasionally they tend to "fight". > >Using our StatServ as an example, this basically sits in a channel >announcing various information about the network for the use of IRCops. >Ideally we would like this channel locked to be an oper only channel but >currently have to rely on an eggdrop bot to enforce this rather than >ChanServ. > >The problems are twofold. Firstly, since Services has no way of recognising >an external psuedo client, when StatServ ops itself, Chanserv will >immediately deop it. Secondly, if the channel mode is set to mode +O, >StatServ can happily join the channel (as a +S user), but services will >enforce the mode and kick StatServ as a non-oper. This results in a vicious >flood of join/kicks as they both fight for their rights :) > >Hopefully, the built-in StatServ will eventually provide most if not all of >the functionality of our existing StatServ and anything it doesn't provide >we can develop into a custom module of services. But, until that time, we >need to maintain StatServ as an external pseudo client. > >The simplest way seems to be some recognition within services for other >ulined servers possibly by detecting the +S user mode in a similar way that >our StatServ will recognise each Services pseudo client as such. Is there >anything in current versions of services that would allow the two servers to >live together or anything we could set in our external pseudo clients which >would cause services to ignore their actions? > > >Mark. > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From mark at ctcp.net Fri Feb 15 05:46:16 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Making Services 5 friendly external pseudo clients Message-ID: <1188.195.92.144.170.1013780776.squirrel@secure.uksolutions.co.uk> > Andrew Church Wrote: > Is +S essentially treated as an oper, admin, or what, > and on what ircd? +S is a mode specifically reserved for Services which the IRCServices psuedoclients also set on themselves at startup. The IRCd in question is Unreal in which +S seems to be a level above and beyond oper/admin/etc. Mark. From achurch at achurch.org Fri Feb 15 23:08:20 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0a20 httpd bugs Message-ID: <3c6d18ca.66121@achurch.org> Good grief, I'm gone for just 3 days and look at all the stuff that piles up... I'm sure glad I haven't released this as beta yet. >1) When viewing the registered nickname and channels lists, httpd has no >concept of suspension and will display suspended nicknames and channels as >if they were usable. Fixed, thanks. >2) XML Download fails a few nicknames into my database. It appears to be >parsing a hostmask as a memo but seems to fail in different places around >the same entry each time. Refreshing the page or retrying from the menu >will usually alter the error slightly. Andrew you have a pretty recent copy >of my databases, but if you want the latest ones to try this on please let >me know. I'm not sure I still have them, can you send them again? >3) Suggestion - While StatServ pages are unimplemented within the httpd >module, [...] It's only an alpha, for crying out loud! --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Fri Feb 15 23:19:15 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Idea Message-ID: <3c6d1923.66166@achurch.org> >Why not allow multiple nicks and/or channels in the chanserv OP and >friends commands? Well, you can't have both (well, you can, but it would be one hell of a mess to code), and I don't see that this would be all that useful anyway. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Fri Feb 15 23:23:35 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] TODO update Message-ID: <3c6d1a3c.66324@achurch.org> >Minor thing, so low priority I guess, but any chance of an update to the >TODO file in the next alpha? The current one has some things included that >have been implemented (e.g. CS KICK) and does not have some things I have >seen discussed on the list as potentials. Fixed. >Andrew, I guess you have an "internal" list of things, so maybe that would >suffice for the alpha period to save time creating the specific file for >it. I do have my own list, but it's only of things that either (1) I'm already in the middle of or (2) am not going to do for 5.0 period, so I don't want to waste time discussing them while there's still so much else to deal with. >Also, any additional information on the plans for StatServ would be useful. >I would like to start putting our external StatServ features into a module, >but don't want to repeat functionality so just intend to implement those >things that probably won't make into the ircservices one. You'll know as soon as I know. (: --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Fri Feb 15 23:31:42 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Re: [IRCServices] Services 4.5.38 released Message-ID: <3c6d1c52.67257@achurch.org> >What actually causes this? I'm not familiar with this problem, could >someone explain? If someone takes a guest nick that Services then tries to assign to a user with SVSNICK, the ircd will send a KILL for the SVSNICK, but Services interprets that as a KILL for the old user, who then disappears from the internal user list. Since Services won't do anything with users who aren't on the internal list (since it doesn't have anywhere to store the info), they never get killed/ghosted, deopped, etc. --Andrew Church achurch@achurch.org http://achurch.org/ >-- Ben Goldstein (beng@nc.rr.com) > >> Also, it has been reported and confirmed that failure to install Q:lines >on >> all of your servers when nick changing (NSForceNickChange) is in use can >> allow users to escape Services' notice and use others' nicks without fear >> of retaliation via nick kills or the GHOST command. A workaround is being >> worked on for version 5.0; in the meantime, make sure you have Q:lines >> installed on all of your servers for "Guest*" (or whatever you use for >> guest nicks). > > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Fri Feb 15 23:39:08 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] Services 5.0 - NickServ register text suggestion Message-ID: <3c6d1e44.70730@achurch.org> >When NSRequireEmail is set, /ns help register will display: > >-NickServ- You must include an E-mail address when registering your >-NickServ- nickname.... >(trimmed for brevity) > >I would like to suggest that this is changed to state that the email >address must be valid or active or something which indicates to a user than >when the AUTH module is in use, a fake email address will not allow a >registration to complete. It might also be useful to include such a >disclaimer in the confirmation command for users that did not view the help >text. > >After 30+ attempts, one user still hasn't got the message that a made up >address is not going to allow his registration to be processed hence my >suggestion of "dumbing down" this process. Done. Never underestimate idiocy, I guess... --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Fri Feb 15 23:53:44 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] More bugs and suggestions for Version 5.0 Message-ID: <3c6d2134.71766@achurch.org> >> I see your point, and yes, an ID alias would be nice, but my personal >> feeling is that aliases are not a good thing (tm) :). If you >> really want the >> ID alias - make a wrapper for the IDENTIFY function. > >As I said in my post, I already have my own version of ID in each version >of services we use. I agree that aliases in general are not a good thing as >I said previously, I just thought this one was something that might be >useful to have in the main distribution. After all, there is already >SIDENTIFY which is, to all intents and purposes, an alias for IDENTIFY. The only reason it's there is because some ircd (Bahamut?) has it hard-coded in. If you want something shorter, write an alias in your client. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Fri Feb 15 23:56:52 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:14 2004 Subject: [IRCServices Coding] More bugs and suggestions for Version 5.0 Message-ID: <3c6d2633.73672@achurch.org> 1) Will consider. 2) It's been there for ages, where have you been? 3) Fixed (this is a bug in DROPNICK preventing dropping forbidden nicks and has nothing to do with #). 4) I thought this was in the TODO list but it looks like not; added. 5) No; I don't see that this is something Services needs to do. 6) No; it ought to be common enough knowledge that channel names begin with #. 7) No; see above. 8) If the suspension doesn't expire then the channel won't either. I do agree the text is a bit misleading. 9) No; unnecessary complexity. 10) No; unnecessary complexity (as mentioned in the previous mail). --Andrew Church achurch@achurch.org http://achurch.org/ >1) Suggestion: httpd module - nickname and channel lists - add an indicator >for noexpire, forbidden, suspended etc to the lists in a similar way to the >in IRC list command. > >2) Suggestion: /cs list and /ns list - add option to list suspended >nicknames and channels to bring in line with the forbidden and noexpire >options currently available. > >3) Bug: Services allows some commands to operate on #nickname. It is >possible for example to forbid #nickname. >/ns forbid #nickname >-NickServ- Nick #nickname is now forbidden. >/ns dropnick #nickname >-NickServ- Internal error--unable to process request. >/ns info will operate on an invlaid nick e.g. >Nick #nick isn't registered. >Where commands are used including a # character, or indeed any unsupported >character, the response might be better as: >-NickServ- Nick invalidnickname may not be registered or used. >or >-NickServ- Nick invalidnickname contains invalid characters. then supply >list of valid characters >Services should explicitly not support # in all nickserv commands to avoid >confusion. >Finally, maybe services could also do a similar thing to the '#' channel on >startup to clear out these nicks that are now stuck in my database :) > >4) Suggestion: /cs forbid and /ns forbid - introduce reason field for >forbid in a similar manner to the suspend command. > >5) Suggestion: Services admin /cs drop and /ns dropnick - Add a reason >field which is broadcast through globops and logged along with the drop >command. Useful for working out later why a channel or nickname was >dropped. > >6) Text bug: '/cs drop channel' produces: >-ChanServ- Syntax: FORBID channel >-ChanServ- Type /msg ChanServ HELP FORBID for more information. >Suggest that it be changed to "FORBID #channel", and/or additional >information explaining that a # prefix is required for channel names. > >7) Text bug related to 6 - /cs drop channel produces: >-ChanServ- Channel channel isn't registered. >which although correct, to be consistent with the requirement of the prefix ># ought to produce a failure message and the suggested additional >information about the prefix listed in 6. > >8) Bug - either in text or operation - /cs help suspend produces the >following information: >-ChanServ- Unlike a forbidden channel, a suspended one does not >-ChanServ- lose its information and will expire! >However, such channels do not seem to expire. As an example, a channel that >was registered and suspended in November 2001 still remains suspended >today. >-ChanServ- Registered: Nov 22 10:11:24 2001 GMT >-ChanServ- Last used: Nov 22 23:53:18 2001 GMT >-ChanServ- Channel #modshack is suspended and may not be used or identified >for. >If the help text means that they would expire if unsuspended, then the text >ought to be changed to reflect this. The problem appears to be in the >version 4.5.x series as well as version 5 since the channels I have noticed >it on were originally suspended under a version of 4.5.x and remained >unexpired after migrating to 5.0. > >9) Suggested config option to limit guest nick length. The new guest nicks >can end up using a full 9 digit precision depending on IRCd limits which on >smaller networks makes them seem a little excessive. It would be nice if >there was a configuration ption to limit this. Obviously such option would >have to be accompanied by information on the minimum length requirement. > >10) Suggestion wrt IDENTIFY command: Although generally I have not found >any reasons to consider or suggest aliases for existing services commands >since they can generally be scripted client side and merely add confusion >to the command list, I have found one "alias" that I do implement within >our services which might prove useful to everyone. That is the addition of >the command 'ID' to perform the job of 'IDENTIFY' with nickserv and >chanserv. >The main benefit I have found is since this is a command which the majority >of users will use every time they log on, is that people coming from other >networks and services packages have the option of both so can quite easily >use this primary services command in the form they already know to identify >without having to rescript. It has helped groups of people move from other >networks very easily and I find once their basics are shown to just work, >they do not mind so much if commands for say access list management are >different. The xOP module has also been very helpful for such groups. >There is also an advantage of being simple to provide appropriate help text >for since it will not affect current translations. >The other maybe less obvious benefit is less typing for people like myself >that avoid scripts and automatic identification. :) > > >Well I think that's it ... for today at least :) > >-- >Mark. > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Sat Feb 16 00:16:46 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] More bugs and suggestions for Version 5.0 Message-ID: <3c6d2683.73733@achurch.org> >> >> & channels are server local, and therefore services cant use them, + >> channels are modeless and using services on them has no point. > >well, if in some case someone start a channel "+" or "!", and put a topic like : >"come to my network xxxx.com" or "14 years old xxx pics....." , or anything like >that, it's handy to be able to close those channel permanently. You do that, and they'll just start using & channels, which Services can't get at in the first place. Better to just kick people like that off your network if you don't want them doing things like that. --Andrew Church achurch@achurch.org http://achurch.org/ From mark at ctcp.net Fri Feb 15 07:29:44 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] More bugs and suggestions for Version 5.0 Message-ID: <1455.195.92.144.170.1013786984.squirrel@secure.uksolutions.co.uk> > Andrew Church wrote: > 2) It's been there for ages, where have you been? In which case the bug is in the help text: CHAN_LIST_OPER_SYNTAX LIST pattern [FORBIDDEN] [NOEXPIRE] Mark. From achurch at achurch.org Sat Feb 16 00:31:36 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] Services 5.0 alpha 21 released Message-ID: <3c6d2a20.12455@achurch.org> Services 5.0 alpha 21 is out at the usual place. I'm tired, so no witty remarks this time, just the changes ma'am: Changes in version 5.0 alpha 21 ------------------------------- 2002/02/15 Fixes and changes suggested by Mark Hetherington : - The httpd/dbaccess module now displays suspension information for suspended nicks and channels. - NickServ HELP REGISTER now emphasizes that a _valid_ E-mail address is required with mail-auth. - Clients with the Unreal +S (service pseudoclient) mode are no longer affected by channel settings. - Forbidden nicks can now be dropped with DROPNICK. 2002/02/12 Added NSFirstAccessWild configuration directive. 2002/02/12 Fixed bug loading databases with a "#" channel registered. 2002/02/12 Fixed crash in ChanServ INFO for no-expire channels. Reported by Mark Hetherington 2002/02/11 Fixed bug in handling of failed socket connections. Reported by Ben Goldstein 2002/02/09 Fixed help messages relating to channel access levels to reflect the updated levels. Reported by Martin Pels 2002/02/09 Added TOPIC access level for ChanServ TOPIC command. 2002/02/09 Changed AUTODEOP and NOJOIN access levels to -1 and -100. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Sat Feb 16 00:32:51 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] More bugs and suggestions for Version 5.0 Message-ID: <3c6d2a2d.12470@achurch.org> >> Andrew Church wrote: >> 2) It's been there for ages, where have you been? > >In which case the bug is in the help text: > >CHAN_LIST_OPER_SYNTAX > LIST pattern [FORBIDDEN] [NOEXPIRE] Fixed in the 4.5 branch. --Andrew Church achurch@achurch.org http://achurch.org/ From mark at ctcp.net Fri Feb 15 07:38:30 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] More bugs and suggestions for Version 5.0 Message-ID: <1482.195.92.144.170.1013787510.squirrel@secure.uksolutions.co.uk> > Andrew Church Wrote: > 6) No; it ought to be common enough knowledge that channel > names begin with #. Then may I suggest, that the help file is made more consistent and the prefix removed from the following entries: 3229: SET #channel MLOCK +nt-ikl 3233: SET #channel MLOCK +knst-ilmp my-key 3238: SET #channel MLOCK + 3351: SOP #channel LIST 2-5,7-9 3382: AOP #channel LIST 2-5,7-9 3407: HOP #channel LIST 2-5,7-9 3429: VOP #channel LIST 2-5,7-9 3468: ACCESS #channel LIST 2-5,7-9 3598: Syntax: OP #channel [nick] 3605: Syntax: DEOP #channel [nick] 3612: Syntax: VOICE #channel [nick] 3619: Syntax: DEVOICE #channel [nick] 3626: Syntax: HALFOP #channel [nick] 3634: Syntax: DEHALFOP #channel [nick] 3642: Syntax: PROTECT #channel [nick] 3650: Syntax: DEPROTECT #channel [nick] (Line numbers relate to en_us.l) -- Mark. From achurch at achurch.org Sat Feb 16 00:40:15 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] More bugs and suggestions for Version 5.0 Message-ID: <3c6d2bf1.13023@achurch.org> No, you may not, but I'll fix them when I get around to it. >> Andrew Church Wrote: >> 6) No; it ought to be common enough knowledge that channel >> names begin with #. > >Then may I suggest, that the help file is made more consistent and the >prefix removed from the following entries: > > 3229: SET #channel MLOCK +nt-ikl > 3233: SET #channel MLOCK +knst-ilmp my-key > 3238: SET #channel MLOCK + > 3351: SOP #channel LIST 2-5,7-9 > 3382: AOP #channel LIST 2-5,7-9 > 3407: HOP #channel LIST 2-5,7-9 > 3429: VOP #channel LIST 2-5,7-9 > 3468: ACCESS #channel LIST 2-5,7-9 > 3598: Syntax: OP #channel [nick] > 3605: Syntax: DEOP #channel [nick] > 3612: Syntax: VOICE #channel [nick] > 3619: Syntax: DEVOICE #channel [nick] > 3626: Syntax: HALFOP #channel [nick] > 3634: Syntax: DEHALFOP #channel [nick] > 3642: Syntax: PROTECT #channel [nick] > 3650: Syntax: DEPROTECT #channel [nick] > >(Line numbers relate to en_us.l) > >-- >Mark. > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding --Andrew Church achurch@achurch.org http://achurch.org/ From mark at ctcp.net Fri Feb 15 07:51:42 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] Services 5.0a20 httpd bugs Message-ID: <1537.195.92.144.170.1013788302.squirrel@secure.uksolutions.co.uk> > Andrew Church wrote: > [XML download problems] > I'm not sure I still have them, can you send them again? I will send the databases to you tonight. > >3) Suggestion - While StatServ pages are unimplemented > within the httpd > >module, [...] > > It's only an alpha, for crying out loud! My apologies. I just thought that alpha or not, it would probably be better to fail-safe rather than just fail :) -- Mark. From griever at t2n.org Fri Feb 15 10:53:03 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] Idea In-Reply-To: <3c6d1923.66166@achurch.org> Message-ID: On Fri, 15 Feb 2002, Andrew Church wrote: > >Why not allow multiple nicks and/or channels in the chanserv OP and > >friends commands? > > Well, you can't have both (well, you can, but it would be one hell of > a mess to code), and I don't see that this would be all that useful anyway. The reason is that I'll occasionally be on a net, get disconnected and auto-rejoin all 3 channels I'm on, and I hate having to retype /chanserv OP #channel mynick over and over > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From beng at nc.rr.com Fri Feb 15 15:27:56 2002 From: beng at nc.rr.com (Ben Goldstein) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] NickServ Register then /identify Message-ID: <010001c1b678$85c02f20$0300a8c0@asi200> After REGISTERing a nick, NickServ should see you as fully identified. Since REGISTER doesn't call set_identified() to update stuff, and lets you change your nick before updating last-seen times (like it should), do_register() should have a ni->id_stamp = u->servicestamp; and not wait for the first /identify. As you see below, you still have to identify even after registering to get fully-authenticated. There could be other consequences to this delayed-stamping- like new memo notices not going to identified users using other nicks, although I havn't tested anything related to that.. I know, its sort of a nitpick :P [17:58:11] -> *nickserv* register password beng@nc.rr.com [17:58:11] #NickServ!services@example.net# Nickname beng1 has been registered to you. [17:58:11] #NickServ!services@example.net# Your password is password -- remember this for later use. [17:58:18] *** Your nick is now beng2 [17:58:22] *** Your nick is now beng1 [17:58:22] #NickServ!services@example.net# This nickname is registered and protected. If it is your nick, type /msg NickServ IDENTIFY password. Otherwise, please choose a different nick. [17:58:23] -> *Nickserv* status beng1 [17:58:23] #NickServ!services@example.net# STATUS beng1 1 [17:58:29] -> *nickserv* identify password [17:58:29] #NickServ!services@example.net# Password accepted -- you are now recognized. [17:58:33] *** Your nick is now beng2 [17:58:35] *** Your nick is now beng1 [17:58:38] -> *Nickserv* status beng1 [17:58:38] #NickServ!services@example.net# STATUS beng1 3 -- Ben Goldstein (beng@nc.rr.com) From mark at ctcp.net Fri Feb 15 15:52:32 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] Services 5.0 Odd enforcer bug Message-ID: <1514.193.237.130.98.1013817152.squirrel@secure.uksolutions.co.uk> I am not sure how to describe this other than by demonstration so... A nick 'me2' is newly registered to preclude possible issues with long term nicks. Kill protection is on. Access list is cleared (but this does not seem to actually make a difference for some clients, it just made the nick change easier to get), report from /ns info: -NickServ- Options: Kill protection, Security I will interleave the events which follow with a display from my connection watcher which might make things difficult to follow but it is an odd situation to try and describe: ** me2 joins IRC but does not identify to NickServ [23:41] SIGNON me2(g@mhetherington.demon.co.uk) at: irc.ctcp.net ** me2 gets the warning from nickserv and ignores (basically the nickname needs to be guested by SVSNICK) [23:42] Nick Change me2 Has Changed Their Nick to: Guest1228353554 [23:42] SIGNON me2(enforcer@ctcp.net) at: services.ctcp.net [23:43] SIGNOFF: me2-->(me2) ** me2 waits out the one minute hold by services then changes back to me2. I have not tried release/recover to see if it has any effect. [23:43] Nick Change Guest1228353554 Has Changed Their Nick to: me2 ** me2 identifies to NS as normal then changes nickname to something else, quits irc, ping timeouts or any action which involves the nick leaving the current nicklist. [23:43] Nick Change me2 Has Changed Their Nick to: me3 [23:43] SIGNON me2(enforcer@ctcp.net) at: services.ctcp.net enforcer takes over the nick that has changed Sorry I could not describe it in a better way, but although the above may not be the only way to recreate this problem, it is 100% reproducible. -- Mark. From mark at ctcp.net Fri Feb 15 16:24:51 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] Services 5.0 Odd enforcer bug Message-ID: <1628.193.237.130.98.1013819091.squirrel@secure.uksolutions.co.uk> Additional: This issue seems to have "permanance". Once a nickname is put into this "state", all future use of it triggers similar enforcer behaviour. continuing on from the earlier log: quit irc using alternate unregistered nick SIGNOFF: me3-->(Quit: ) rejoin irc with unregistered alternate nick SIGNON me3(g@mhetherington.demon.co.uk) at: irc.ctcp.net quit irc using alternate unregistered nick SIGNOFF: me3-->(Quit: ) rejoin with the me2 nick and identify SIGNON me2(g@mhetherington.demon.co.uk) at: irc.ctcp.net quit irc SIGNOFF: me2-->(Quit: ) SIGNON me2(enforcer@ctcp.net) at: services.ctcp.net Mark. > -----Original Message----- > From: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net]On Behalf Of Mark > Hetherington > Sent: 15 February 2002 23:53 > To: ircservices-coding@ircservices.za.net > Subject: [IRCServices Coding] Services 5.0 Odd enforcer bug > > > I am not sure how to describe this other than by demonstration so... > > A nick 'me2' is newly registered to preclude possible issues with > long term > nicks. Kill protection is on. Access list is cleared (but this does not > seem to actually make a difference for some clients, it just made > the nick > change easier to get), report from /ns info: > -NickServ- Options: Kill protection, Security > > I will interleave the events which follow with a display from my > connection > watcher which might make things difficult to follow but it is an odd > situation to try and describe: > > ** me2 joins IRC but does not identify to NickServ > [23:41] SIGNON me2(g@mhetherington.demon.co.uk) at: > irc.ctcp.net > ** me2 gets the warning from nickserv and ignores (basically the nickname > needs to be guested by SVSNICK) > [23:42] Nick Change me2 Has Changed Their Nick to: > Guest1228353554 > [23:42] SIGNON me2(enforcer@ctcp.net) at: services.ctcp.net > [23:43] SIGNOFF: me2-->(me2) > ** me2 waits out the one minute hold by services then changes > back to me2. > I have not tried release/recover to see if it has any effect. > [23:43] Nick Change Guest1228353554 Has Changed Their Nick to: > me2 > ** me2 identifies to NS as normal then changes nickname to > something else, > quits irc, ping timeouts or any action which involves the nick > leaving the > current nicklist. > [23:43] Nick Change me2 Has Changed Their Nick to: me3 > [23:43] SIGNON me2(enforcer@ctcp.net) at: services.ctcp.net > enforcer takes over the nick that has changed > > > Sorry I could not describe it in a better way, but although the above may > not be the only way to recreate this problem, it is 100% reproducible. > > -- > Mark. > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Sat Feb 16 11:02:03 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] Idea Message-ID: <3c6dbdb6.41036@achurch.org> >On Fri, 15 Feb 2002, Andrew Church wrote: > >> >Why not allow multiple nicks and/or channels in the chanserv OP and >> >friends commands? >> >> Well, you can't have both (well, you can, but it would be one hell of >> a mess to code), and I don't see that this would be all that useful anyway. > >The reason is that I'll occasionally be on a net, get disconnected and >auto-rejoin all 3 channels I'm on, and I hate having to retype /chanserv >OP #channel mynick over and over Well, I'm going to try and get a fix for that in the form of auto-op on identify so that should become irrelevant. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Sat Feb 16 11:37:56 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] Services 5.0 Odd enforcer bug Message-ID: <3c6dc611.42333@achurch.org> Fixed (typo in cancel_user()). --Andrew Church achurch@achurch.org http://achurch.org/ >I am not sure how to describe this other than by demonstration so... > >A nick 'me2' is newly registered to preclude possible issues with long term >nicks. Kill protection is on. Access list is cleared (but this does not >seem to actually make a difference for some clients, it just made the nick >change easier to get), report from /ns info: >-NickServ- Options: Kill protection, Security > >I will interleave the events which follow with a display from my connection >watcher which might make things difficult to follow but it is an odd >situation to try and describe: > >** me2 joins IRC but does not identify to NickServ >[23:41] SIGNON me2(g@mhetherington.demon.co.uk) at: irc.ctcp.net >** me2 gets the warning from nickserv and ignores (basically the nickname >needs to be guested by SVSNICK) >[23:42] Nick Change me2 Has Changed Their Nick to: >Guest1228353554 >[23:42] SIGNON me2(enforcer@ctcp.net) at: services.ctcp.net >[23:43] SIGNOFF: me2-->(me2) >** me2 waits out the one minute hold by services then changes back to me2. >I have not tried release/recover to see if it has any effect. >[23:43] Nick Change Guest1228353554 Has Changed Their Nick to: >me2 >** me2 identifies to NS as normal then changes nickname to something else, >quits irc, ping timeouts or any action which involves the nick leaving the >current nicklist. >[23:43] Nick Change me2 Has Changed Their Nick to: me3 >[23:43] SIGNON me2(enforcer@ctcp.net) at: services.ctcp.net >enforcer takes over the nick that has changed > > >Sorry I could not describe it in a better way, but although the above may >not be the only way to recreate this problem, it is 100% reproducible. > >-- >Mark. > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From griever at t2n.org Fri Feb 15 18:48:27 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] Idea In-Reply-To: <3c6dbdb6.41036@achurch.org> Message-ID: On Sat, 16 Feb 2002, Andrew Church wrote: > >On Fri, 15 Feb 2002, Andrew Church wrote: > > > >> >Why not allow multiple nicks and/or channels in the chanserv OP and > >> >friends commands? > >> > >> Well, you can't have both (well, you can, but it would be one hell of > >> a mess to code), and I don't see that this would be all that useful anyway. > > > >The reason is that I'll occasionally be on a net, get disconnected and > >auto-rejoin all 3 channels I'm on, and I hate having to retype /chanserv > >OP #channel mynick over and over > > Well, I'm going to try and get a fix for that in the form of auto-op > on identify so that should become irrelevant. ok. The multiple nick thing would be nice though. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From mark at ctcp.net Sat Feb 16 09:32:03 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] Services 5.0a21 problems Message-ID: <1474.193.237.130.98.1013880723.squirrel@secure.uksolutions.co.uk> Services appears to be losing the operserv oper/admin list. When it starts up it seems to ignore or throw away the current contents of the database and the entries have to be added back in. The only error in the log is: [Feb 16 17:11:19 2002] IRC Services 5.0a21 starting up [Feb 16 17:11:19 2002] database/version4: Read error on nick.db [Feb 16 17:24:14.156110 2002] debug: Loading module `nickserv/main' [Feb 16 17:24:14.170455 2002] database/version4: Read error on nick.db [Feb 16 17:24:14.170563 2002] debug: Successfully loaded module `nickserv/main' Not sure why there is a read error, but NickServ seems to operate successfully regardless of it. I guess it may have some bearing on the operserv list bug. As a suggestion, could the database error reporting be made provide a little more information as to which failure occurred. E.g. read error on %s by currentfunction. -- Mark. From Kevc at GMX.co.uk Sun Feb 17 09:18:14 2002 From: Kevc at GMX.co.uk (Kevin Conlin) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] SegFault References: <1474.193.237.130.98.1013880723.squirrel@secure.uksolutions.co.uk> Message-ID: <00f301c1b7d7$1959ed20$ea09fd3e@conlinr2i16j0y> Any Help on this Message? Services keep SegFaulting due to this. [Feb 17 09:28:03 2002] nickserv/main: Commish!The_Game@210.186.38.187 identified for nick Commish [Feb 17 09:28:40 2002] database/version4: nick The|Game has no NickGroupInfo, setting password to nick [Feb 17 09:28:44 2002] nickserv/main: Unable to get NickGroupInfo (id 3327104409) for The|Game at util.c:228 [Feb 17 09:28:44 2002] PANIC! buffer = :Commish & The|Game 1013959720 [Feb 17 09:28:44 2002] Services terminating: Segmentation fault [Feb 17 10:11:06 2002] IRC Services 5.0a20 starting up [Feb 17 10:11:06 2002] database/version4: Nick The|Game has no settings (linked to missing nick?), deleting [Feb 17 10:11:45 2002] IRC Services 5.0a20 starting up [Feb 17 10:11:45 2002] database/version4: Nick The|Game has no settings (linked to missing nick?), deleting TY Kevin From mark at ctcp.net Mon Feb 18 12:21:02 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] Services 5.0a21 /cs akick bug Message-ID: <1160.193.237.130.98.1014063662.squirrel@secure.uksolutions.co.uk> When adding an akick to Chanserv, Services incorrectly reformats the mask: i.e.: /cs akick #channel add user@host -ChanServ- *!user@host@@host added to #channel autokick list. /cs akick #channel add nick!user@host -ChanServ- nick!user@host@@host added to #channel autokick list. /cs skick #channel list -ChanServ- Autokick list for #channel: -ChanServ- 1 nick!user@host@@host -ChanServ- 2 *!user@host@@host -- Mark. From mark at ctcp.net Tue Feb 19 16:21:30 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] Services 5.0a21: Odd log message Message-ID: <1359.193.237.130.98.1014164490.squirrel@secure.uksolutions.co.uk> I have included the previous entry in case it is relevant, but it is more entry 2 that I wanted to mention since I assume it is indicative of a problem: [Feb 19 23:02:06 2002] channel: MODE #vodatones -o for user tharok not on channel [Feb 19 23:03:24 2002] user: BUG (?) no channel record for tharok on #vodatones (part) No more information I am afraid since I do not know where to look. If nothing else, maybe some information on what the BUG "status" indicates could help me try and get a reproducible case. - Mark. From ben at desync.com Wed Feb 20 07:19:04 2002 From: ben at desync.com (ben) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] vhosts and convert-db Message-ID: <20020220071904.C26585@desync.com> Hi. I have a question and some observations.. First, if a user has a fakehost, are you supposed to be able to see their real hostname in /nickserv INFO or did I miss something? Second, convert-db is segging on our oper.db from Epona. Also, it says this for forbidden nicknames: > Warning: nick `whatever' has null password. Setting password to nickname. ..which isn't quite the desired result. So far, I'm impressed with Services 5, though. I seem to recall someone here working on a mysql database module. Any progress on that? -b -- [ ben wilber :: ben@desync.com ] [ desync networks / inside3d ] From mark at ctcp.net Wed Feb 20 16:34:21 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] Services 5.0a21 Slipping through the AUTH net... Message-ID: <1447.193.237.130.98.1014251661.squirrel@secure.uksolutions.co.uk> On Feb 15th 2044 GMT, a nickname was registered on Services 5.0.a20. About an hour later, services was upgraded to 5.0.a21. From log information, this nickname has never used the AUTH command but is now being successfully identified for. I will be performing continous tests to see if restarting services/segfaults have any bearing on this, but tests so far have been unable to reproduce the problem. A few suggestions that would help tracking this problem and to enhance the available listing features: 1) Provide the AUTH status field for nicknames in the httpd module. 2) In a full list of nicknames (both within IRC and in http) add an indicator of non-AUTH status similar to that of SUSPENDED/FORBIDDEN. 3) Add a view option to /ns list to view nicknames that are in the awaiting AUTH status. -- Mark. From admin at nevernet.net Wed Feb 20 21:18:32 2002 From: admin at nevernet.net (Elijah) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] Logging Questions/Suggestions In-Reply-To: <1447.193.237.130.98.1014251661.squirrel@secure.uksolutions.co.uk> Message-ID: <031301c1ba97$34d11430$cc00a8c0@cc2401979c> While I know there's quite a simple fix for this, would it be possible to forget about services logging unknown messages or is there some greater purpose for them being logged? I've just noticed that if a lot of activity takes place in ChatOps or any other "unusual" server notices, they're all logged and can take up a great deal of space. Also, what about a config option to either enable or disable NickServ/ChanServ logging of every identify command being issued? When you get a healthy number of users this creates an enormous amount of garbage in the logfile, which could be useful at times but in general is just excess and a waste of disk space (imho). Just some questions, or suggestions I guess. Elijah NeverNET IRC From achurch at achurch.org Fri Feb 22 05:22:22 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] Services 5.0 alpha 22 -- the twos have it Message-ID: <3c764fbf.64133@achurch.org> You couldn't possibly expect me to resist releasing alpha 22 on 2002/2/22, could you? I'll get to mail and stuff on the weekend. Changes in version 5.0 alpha 22 ------------------------------- 2002/02/22 a22 2002/2/22 22:22:22 commemorative release. 2002/02/16 Fixed bug causing guested nicks to keep getting guested and noexpire/forbidden flags to disappear from nicks. Reported by Mark Hetherington --Andrew Church achurch@achurch.org http://achurch.org/ From mark at ctcp.net Fri Feb 22 15:58:30 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] Services 5.0 alpha 22 -- the twos have it Message-ID: <1328.193.237.130.98.1014422310.squirrel@secure.uksolutions.co.uk> The links to the latest version still refer to version 5.0a21 and these no longer work on the website. Anyone who wants the latest version can use the following link until Andrew updates the site: http://achurch.org/services/5.0-alpha/ircservices-5.0a22.tar.gz -- Mark. From mark at ctcp.net Sat Feb 23 08:15:46 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] Services 5.0a22 Segfault on unlink Message-ID: <1275.193.237.130.98.1014480946.squirrel@secure.uksolutions.co.uk> What appears to have happened is a user has nick1 and nick2 registered amnd desired to link them. User tried to drop nick2 as nick2 but did not provide the correct password to do so. After some confusion, the user then tried to unlink nick2 as nick2 despite it not being linked to anything. nickserv/link: [Feb 23 13:16:16 2002] PANIC! buffer = :banshee PRIVMSG NickServ@services.ctcp.net :unlink banshee Services terminating: Segmentation fault I guess it could be as simple as "unlink self" causing the crash. Hopefully, that will be sufficient information to begin tracking down the bug, I will try to get a fully reproducible case later. -- Mark. From rg at tcslon.com Sat Feb 23 08:30:50 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:15 2004 Subject: [IRCServices Coding] Services 5.0a22 Segfault on unlink In-Reply-To: <1275.193.237.130.98.1014480946.squirrel@secure.uksolutions.co.uk> Message-ID: > I guess it could be as simple as "unlink self" causing the crash. > Hopefully, that will be sufficient information to begin > tracking down the > bug, I will try to get a fully reproducible case later. [16:19:26] -> *nickserv* unlink Russ [16:19:26] -NickServ- Nick Russ has been unlinked from your nick. [16:20:57] -> *nickserv* status Russ [16:20:57] -NickServ- STATUS Russ 0 Here it seems unlinking yourself appears to deregister the nick. BUT... I reregister my nick: [16:22:43] -NickServ- Authorization succeeded; your nickname registration is now complete. [16:23:02] -> *nickserv* unlink Russ [16:23:02] -NickServ- Nick Russ has been unlinked from your nick. *** Routing -- from apollo.final-conflict.net: Server services.final-conflict.net[unknown@0.0.0.0] closed the connection And bang! we have a segfault. The services log is quite cryptic in saying: [Feb 23 16:23:02 2002] nickserv/link: (that's it) And here's a backtrace: (gdb) bt #0 0x40063431 in tmpfile () from /lib/libc.so.6 #1 0x40066724 in freopen64 () from /lib/libc.so.6 #2 0x40061966 in _IO_vfscanf () from /lib/libc.so.6 #3 0x8051430 in vlogprintf (fmt=0x4015d900 "0", args=0xbffff5f8) at log.c:34 #4 0x8051727 in _module_log (modname=0x81220c0 "nickserv/link", fmt=0x4015d900 "0") at log.c:189 #5 0x4015d3dd in do_unlink (u=0x812ece0) at link.c:101 #6 0x804df7a in run_cmd (service=0x8120df0 "NickServ", u=0x812ece0, id=0x811d1c8, cmd=0xbffff72e "unlink") at commands.c:175 #7 0x4014f377 in _init () from /home/ircservices/modules/nickserv/main.so #8 0x8053f1d in call_callback_5 (module=0x0, id=26, arg1=0xbffff95c, arg2=0xbffff724, arg3=0xbffff72e, arg4=0x0, arg5=0x0) at modules.c:623 #9 0x80521c5 in m_privmsg (source=0xbffff95c "Russ", ac=2, av=0x812e838) at messages.c:170 #10 0x805447c in process () at process.c:131 #11 0x8051a31 in readline_callback (s=0x812bb70, param_unused=0x24) at main.c:158 #12 0x80557bf in check_sockets () at sockets.c:375 #13 0x8051c8d in main (ac=1, av=0xbffffb54, envp=0xbffffb5c) at main.c:255 (this backtrace may be invalid, as I don't have gdb on my services machine, so I had to copy the files to another box with a slightly earlier version of services on - it looks ok though) Russ Garrett (russ@garrett.co.uk) From rg at tcslon.com Sat Feb 23 09:09:30 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] Services 5.0a22 Segfault on unlink In-Reply-To: Message-ID: OK, I've just compiled gdb 5.1 on the server and the backtrace it produces is somewhat different, so here it is (running off the actual binaries this time) - it seems to make a bit more sense: (gdb) bt #0 0x40063431 in _IO_vfprintf (s=0xbfffce58, format=0x4015d900 "%s!%s@%s unlinked nick %s from %s", ap=0xbffff60c) at vfprintf.c:1259 #1 0x40066724 in buffered_vfprintf (s=0x8079790, format=0x4015d900 "%s!%s@%s unlinked nick %s from %s", args=0xbffff5f8) at vfprintf.c:1758 #2 0x40061966 in _IO_vfprintf (s=0x8079790, format=0x4015d900 "%s!%s@%s unlinked nick %s from %s", ap=0xbffff5f8) at vfprintf.c:1029 #3 0x08051430 in vlogprintf (fmt=0x4015d900 "%s!%s@%s unlinked nick %s from %s", args=0xbffff5f8) at log.c:34 #4 0x08051727 in _module_log (modname=0x81220c0 "nickserv/link", fmt=0x4015d900 "%s!%s@%s unlinked nick %s from %s") at log.c:189 #5 0x4015d3dd in do_unlink (u=0x812ece0) at link.c:152 #6 0x0804df7a in run_cmd (service=0x8120df0 "NickServ", u=0x812ece0, id=0x811d1c8, cmd=0xbffff72e "unlink") at commands.c:175 #7 0x4014f377 in nickserv (source=0xbffff95c "Russ", target=0xbffff724 "nickserv", buf=0xbffff72e "unlink") at main.c:177 #8 0x08053f1d in call_callback_5 (module=0x0, id=26, arg1=0xbffff95c, arg2=0xbffff724, arg3=0xbffff72e, arg4=0x0, arg5=0x0) at modules.c:623 #9 0x080521c5 in m_privmsg (source=0xbffff95c "Russ", ac=2, av=0x812e838) at messages.c:170 #10 0x0805447c in process () at process.c:131 #11 0x08051a31 in readline_callback (s=0x812bb70, param_unused=0x24) at main.c:158 #12 0x080557bf in check_sockets () at sockets.c:375 #13 0x08051c8d in main (ac=1, av=0xbffffb54, envp=0xbffffb5c) at main.c:255 #14 0x400349cb in __libc_start_main (main=0x8051a34
, argc=1, argv=0xbffffb54, init=0x804bc88 <_init>, fini=0x805821c <_fini>, rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffffb4c) at ../sysdeps/generic/libc-start.c:92 Russ Garrett (russ@garrett.co.uk) From v13 at it.teithe.gr Sat Feb 23 13:31:59 2002 From: v13 at it.teithe.gr (V13) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] rfc violation ? Message-ID: <200202232131.XAA02185@ppp700.the.forthnet.gr> -NickServ- nick, type /IDENTIFY password. Otherwise, Services are using a NOTICE to notify the user that he needs to identify himself. Is this correct? RFC says that no auto-reply should be send when a notice is received, but this is not possible in case of a bot or an auto-identify script, since the notification is send using a NOTICE and not a PRIVMSG. :) <> From ShadowMaster at Shadow-Realm.org Sat Feb 23 13:59:01 2002 From: ShadowMaster at Shadow-Realm.org (Thomas J. =?iso-8859-1?q?Stens=E5s?=) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] rfc violation ? In-Reply-To: <200202232131.XAA02185@ppp700.the.forthnet.gr> References: <200202232131.XAA02185@ppp700.the.forthnet.gr> Message-ID: <200202232159.g1NLx2p49991@villageirc.net> On Saturday 23 February 2002 22:31, you wrote: > -NickServ- nick, type /IDENTIFY password. Otherwise, > > Services are using a NOTICE to notify the user that he needs to identify > himself. Is this correct? RFC says that no auto-reply should be send when a > notice is received, but this is not possible in case of a bot or an > auto-identify script, since the notification is send using a NOTICE and not > a PRIVMSG. :) There is no violation. The notice is not sent as a reply to anything other than a user using a registered nickname. If the client chooses to violate the RFC by automatically respond to the notices sent by services, thats the clients problem. -- Yours Sincerely Thomas Juberg Stens?s -- What we do in life echoes in eternity. DMCA? Who cares? http://thefreeworld.net/ From griever at t2n.org Sat Feb 23 14:27:52 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] rfc violation ? In-Reply-To: <200202232159.g1NLx2p49991@villageirc.net> Message-ID: On Sat, 23 Feb 2002, Thomas J. Stens?s wrote: > On Saturday 23 February 2002 22:31, you wrote: > > -NickServ- nick, type /IDENTIFY password. Otherwise, > > > > Services are using a NOTICE to notify the user that he needs to identify > > himself. Is this correct? RFC says that no auto-reply should be send when a > > notice is received, but this is not possible in case of a bot or an > > auto-identify script, since the notification is send using a NOTICE and not > > a PRIVMSG. :) > > There is no violation. The notice is not sent as a reply to anything other > than a user using a registered nickname. > > If the client chooses to violate the RFC by automatically respond to the > notices sent by services, thats the clients problem. It's not violating the RFC dammit! The RFC says "SHOULD not!" not "SHALL NOT!" > -- > Yours Sincerely > > Thomas Juberg Stens?s > > -- What we do in life echoes in eternity. > > DMCA? Who cares? http://thefreeworld.net/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From ShadowMaster at Shadow-Realm.org Sat Feb 23 15:55:39 2002 From: ShadowMaster at Shadow-Realm.org (Thomas J. =?iso-8859-1?q?Stens=E5s?=) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] rfc violation ? In-Reply-To: References: Message-ID: <200202232355.g1NNteh64628@villageirc.net> On Saturday 23 February 2002 23:27, you wrote: > It's not violating the RFC dammit! > The RFC says "SHOULD not!" not "SHALL NOT!" *shhhhhh* Tired =) -- Yours Sincerely Thomas Juberg Stens?s -- What we do in life echoes in eternity. DMCA? Who cares? http://thefreeworld.net/ From kfiresun at ix.netcom.com Sun Feb 24 02:14:41 2002 From: kfiresun at ix.netcom.com (Kelmar K. Firesun) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] rfc violation ? References: <200202232355.g1NNteh64628@villageirc.net> Message-ID: <002601c1bd1c$12a769e0$0200000a@stormkeepers.com> ----- Original Message ----- From: "Thomas J. Stens?s" To: Sent: Saturday, February 23, 2002 5:55 PM Subject: Re: [IRCServices Coding] rfc violation ? > On Saturday 23 February 2002 23:27, you wrote: > > It's not violating the RFC dammit! > > The RFC says "SHOULD not!" not "SHALL NOT!" > > *shhhhhh* > Tired =) > To quote RFC 1459 (emphasis added): The difference between NOTICE and PRIVMSG is that automatic replies _MUST_NEVER_ be sent in response to a NOTICE message. This is not to say that Services are not compliant with the RFC. Quite the opposite, infact. Services sends the notices so that the other end does _NOT_ auto-reply. As Thomas pointed out: if the client choses to ignore, this then it is the client that is at fault, not services. Kelmar K. Firesun (IRL: Bryce Simonds) Acting Admin: dream.esper.net From rg at tcslon.com Sun Feb 24 03:36:41 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] Update on unlinking bug In-Reply-To: <002601c1bd1c$12a769e0$0200000a@stormkeepers.com> Message-ID: Turns out that unlink self bug I tried out yesterday corrupted nick.db completely - nobody could access operserv, so I had to completely wipe the db and start again :) Teaches me I should make more regular backups I spose... not a great problem for my net, but you get the point :) Russ Garrett (russ@garrett.co.uk) From mark at ctcp.net Sun Feb 24 04:43:10 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] Update on unlinking bug Message-ID: <1060.193.237.130.98.1014554590.squirrel@secure.uksolutions.co.uk> > Russell Garrett wrote: > Turns out that unlink self bug I tried out yesterday corrupted > nick.db completely - nobody could access operserv, so I had to > completely wipe the db and start again :) Ah, could well be the cause of the problems in my nick.db and operserv lists I reported last weekend after upgrading from 5.0a20 to 5.0a21. -- Mark. From griever at t2n.org Sun Feb 24 12:07:04 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] GCC3 Message-ID: I am proud to announce that the latest version of GCC 3 compiles services without a hitch. However, it does give two warnings: it says the multi-line string literal in init.c is depreciated (that's true, it's not iso OR posix C) and it says that in do_dropnick, ngi might be used uninitialized (the syntax raises my hackles a bit, but indeed it is always initial- ized when used) I'm now going to test to see if it runs :) From mark at ctcp.net Sun Feb 24 14:32:24 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] GCC3 Message-ID: <1501.193.237.130.98.1014589944.squirrel@secure.uksolutions.co.uk> > Finny Merrill wrote: > However, it does give two warnings: it says the multi-line string > literal in init.c is depreciated (that's true, it's not iso OR posix > C) and it says that in do_dropnick, ngi might be used uninitialized > (the syntax raises my hackles a bit, but indeed it is always initial- > ized when used) IIRC the warning about "ngi might be used uninitialised" is not merely a GCC 3.0 error since I have been seeing it for a while. It occurs because of the way the code initialises ngi within an if condition where another condition that must be true is also involved. Personally, I would fix such a warning since it would be a legitimate operation for the compiler to generate code that could skip the initialisation of ngi. The particular line in question is: if (ni->nickgroup && !(ngi = get_ngi(ni))) Should ni->nickgroup be zero, the compiler could have output code which would skip the initialisation of ngi since it would not pass an AND operation leading to a later illegal acces to ngi. -- Mark. From griever at t2n.org Sun Feb 24 14:39:38 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] GCC3 In-Reply-To: <1501.193.237.130.98.1014589944.squirrel@secure.uksolutions.co.uk> Message-ID: On Sun, 24 Feb 2002, Mark Hetherington wrote: > > Finny Merrill wrote: > > However, it does give two warnings: it says the multi-line string > > literal in init.c is depreciated (that's true, it's not iso OR posix > > C) and it says that in do_dropnick, ngi might be used uninitialized > > (the syntax raises my hackles a bit, but indeed it is always initial- > > ized when used) > > IIRC the warning about "ngi might be used uninitialised" is not merely a > GCC 3.0 error since I have been seeing it for a while. > > It occurs because of the way the code initialises ngi within an if > condition where another condition that must be true is also involved. > > Personally, I would fix such a warning since it would be a legitimate > operation for the compiler to generate code that could skip the > initialisation of ngi. > > The particular line in question is: > > if (ni->nickgroup && !(ngi = get_ngi(ni))) > > Should ni->nickgroup be zero, the compiler could have output code which > would skip the initialisation of ngi since it would not pass an AND > operation leading to a later illegal acces to ngi. it MUST skip the initialization of ngi if ni->nickgroup compares equal to 0 > > From achurch at achurch.org Mon Feb 25 18:01:46 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] GCC3 Message-ID: <3c79ff5d.24131@achurch.org> The major problem I have with GCC 3.0 is that it reorders structures (or at least did at one point), which would break convert-db, and in general is a Bad Idea (among other things it prevents you from laying structures on top of data in memory). Does anyone know if this has been fixed or if there's a way around it? >IIRC the warning about "ngi might be used uninitialised" is not merely a >GCC 3.0 error since I have been seeing it for a while. > >It occurs because of the way the code initialises ngi within an if >condition where another condition that must be true is also involved. > >Personally, I would fix such a warning since it would be a legitimate >operation for the compiler to generate code that could skip the >initialisation of ngi. ngi is never used if it isn't initialized (read the code). I've never seen this warning, incidentally; have you changed the default compiler options? --Andrew Church achurch@achurch.org http://achurch.org/ From mark at ctcp.net Mon Feb 25 02:27:09 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] GCC3 Message-ID: <1102.195.92.144.170.1014632829.squirrel@secure.uksolutions.co.uk> > [snip] "ngi might be used uninitialised" is > ngi is never used if it isn't initialized (read the code). I *have* read the code. > I've > never seen this warning, incidentally; have you changed the default > compiler options? No. -- Mark. From griever at t2n.org Mon Feb 25 03:50:21 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] GCC3 In-Reply-To: <3c79ff5d.24131@achurch.org> Message-ID: On Mon, 25 Feb 2002, Andrew Church wrote: > The major problem I have with GCC 3.0 is that it reorders structures > (or at least did at one point), which would break convert-db, and in > general is a Bad Idea (among other things it prevents you from laying > structures on top of data in memory). Does anyone know if this has been > fixed or if there's a way around it? Are you sure it reordered them? It might just have changed the padding between members, which compilers have been known to do in the past. Anyhow, I haven't tried convert-db yet but I will when I get the chance > > >IIRC the warning about "ngi might be used uninitialised" is not merely a > >GCC 3.0 error since I have been seeing it for a while. > > > >It occurs because of the way the code initialises ngi within an if > >condition where another condition that must be true is also involved. > > > >Personally, I would fix such a warning since it would be a legitimate > >operation for the compiler to generate code that could skip the > >initialisation of ngi. > > ngi is never used if it isn't initialized (read the code). I've > never seen this warning, incidentally; have you changed the default > compiler options? > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From achurch at achurch.org Mon Feb 25 22:39:22 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] GCC3 Message-ID: <3c7a3f40.10425@achurch.org> >> The major problem I have with GCC 3.0 is that it reorders structures >> (or at least did at one point), which would break convert-db, and in >> general is a Bad Idea (among other things it prevents you from laying >> structures on top of data in memory). Does anyone know if this has been >> fixed or if there's a way around it? > >Are you sure it reordered them? It might just have changed the padding >between members, which compilers have been known to do in the past. >Anyhow, I haven't tried convert-db yet but I will when I get the chance To be perfectly honest, that's based on hearsay--I haven't confirmed it one way or the other. But I do recall quite a lot of discussion on that point, so I'd like to have confirmation that it does work before "officially" endorsing it. --Andrew Church achurch@achurch.org http://achurch.org/ From kfiresun at ix.netcom.com Mon Feb 25 13:04:55 2002 From: kfiresun at ix.netcom.com (Kelmar K. Firesun) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] GCC3 References: <3c7a3f40.10425@achurch.org> Message-ID: <004601c1be40$13b778a0$0200000a@stormkeepers.com> ----- Original Message ----- From: "Andrew Church" To: Sent: Monday, February 25, 2002 7:39 AM Subject: RE: [IRCServices Coding] GCC3 > >> The major problem I have with GCC 3.0 is that it reorders structures > >> (or at least did at one point), which would break convert-db, and in > >> general is a Bad Idea (among other things it prevents you from laying > >> structures on top of data in memory). Does anyone know if this has been > >> fixed or if there's a way around it? > > > >Are you sure it reordered them? It might just have changed the padding > >between members, which compilers have been known to do in the past. > >Anyhow, I haven't tried convert-db yet but I will when I get the chance > > To be perfectly honest, that's based on hearsay--I haven't confirmed > it one way or the other. But I do recall quite a lot of discussion on that > point, so I'd like to have confirmation that it does work before > "officially" endorsing it. > I could certanly see it padding the data structures. This would be to optimize memory access by keeping things aligned with the CPU's WORD size. 64bits in the case of most Intel Pentiums if I recall correctly. For example, if you have a structure like so: struct foo { int_16 bar; int_8 baz; }; The compiler would append or prepend (depending on compiler) on an extra 40bits of data to align it in memory on each allocation. If this is the case there SHOULD be a command line option to tell the compiler to disable this optimization. In other cases, you can disable this on a structure by structure basis using a "packed" (or something similar) keyword. Note, that this optimization could also apply to an array. This is a very common optimization for speed in many compilers. I'm actually very surprised that GCC would just now be implementing it. Kelmar K. Firesun (IRL: Bryce Simonds) Acting Admin: dream.esper.net From quension at softhome.net Mon Feb 25 18:28:57 2002 From: quension at softhome.net (Trevor Talbot) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] GCC3 In-Reply-To: <004601c1be40$13b778a0$0200000a@stormkeepers.com> Message-ID: <95DF3A2A-2A60-11D6-A265-0003938D6866@softhome.net> On Monday, February 25, 2002, at 01:04 PM, Kelmar K. Firesun wrote: > ----- Original Message ----- > From: "Andrew Church" > >>>> The major problem I have with GCC 3.0 is that it reorders >>>> structures >>>> (or at least did at one point), which would break convert-db, and in >>>> general is a Bad Idea (among other things it prevents you from laying >>>> structures on top of data in memory). Does anyone know if this has >>>> been >>>> fixed or if there's a way around it? >>> >>> Are you sure it reordered them? It might just have changed the padding >>> between members, which compilers have been known to do in the past. >>> Anyhow, I haven't tried convert-db yet but I will when I get the >>> chance >> >> To be perfectly honest, that's based on hearsay--I haven't >> confirmed >> it one way or the other. But I do recall quite a lot of discussion on >> that >> point, so I'd like to have confirmation that it does work before >> "officially" endorsing it. Reordering is not permitted by the ANSI/ISO C standards. > I could certanly see it padding the data structures. > This would be to optimize memory access by keeping things > aligned with the CPU's WORD size. 64bits in the case of > most Intel Pentiums if I recall correctly. Usually 32 bits, possible exceptions where optimized structures occur (MMX usage, for example). > For example, if you have a structure like so: > > struct foo > { > int_16 bar; > int_8 baz; > }; > > The compiler would append or prepend (depending on compiler) > on an extra 40bits of data to align it in memory on each > allocation. Under 32bit x86, it's likely to add 8 bits of padding to the end of the structure. The alignment is for the width of the largest datatype. > This is a very common optimization for speed in many compilers. > I'm actually very surprised that GCC would just now be > implementing it. Not just for speed; some platforms require aligned types (such as Motorola 68k and PPC under certain conditions). It's also well-documented by the C standards. Partly for this reason, mapping structs onto arbitrary data in memory results in undefined behavior. -- Quension From achurch at achurch.org Tue Feb 26 14:48:57 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] GCC3 Message-ID: <3c7b236e.01202@achurch.org> >Reordering is not permitted by the ANSI/ISO C standards. That's what I thought, but a whole bunch of people seemed to think GCC 3.0 was doing just that. >> struct foo >> { >> int_16 bar; >> int_8 baz; >> }; >> >> The compiler would append or prepend (depending on compiler) >> on an extra 40bits of data to align it in memory on each >> allocation. > >Under 32bit x86, it's likely to add 8 bits of padding to the end >of the structure. The alignment is for the width of the largest >datatype. Again, that's what I thought--compilers aren't supposed to pad more than the largest type in the structure, and between structure members only enough to align the next member to a multiple of its size. I'm pretty sure this is defined somewhere, and if not then it should be (see below). >Partly for this reason, mapping structs onto arbitrary data in >memory results in undefined behavior. It shouldn't, and if it did things would break all over the place. Suppose you have two compilers, one of which is used to compile a program, and the other of which is used to compile a library used by the program. Now suppose the program passes a pointer to a structure (say, a FILE *) to the library. If the two compilers use different algorithms to pad structure members, guess what happens? Boom. --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Mon Feb 25 22:18:47 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] GCC3 In-Reply-To: <3c7b236e.01202@achurch.org> Message-ID: On Tue, 26 Feb 2002, Andrew Church wrote: > >Reordering is not permitted by the ANSI/ISO C standards. > > That's what I thought, but a whole bunch of people seemed to think GCC > 3.0 was doing just that. > > >> struct foo > >> { > >> int_16 bar; > >> int_8 baz; > >> }; > >> > >> The compiler would append or prepend (depending on compiler) > >> on an extra 40bits of data to align it in memory on each > >> allocation. > > > >Under 32bit x86, it's likely to add 8 bits of padding to the end > >of the structure. The alignment is for the width of the largest > >datatype. > > Again, that's what I thought--compilers aren't supposed to pad more > than the largest type in the structure, and between structure members only > enough to align the next member to a multiple of its size. I'm pretty sure > this is defined somewhere, and if not then it should be (see below). Not the largest type in the structure, the largest *type*. Most structures will pad to 32 bits on intel machines. like this: struct { int8_t byte; /* inserts 8 or 24 bits of padding here */ int16_t word; /* inserts 16 bits of padding here */ int32_t dword; /* no padding here */ } something; > > >Partly for this reason, mapping structs onto arbitrary data in > >memory results in undefined behavior. > > It shouldn't, and if it did things would break all over the place. > Suppose you have two compilers, one of which is used to compile a program, > and the other of which is used to compile a library used by the program. > Now suppose the program passes a pointer to a structure (say, a FILE *) to > the library. If the two compilers use different algorithms to pad > structure members, guess what happens? Boom. > IF I remember correctly, POSIX mandates uniform structure padding for all compilers on a single platform. > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From achurch at achurch.org Tue Feb 26 15:31:57 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] GCC3 Message-ID: <3c7b2cab.01270@achurch.org> >> Again, that's what I thought--compilers aren't supposed to pad more >> than the largest type in the structure, and between structure members only >> enough to align the next member to a multiple of its size. I'm pretty sure >> this is defined somewhere, and if not then it should be (see below). >Not the largest type in the structure, the largest *type*. >Most structures will pad to 32 bits on intel machines. > >like this: > >struct { > int8_t byte; > /* inserts 8 or 24 bits of padding here */ > int16_t word; > /* inserts 16 bits of padding here */ > int32_t dword; > /* no padding here */ >} something; That's missing the point; you put a 32-bit type in there, which of course means it will pad to 32 bits. (And by your argument, it would have to pad to at least the size of a double, not just an int32_t.) What you're saying would be something like: struct { int8_t byte; /* 24 bits of padding */ int16_t word; /* 16 bits of padding */ } foo; /* size = 64 bits */ which is stupid because you have 32 bits of wasted space, when you could just as easily and with no alignment problems (at least on any CPU I know of) have done: struct { int8_t byte; /* 8 bits of padding */ int16_t word; } bar; /* size = 32 bits */ --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Feb 26 15:36:30 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] GCC3 Message-ID: <3c7b2d29.01321@achurch.org> Just to clarify, my point is padding shouldn't be put in where it isn't needed; for example, struct { int8_t a, b, c; } baz; should give sizeof(baz) == 3 (and it does in gcc 2.95.3). --Andrew Church achurch@achurch.org http://achurch.org/ >>> Again, that's what I thought--compilers aren't supposed to pad more >>> than the largest type in the structure, and between structure members only >>> enough to align the next member to a multiple of its size. I'm pretty sure >>> this is defined somewhere, and if not then it should be (see below). >>Not the largest type in the structure, the largest *type*. >>Most structures will pad to 32 bits on intel machines. >> >>like this: >> >>struct { >> int8_t byte; >> /* inserts 8 or 24 bits of padding here */ >> int16_t word; >> /* inserts 16 bits of padding here */ >> int32_t dword; >> /* no padding here */ >>} something; > > That's missing the point; you put a 32-bit type in there, which of >course means it will pad to 32 bits. (And by your argument, it would have >to pad to at least the size of a double, not just an int32_t.) What you're >saying would be something like: > >struct { > int8_t byte; > /* 24 bits of padding */ > int16_t word; > /* 16 bits of padding */ >} foo; /* size = 64 bits */ > >which is stupid because you have 32 bits of wasted space, when you could >just as easily and with no alignment problems (at least on any CPU I know >of) have done: > >struct { > int8_t byte; > /* 8 bits of padding */ > int16_t word; >} bar; /* size = 32 bits */ > > --Andrew Church > achurch@achurch.org > http://achurch.org/ >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Tue Feb 26 16:32:57 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:16 2004 Subject: [IRCServices Coding] Services 5.0a21 problems Message-ID: <3c7b3b1e.03172@achurch.org> >Services appears to be losing the operserv oper/admin list. When it starts >up it seems to ignore or throw away the current contents of the database >and the entries have to be added back in. > >The only error in the log is: >[Feb 16 17:11:19 2002] IRC Services 5.0a21 starting up >[Feb 16 17:11:19 2002] database/version4: Read error on nick.db Found and fixed; apparently some earlier alphas left a nickgroup with ID 0 in the database, which causes a read error when loading. >As a suggestion, could the database error reporting be made provide a >little more information as to which failure occurred. E.g. read error on %s >by currentfunction. I do plan to change a few error messages around, but in general "read error" means "unexpected EOF", and in such a case reporting where it came from is pretty meaningless (since the actual data corruption may have happened much earlier in the file). --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Feb 26 16:40:23 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Services 5.0a21 /cs akick bug Message-ID: <3c7b3c0c.03652@achurch.org> >When adding an akick to Chanserv, Services incorrectly reformats the mask: Fixed, thanks. >i.e.: > >/cs akick #channel add user@host >-ChanServ- *!user@host@@host added to #channel autokick list. > >/cs akick #channel add nick!user@host >-ChanServ- nick!user@host@@host added to #channel autokick list. > >/cs skick #channel list >-ChanServ- Autokick list for #channel: >-ChanServ- 1 nick!user@host@@host >-ChanServ- 2 *!user@host@@host > >-- >Mark. > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Mon Feb 25 23:43:26 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] GCC3 In-Reply-To: <3c7b2cab.01270@achurch.org> Message-ID: On Tue, 26 Feb 2002, Andrew Church wrote: > >> Again, that's what I thought--compilers aren't supposed to pad more > >> than the largest type in the structure, and between structure members only > >> enough to align the next member to a multiple of its size. I'm pretty sure > >> this is defined somewhere, and if not then it should be (see below). > >Not the largest type in the structure, the largest *type*. > >Most structures will pad to 32 bits on intel machines. > > > >like this: > > > >struct { > > int8_t byte; > > /* inserts 8 or 24 bits of padding here */ > > int16_t word; > > /* inserts 16 bits of padding here */ > > int32_t dword; > > /* no padding here */ > >} something; > > That's missing the point; you put a 32-bit type in there, which of > course means it will pad to 32 bits. (And by your argument, it would have > to pad to at least the size of a double, not just an int32_t.) What you're > saying would be something like: > > struct { > int8_t byte; > /* 24 bits of padding */ > int16_t word; > /* 16 bits of padding */ > } foo; /* size = 64 bits */ > > which is stupid because you have 32 bits of wasted space, when you could > just as easily and with no alignment problems (at least on any CPU I know > of) have done: > > struct { > int8_t byte; > /* 8 bits of padding */ > int16_t word; > } bar; /* size = 32 bits */ Hmm, you're right. BUT, some compilers might be too stupid to do it this correct way. Plus if you did this: struct { int8_t byte; /* 8 bits of padding */ int16_t word1, word2; /* 16 bits of padding! */ } bar; it pads the extra 16 bits so it's on a 32 bit boundary. and btw, even if you have doubles or long longs in there, it still aligns on 32 bit boundaries. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From griever at t2n.org Mon Feb 25 23:43:57 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] GCC3 In-Reply-To: <3c7b2d29.01321@achurch.org> Message-ID: On Tue, 26 Feb 2002, Andrew Church wrote: > Just to clarify, my point is padding shouldn't be put in where it > isn't needed; for example, > > struct { > int8_t a, b, c; > } baz; > > should give sizeof(baz) == 3 (and it does in gcc 2.95.3). odd... > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > > >>> Again, that's what I thought--compilers aren't supposed to pad more > >>> than the largest type in the structure, and between structure members only > >>> enough to align the next member to a multiple of its size. I'm pretty sure > >>> this is defined somewhere, and if not then it should be (see below). > >>Not the largest type in the structure, the largest *type*. > >>Most structures will pad to 32 bits on intel machines. > >> > >>like this: > >> > >>struct { > >> int8_t byte; > >> /* inserts 8 or 24 bits of padding here */ > >> int16_t word; > >> /* inserts 16 bits of padding here */ > >> int32_t dword; > >> /* no padding here */ > >>} something; > > > > That's missing the point; you put a 32-bit type in there, which of > >course means it will pad to 32 bits. (And by your argument, it would have > >to pad to at least the size of a double, not just an int32_t.) What you're > >saying would be something like: > > > >struct { > > int8_t byte; > > /* 24 bits of padding */ > > int16_t word; > > /* 16 bits of padding */ > >} foo; /* size = 64 bits */ > > > >which is stupid because you have 32 bits of wasted space, when you could > >just as easily and with no alignment problems (at least on any CPU I know > >of) have done: > > > >struct { > > int8_t byte; > > /* 8 bits of padding */ > > int16_t word; > >} bar; /* size = 32 bits */ > > > > --Andrew Church > > achurch@achurch.org > > http://achurch.org/ > >------------------------------------------------------------------ > >To unsubscribe or change your subscription options, visit: > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From achurch at achurch.org Tue Feb 26 16:42:26 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Services 5.0a21: Odd log message Message-ID: <3c7b3e13.03702@achurch.org> >I have included the previous entry in case it is relevant, but it is more >entry 2 that I wanted to mention since I assume it is indicative of a >problem: > >[Feb 19 23:02:06 2002] channel: MODE #vodatones -o for user tharok not on >channel >[Feb 19 23:03:24 2002] user: BUG (?) no channel record for tharok on >#vodatones (part) > >No more information I am afraid since I do not know where to look. If >nothing else, maybe some information on what the BUG "status" indicates >could help me try and get a reproducible case. "BUG" indicates a situation that should never occur if the program is correctly coded; for example, something like the following: if (i < 0 || i > 3) return -1; switch (i) { case 0: /* ... */ break; case 1: /* ... */ break; case 2: /* ... */ break; default: log("BUG: impossible value for i (%d)", i); return -1; } In this case, it indicates that a PART message was received for a user who was not recorded as being on the channel they were supposedly parting, which means there's a bug in either Services or the ircds. (Most probably this is a Services bug, but since it could potentially be caused by bad messages from the uplink server this probably shouldn't be marked "BUG" as the other BUG cases are.) --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Feb 26 16:53:25 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] SegFault Message-ID: <3c7b3f8e.03723@achurch.org> >Any Help on this Message? Services keep SegFaulting due to this. I don't see anything offhand in the code that would cause this. Can you send me your databases? --Andrew Church achurch@achurch.org http://achurch.org/ >[Feb 17 09:28:03 2002] nickserv/main: Commish!The_Game@210.186.38.187 >identified for nick Commish >[Feb 17 09:28:40 2002] database/version4: nick The|Game has no >NickGroupInfo, setting password to nick >[Feb 17 09:28:44 2002] nickserv/main: Unable to get NickGroupInfo (id >3327104409) for The|Game at util.c:228 >[Feb 17 09:28:44 2002] PANIC! buffer = :Commish & The|Game 1013959720 >[Feb 17 09:28:44 2002] Services terminating: Segmentation fault >[Feb 17 10:11:06 2002] IRC Services 5.0a20 starting up >[Feb 17 10:11:06 2002] database/version4: Nick The|Game has no settings >(linked to missing nick?), deleting >[Feb 17 10:11:45 2002] IRC Services 5.0a20 starting up >[Feb 17 10:11:45 2002] database/version4: Nick The|Game has no settings >(linked to missing nick?), deleting > >TY >Kevin > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Tue Feb 26 16:56:33 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] vhosts and convert-db Message-ID: <3c7b4006.03734@achurch.org> >Hi. I have a question and some observations.. > >First, if a user has a fakehost, are you supposed to be able to see their real hostname in /nickserv INFO or did I miss something? Yes, if you are the nick owner or a Services admin. >Second, convert-db is segging on our oper.db from Epona. Also, it says this for forbidden nicknames: >> Warning: nick `whatever' has null password. Setting password to nickname. >..which isn't quite the desired result. Can you send me your Epona database so I can test this? >So far, I'm impressed with Services 5, though. I seem to recall someone here working on a mysql database module. Any progress on that? It's not me, so I can't answer that, but I do eventually plan to have some sort of DBMS interface in Services. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Feb 26 16:58:53 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Logging Questions/Suggestions Message-ID: <3c7b4067.03747@achurch.org> >While I know there's quite a simple fix for this, would it be possible >to forget about services logging unknown messages or is there some >greater purpose for them being logged? I've just noticed that if a lot >of activity takes place in ChatOps or any other "unusual" server >notices, they're all logged and can take up a great deal of space. Also, >what about a config option to either enable or disable NickServ/ChanServ >logging of every identify command being issued? When you get a healthy >number of users this creates an enormous amount of garbage in the >logfile, which could be useful at times but in general is just excess >and a waste of disk space (imho). If you get messages like this I'd appreciate knowing what commands are being used and for what server so I can include them in the message list. --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Mon Feb 25 23:58:55 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] vhosts and convert-db In-Reply-To: <3c7b4006.03734@achurch.org> Message-ID: On Tue, 26 Feb 2002, Andrew Church wrote: > >Hi. I have a question and some observations.. > > > >First, if a user has a fakehost, are you supposed to be able to see their real hostname in /nickserv INFO or did I miss something? > > Yes, if you are the nick owner or a Services admin. > > >Second, convert-db is segging on our oper.db from Epona. Also, it says this for forbidden nicknames: > >> Warning: nick `whatever' has null password. Setting password to nickname. > >..which isn't quite the desired result. > > Can you send me your Epona database so I can test this? > > >So far, I'm impressed with Services 5, though. I seem to recall someone here working on a mysql database module. Any progress on that? > > It's not me, so I can't answer that, but I do eventually plan to have > some sort of DBMS interface in Services. It's me. I haven't worked on it for a while though due to time constraints, but once it's done I'll send it to andy so he can mangle it up the way he wants :P. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From griever at t2n.org Mon Feb 25 23:59:50 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] GCC3 sizes Message-ID: [griever@linux ircservices-5.0a22]$ gcc3 tools/cdtest.c -I. -DCONVERT_DB [griever@linux ircservices-5.0a22]$ ./a.out NickInfo: 320 ChannelInfo: 1152 NickGroupInfo: 376 [griever@linux ircservices-5.0a22]$ gcc tools/cdtest.c -I. -DCONVERT_DB [griever@linux ircservices-5.0a22]$ ./a.out NickInfo: 320 ChannelInfo: 1152 NickGroupInfo: 376 it seems as if there is no alignment change :/ So I don't know what's going on here. From achurch at achurch.org Tue Feb 26 17:02:24 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] GCC3 Message-ID: <3c7b4174.04007@achurch.org> >Plus if you did this: > >struct { > int8_t byte; > /* 8 bits of padding */ > int16_t word1, word2; > /* 16 bits of padding! */ >} bar; > >it pads the extra 16 bits so it's on a 32 bit boundary. Um, no it doesn't: #include struct { int8_t byte; int16_t word1, word2; } bar; main() { printf("%d\n", sizeof(bar)); } "6" is printed: 1 byte + 1 byte of padding + 2*2 bytes. (Incidentally, it looks like you're right on the double/long long issue; my apologies.) --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Feb 26 17:15:44 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Services 5.0a22 Segfault on unlink Message-ID: <3c7b4467.04045@achurch.org> >What appears to have happened is a user has nick1 and nick2 registered amnd >desired to link them. User tried to drop nick2 as nick2 but did not provide >the correct password to do so. After some confusion, the user then tried to >unlink nick2 as nick2 despite it not being linked to anything. >nickserv/link: [Feb 23 13:16:16 2002] PANIC! buffer = :banshee PRIVMSG >NickServ@services.ctcp.net :unlink banshee >Services terminating: Segmentation fault I, um, already fixed this once. Really. The gremlins must have ate the fix, or something... yeah, that's it. Gremlins did it. --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Tue Feb 26 00:19:38 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] GCC3 In-Reply-To: <3c7b4174.04007@achurch.org> Message-ID: On Tue, 26 Feb 2002, Andrew Church wrote: > >Plus if you did this: > > > >struct { > > int8_t byte; > > /* 8 bits of padding */ > > int16_t word1, word2; > > /* 16 bits of padding! */ > >} bar; > > > >it pads the extra 16 bits so it's on a 32 bit boundary. > > Um, no it doesn't: You're right. Unlike some compilers, GCC doesn't pad types at the end. It still aligns statics and autos on the 32 bit boundary, but if you malloced it, there would still be the extra 16 bits. > > #include > struct { > int8_t byte; > int16_t word1, word2; > } bar; > main() { printf("%d\n", sizeof(bar)); } > > "6" is printed: 1 byte + 1 byte of padding + 2*2 bytes. wierd, I always though structs were multiples of 4 bytes. > > (Incidentally, it looks like you're right on the double/long long > issue; my apologies.) > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From achurch at achurch.org Tue Feb 26 17:23:36 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] NickServ Register then /identify Message-ID: <3c7b4663.06002@achurch.org> >After REGISTERing a nick, NickServ should see you as fully identified. Since >REGISTER doesn't call set_identified() to update stuff, and lets you change >your nick before updating last-seen times (like it should), do_register() >should have a ni->id_stamp = u->servicestamp; and not wait for the first >/identify. As you see below, you still have to identify even after >registering to get fully-authenticated. Fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ >There could be other consequences to this delayed-stamping- like new memo >notices not going to identified users using other nicks, although I havn't >tested anything related to that.. I know, its sort of a nitpick :P > >[17:58:11] -> *nickserv* register password beng@nc.rr.com >[17:58:11] #NickServ!services@example.net# Nickname beng1 has been >registered to you. >[17:58:11] #NickServ!services@example.net# Your password is password -- >remember this for later use. >[17:58:18] *** Your nick is now beng2 >[17:58:22] *** Your nick is now beng1 >[17:58:22] #NickServ!services@example.net# This nickname is registered and >protected. If it is your nick, type /msg NickServ IDENTIFY >password. Otherwise, please choose a different nick. >[17:58:23] -> *Nickserv* status beng1 >[17:58:23] #NickServ!services@example.net# STATUS beng1 1 >[17:58:29] -> *nickserv* identify password >[17:58:29] #NickServ!services@example.net# Password accepted -- you are now >recognized. >[17:58:33] *** Your nick is now beng2 >[17:58:35] *** Your nick is now beng1 >[17:58:38] -> *Nickserv* status beng1 >[17:58:38] #NickServ!services@example.net# STATUS beng1 3 > >-- Ben Goldstein (beng@nc.rr.com) > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From kfiresun at ix.netcom.com Tue Feb 26 05:05:56 2002 From: kfiresun at ix.netcom.com (Kelmar K. Firesun) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] GCC3 References: Message-ID: <002701c1bec6$54327700$0200000a@stormkeepers.com> ----- Original Message ----- From: "Finny Merrill" To: Sent: Tuesday, February 26, 2002 2:19 AM Subject: Re: [IRCServices Coding] GCC3 ] ... SNIP ... [ > > > "6" is printed: 1 byte + 1 byte of padding + 2*2 bytes. > wierd, I always though structs were multiples of 4 bytes. > 6 would imply a 16bit alignment, I would expect it to display 8 for 32bit alignment. I'll also note that after testing this on another compiler, I was not able to adjust this number even when I told it to use a different boundary. http://developer.intel.com/design/mobile/manuals/24281603.pdf According to the above it would appear that data should be alligned on a 32-byte boundary for structures larger than 32-bytes. (There are also some other gnifty points in there ;) Mmm... Assembly...... :9 Kelmar K. Firesun (IRL: Bryce Simonds) Acting Admin: dream.esper.net From quension at softhome.net Tue Feb 26 08:09:26 2002 From: quension at softhome.net (Trevor Talbot) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] GCC3 In-Reply-To: Message-ID: <34AB0E40-2AD3-11D6-8FB8-0003938D6866@softhome.net> On Tuesday, February 26, 2002, at 12:19 AM, Finny Merrill wrote: > On Tue, 26 Feb 2002, Andrew Church wrote: > >>> Plus if you did this: >>> >>> struct { >>> int8_t byte; >>> /* 8 bits of padding */ >>> int16_t word1, word2; >>> /* 16 bits of padding! */ >>> } bar; >>> >>> it pads the extra 16 bits so it's on a 32 bit boundary. >> >> Um, no it doesn't: > You're right. Unlike some compilers, GCC doesn't pad types > at the end. It still aligns statics and autos on the 32 bit > boundary, but if you malloced it, there would still be the extra > 16 bits. Without meaning any offense, you're full of odd misinformation. Variables of static and auto duration have no alignment other than the size of their type; malloc() has nothing to do with padding at all. And gcc will pad structs wherever is required (including the end), except at the beginning. -- Quension From quension at softhome.net Tue Feb 26 08:09:34 2002 From: quension at softhome.net (Trevor Talbot) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] GCC3 In-Reply-To: <3c7b236e.01202@achurch.org> Message-ID: <397C2F92-2AD3-11D6-8FB8-0003938D6866@softhome.net> On Monday, February 25, 2002, at 09:48 PM, Andrew Church wrote: >> Reordering is not permitted by the ANSI/ISO C standards. > > That's what I thought, but a whole bunch of people seemed to think > GCC > 3.0 was doing just that. It occurs to me that this has been talked about as a somewhat-useful optimization. The idea is to reorder struct members for optimal padding. But even if gcc did adopt this as an extension (I don't know if it does or not), it would have to be disabled by default, as several things (such as ANSI offsetof()) would break. > Again, that's what I thought--compilers aren't supposed to pad more > than the largest type in the structure, and between structure members > only > enough to align the next member to a multiple of its size. I'm pretty > sure > this is defined somewhere, and if not then it should be (see below). > >> Partly for this reason, mapping structs onto arbitrary data in >> memory results in undefined behavior. > > It shouldn't, and if it did things would break all over the place. > Suppose you have two compilers, one of which is used to compile a > program, > and the other of which is used to compile a library used by the program. > Now suppose the program passes a pointer to a structure (say, a FILE *) > to > the library. If the two compilers use different algorithms to pad > structure members, guess what happens? Boom. Actually, I was referring to things such as: struct tag { char type; uint_32 value; } *s; char map[32]; /* load map with some data */ s = (struct tag *)map; But your point about compilers is a valid one; I don't know about POSIX (as someone else commented), but in general compilers adopt the same alignment scheme for a particular architecture. After all, the architecture is what requires certain alignments anyway :) -- Quension From griever at t2n.org Tue Feb 26 12:01:21 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] GCC3 In-Reply-To: <397C2F92-2AD3-11D6-8FB8-0003938D6866@softhome.net> Message-ID: On Tue, 26 Feb 2002, Trevor Talbot wrote: > On Monday, February 25, 2002, at 09:48 PM, Andrew Church wrote: > > >> Reordering is not permitted by the ANSI/ISO C standards. > > > > That's what I thought, but a whole bunch of people seemed to think > > GCC > > 3.0 was doing just that. > > It occurs to me that this has been talked about as a somewhat-useful > optimization. The idea is to reorder struct members for optimal padding. > But even if gcc did adopt this as an extension (I don't know if it does > or > not), it would have to be disabled by default, as several things (such as > ANSI offsetof()) would break. > > > Again, that's what I thought--compilers aren't supposed to pad more > > than the largest type in the structure, and between structure members > > only > > enough to align the next member to a multiple of its size. I'm pretty > > sure > > this is defined somewhere, and if not then it should be (see below). > > > >> Partly for this reason, mapping structs onto arbitrary data in > >> memory results in undefined behavior. > > > > It shouldn't, and if it did things would break all over the place. > > Suppose you have two compilers, one of which is used to compile a > > program, > > and the other of which is used to compile a library used by the program. > > Now suppose the program passes a pointer to a structure (say, a FILE *) > > to > > the library. If the two compilers use different algorithms to pad > > structure members, guess what happens? Boom. > > Actually, I was referring to things such as: > > struct tag { > char type; > uint_32 value; > } *s; > > char map[32]; should be unsigned char. > > /* load map with some data */ > > s = (struct tag *)map; > > But your point about compilers is a valid one; I don't know about > POSIX (as someone else commented), but in general compilers adopt > the same alignment scheme for a particular architecture. After all, > the architecture is what requires certain alignments anyway :) > > -- Quension > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From achurch at achurch.org Wed Feb 27 09:11:04 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] GCC3 Message-ID: <3c7c2442.11224@achurch.org> >> Actually, I was referring to things such as: >> >> struct tag { >> char type; >> uint_32 value; >> } *s; >> >> char map[32]; >should be unsigned char. Good God, man, don't waste my time with such trivialities. Besides which it doesn't make a whit of difference in this case anyway. --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Tue Feb 26 16:53:00 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] GCC3 In-Reply-To: <3c7c2442.11224@achurch.org> Message-ID: On Wed, 27 Feb 2002, Andrew Church wrote: > >> Actually, I was referring to things such as: > >> > >> struct tag { > >> char type; > >> uint_32 value; > >> } *s; > >> > >> char map[32]; > >should be unsigned char. > > Good God, man, don't waste my time with such trivialities. Besides > which it doesn't make a whit of difference in this case anyway. You're right, sorry > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From achurch at achurch.org Wed Feb 27 22:08:00 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Services 5.0a21 Slipping through the AUTH net... Message-ID: <3c7cdb79.14405@achurch.org> >On Feb 15th 2044 GMT, a nickname was registered on Services 5.0.a20. About >an hour later, services was upgraded to 5.0.a21. From log information, this >nickname has never used the AUTH command but is now being successfully >identified for. I will be performing continous tests to see if restarting >services/segfaults have any bearing on this, but tests so far have been >unable to reproduce the problem. This is probably related to the problem you mentioned about Services admins/opers disappearing, since both the authcode field and OperServ privilege level are stored in the nickgroup extension structure. >A few suggestions that would help tracking this problem and to enhance the >available listing features: > >1) Provide the AUTH status field for nicknames in the httpd module. >2) In a full list of nicknames (both within IRC and in http) add an >indicator of non-AUTH status similar to that of SUSPENDED/FORBIDDEN. >3) Add a view option to /ns list to view nicknames that are in the awaiting >AUTH status. All good ideas, and I'll see about adding them. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Thu Feb 28 00:23:48 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Auth Module - SETAUTH command suggestion Message-ID: <3c7cfa16.33420@achurch.org> >One thing that seems to be missing from the AUTH modules, is the ability to >put a nick into auth mode. The reasons that I feel this command is required >are listed below: Good idea, added (SETAUTH). --Andrew Church achurch@achurch.org http://achurch.org/ >1) We have a number of nicknames that were registered before the >introduction of the AUTH modules, so although we have always insisted on >email addresses, not all are verified. Some are obviously made up purely >for the purpose of registration. At present, the only guaranteed solution >is to drop the nick name and force it to be registered under the new AUTH >system. However, since this would be more than a minor inconvenience for >some users as it dropped channels, linked nicks and access rights in >channels, it is something that I would prefer a more user friendly solution >to. For anyone changing over from an older version of services or a >competitor without nickname validation, a SETAUTH feature would be useful >in validating existing registrations. > >2) Services Admins are able to change the email address of a user without >triggering the AUTH module. Unless the Services Admin manually verifies the >address, or knows the address to be valid, this creates a situation where >an email address can be entered into a new database which is not validated. >A SETAUTH command would address this for an email address which cannot be >verfied manually. This could be acheived by always triggering AUTH on set >email, but since there are cases where auth may not be required, SETAUTH >provides this as an option. > >3) When importing users from another services database, for example during >a network merge, again there is the potential for importing unvalidated >addresses. SETAUTH would allow a Services Admin to flag nicknames as >unauthorised so that validation could occur. Again, this could be >automatically flagged during import, but as with 2, I think a command is >better to make the AUTH optional. > >One issue with the command, is it would likely require an unlimited AUTH >time (until normal nick expiration at least) since in scenario 3 above, it >is possible that not all users would log on before the main AUTH expiry >time kicked in. It seems that the SET EMAIL authorisation already works in >this manner so this may be trivial to address. > > >-- >Mark. > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Thu Feb 28 00:28:06 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Services 5.0 alpha 23 released Message-ID: <3c7d117c.60145@achurch.org> Okay, the real next alpha is done now. Not much to mention, basically just the stuff that's been gone over in the ML recently plus a couple other things I'd noticed (including the 4.5.39 fix). And yes, I did remember to update the index page this time. Changes in version 5.0 alpha 23 ------------------------------- 2002/02/28 a23 Added SETAUTH command to nickserv/mail-auth module. Suggested by Mark Hetherington 2002/02/28 Fix security hole allowing users to be considered "identified" for nicks with an authorization code set. 2002/02/27 Added options to NickServ LIST and httpd/dbaccess to filter by and display nickname authorization codes. Suggested by Mark Hetherington 2002/02/27 Added options to nickname/channel lists (httpd/dbaccess) to display only forbidden, suspended, or non-expiring items. 2002/02/27 Added support for GET query strings in HTTP server. 2002/02/26 Fixed bug resulting in "not identified" after nickname registration. Reported by Ben Goldstein 2002/02/26 Prevent use of the NickServ UNLINK command on self. 2002/02/26 Fixed bug causing autokick masks to get corrupted on add. Reported by Mark Hetherington 2002/02/26 Fixed bug causing database load errors on certain types of bad data. Reported by Mark Hetherington --Andrew Church achurch@achurch.org http://achurch.org/ From mark at ctcp.net Wed Feb 27 16:36:22 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Services 5.0 +S user bug Message-ID: <21025.193.237.130.98.1014856582.squirrel@secure.uksolutions.co.uk> Just installed 5.0a23 and all went well apart from the +S user problem still occuring. In the echo channel for our +S pseudo client, the following was observed this time (xxx to avoid network spamming): [in channel] *** services.xxx.xxx changes topic to 'Stats Channel' *** ChanServ sets mode: -o dearnapst *** ChanServ sets mode: +b *!?@* *** StatServ was kicked by ChanServ (@????=y????q) *** StatServ (stats@stats.xxx.xxx) has joined #stats *** stats.ctcp.net sets mode: +o StatServ *** ChanServ sets mode: +Rlk 135707936 H? [services.log] IRC Services 5.0a23 starting up database/version4: Ignoring nickgroup 0 (bug in previous versions) httpd/main: Listening on 217.10.142.131:12701 operserv/sline: warning: client IP addresses not available with this IRC server PANIC! buffer = :dearnapst ! chanserv :op #stats dearnapst >From the channel log, something is corrupted by the presence of the +S client in a channel (hence the odd key and limit), but from the services log, it is the first command given to services by a user which generates the segfault. After the segfault and removal of the +S psuedo client, services was restarted and the following observed: *** services.xxx.xxx changes topic to 'Stats Channel' *** ChanServ sets mode: -k H? *** ChanServ sets mode: -l *** StatServ (stats@stats.xxx.xxx) has joined #stats *** stats.xxx.xxx sets mode: +o StatServ *** StatServ sets mode: +a StatServ *** ChanServ sets mode: -ooa StatServ StatServ StatServ So services is overriding commands given by a +S client. Hope something in there is useful in tracking this one down. -- Mark. CTCP Networks. From mark at ctcp.net Wed Feb 27 16:44:43 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Services 5.0a23 - Note for upgraders with respect to Nickgroup 0 bug Message-ID: <21028.193.237.130.98.1014857083.squirrel@secure.uksolutions.co.uk> The new version will correctly detect the bug wrt nickgroup but with every database write will continue to log the fact that it still exists in the in RAM copy. To fix this problem completely, you must start version 5.0a23, then shut down (/os shutdown or kill -TERM pid). This will update the databases on disk and remove the erroneous entry from RAM. -- Mark. From jollino at sogno.net Thu Feb 28 02:12:37 2002 From: jollino at sogno.net (Jollino) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] How does XML from services look like? Message-ID: Hi there, I've been reading about the new XML export type that's going to be included in 5.0, but I was wondering.. how does it actually look like? I mean, what kind of tags is it going to use? Could anyone give me any example of it? Thanks in advance ;) -- Jollino [jollino at sogno dot net - jollino at chieti dot ch] IRC Operator on irc.discussioni.org Webmaster of http://www.sogno.net and related services Active content provider of http://www.chieti.ch Italian Dreamer no. 2305 (www.italiandreamers.net) Longe vivu la verda stelo de Esperanto! Eg atart agap?en... From achurch at achurch.org Thu Feb 28 19:17:49 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] How does XML from services look like? Message-ID: <3c7e03eb.77477@achurch.org> >Hi there, >I've been reading about the new XML export type that's going to be >included in 5.0, but I was wondering.. how does it actually look like? I > >mean, what kind of tags is it going to use? >Could anyone give me any example of it? I'm working on documentation for this, which hopefully (ha!) should be ready within the next alpha or two. --Andrew Church achurch@achurch.org http://achurch.org/ From rg at tcslon.com Thu Feb 28 06:02:13 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Another database bug (a.k.a bang goes my nicks.db again ;) In-Reply-To: <21028.193.237.130.98.1014857083.squirrel@secure.uksolutions.co.uk> Message-ID: [Feb 28 13:59:42 2002] database/version4: BUG: nickgroup with ID 0 found during write (skipping) This is not actually causing much of a problem with services, it's just filling up the logs and causing madness in the xml-export module. I'm afraid I can't identify when it started exactly. I'm going to try to reload the db from what I can salvage of the XML export.. Russ Garrett (russ@garrett.co.uk) From mark at ctcp.net Thu Feb 28 06:08:31 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Another database bug (a.k.a bang goes my nicks.db again ;) Message-ID: <1209.195.92.144.170.1014905311.squirrel@secure.uksolutions.co.uk> > Russell Garrett wrote > [Feb 28 13:59:42 2002] database/version4: BUG: nickgroup with ID 0 > found during write (skipping) > > This is not actually causing much of a problem with services, it's > just filling up the logs and causing madness in the xml-export > module. I'm afraid I can't identify when it started exactly. I'm > going to try to reload the db from what I can salvage of the XML > export.. This is not a bug. I posted about this last night explaining that it could happen and how to "fix" it. Just shutdown services and bring them back online and your database will be fixed. -- Mark. From rg at tcslon.com Thu Feb 28 06:13:15 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Another database bug (a.k.a bang goes my nicks.db again ;) In-Reply-To: <1209.195.92.144.170.1014905311.squirrel@secure.uksolutions.co.uk> Message-ID: > This is not a bug. I posted about this last night > explaining that it could > happen and how to "fix" it. Just shutdown services and > bring them back > online and your database will be fixed. I've tried this about three times, and it still shows the error. Any ideas? Russ From mark at ctcp.net Thu Feb 28 06:26:58 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Another database bug (a.k.a bang goes my nicks.db again ;) Message-ID: <1261.195.92.144.170.1014906418.squirrel@secure.uksolutions.co.uk> Russell Garrett wrote: > > This is not a bug. I posted about this last night > > explaining that it could > > happen and how to "fix" it. Just shutdown services and > > bring them back > > online and your database will be fixed. > > I've tried this about three times, and it still shows the error. Any > ideas? That's odd. Do you get an error during startup of services when it first reads the databases? e.g. "IRC Services 5.0a23 starting up database/version4: Ignoring nickgroup 0 (bug in previous versions)" Or are you just getting the "database/version4: BUG: nickgroup with ID 0 found during write (skipping)" error? -- Mark. From rg at tcslon.com Thu Feb 28 06:40:42 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Another database bug (a.k.a bang goes my nicks.db again ;) In-Reply-To: <1261.195.92.144.170.1014906418.squirrel@secure.uksolutions.co.uk> Message-ID: > > I've tried this about three times, and it still shows > the error. Any > > ideas? > > That's odd. Do you get an error during startup of services > when it first > reads the databases? I don't get a read error: [Feb 28 14:32:23 2002] IRC Services 5.0a23-PhaseNet1 starting up [Feb 28 14:32:24 2002] httpd/main: Listening on :8080 [Feb 28 14:32:24 2002] user: New maximum user count: 1 [Feb 28 14:32:24 2002] user: New maximum user count: 2 [Feb 28 14:32:24 2002] user: New maximum user count: 3 [Feb 28 14:32:24 2002] user: New maximum user count: 4 [Feb 28 14:32:24 2002] user: New maximum user count: 5 [Feb 28 14:32:24 2002] protocol/bahamut: WARNING: missing IP address for new nick StatServ [Feb 28 14:32:24 2002] user: New maximum user count: 6 [Feb 28 14:37:26 2002] database/version4: BUG: nickgroup with ID 0 found during write (skipping) ... The "New maximum user count" messages come up every time though, which is a bit odd. The Statserv thing is because I'm using a seperate statserv which isn't fully compliant with the bahamut 1.4.25 protocol (must add that at some point), and my PhaseNet1 patch goes nowhere near any database or nickserv stuff (at the moment), before you ask :). All the permissions on the databases are correct. Russ Garrett (russ@garrett.co.uk) From achurch at achurch.org Thu Feb 28 23:55:21 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Another database bug (a.k.a bang goes my nicks.db again ;) Message-ID: <3c7e4513.00764@achurch.org> >> > I've tried this about three times, and it still shows >> the error. Any >> > ideas? >> >> That's odd. Do you get an error during startup of services >> when it first >> reads the databases? > >I don't get a read error: Well, that probably means the bug that creates the bad nickgroup entry is still sitting around somewhere, biding its time until it jumps up and eats all of us alive. Err, maybe not, but I'll take a look anyway. --Andrew Church achurch@achurch.org http://achurch.org/ From mark at ctcp.net Thu Feb 28 07:02:46 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Another database bug (a.k.a bang goes my nicks.db again ;) Message-ID: <1332.195.92.144.170.1014908566.squirrel@secure.uksolutions.co.uk> > Russell Garrett wrote > The "New maximum user count" messages come up every time though, > which is a bit odd. That is odd. Maybe your stats.db file is corrupt? Just rebooted our services to make sure I don't get problems with the user counts and I don't, but it does seem that I am getting the "database/version4: BUG: nickgroup with ID 0 found during write (skipping)" error again now despite it not happening after the reboot last night. Going to track back through the log, see if I can find anything odd. I wouldn't worry too much about it other than increased log size since no read error on boot means your nick database is not lost. I have been running with this problem for a couple weeks before services was able to detect it without suffering too many problems and I guess a24 will fix this one for good. Seems the workaround I posted last night must just have been a lucky fluke. -- Mark. From rg at tcslon.com Thu Feb 28 07:06:18 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Another database bug (a.k.a bang goes my nicks.db again ;) In-Reply-To: <3c7e4513.00764@achurch.org> Message-ID: > Well, that probably means the bug that creates the > bad nickgroup entry > is still sitting around somewhere, biding its time until > it jumps up and > eats all of us alive. Eek :) Just to say that debugmode isn't providing any more clues - and, if it's any help, this is the (probably related) bug I was about to report originally - chunks are missing out of the XML export: Russ[away] 0 ~rg@apollo.final-conflict.net ~rg@apollo.final-conflict.net 0 [channel founder pass] [description] 1014809705 ... Nickinfo here seen running straight into a channelinfo - the bits it misses out are different every restart. With regards to the statserv stuff - I have a feeling those "New User Count" messages come up every time services starts up without the statserv module loaded - I might have a go moving from my heavily-hacked copy of OperStats to a modified StatServ module if I'm bored :). Russ Garrett From achurch at achurch.org Fri Mar 1 09:53:51 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] Services 5.0 +S user bug Message-ID: <3c7ed153.02062@achurch.org> >Just installed 5.0a23 and all went well apart from the +S user problem >still occuring. > >In the echo channel for our +S pseudo client, the following was observed >this time (xxx to avoid network spamming): > >[in channel] >*** services.xxx.xxx changes topic to 'Stats Channel' >*** ChanServ sets mode: -o dearnapst >*** ChanServ sets mode: +b *!.@* >*** StatServ was kicked by ChanServ (...) Found and fixed, I think. --Andrew Church achurch@achurch.org http://achurch.org/ From mark at ctcp.net Sat Mar 2 18:31:16 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] The case of the non-existant user Message-ID: <1599.193.237.130.98.1015122676.squirrel@secure.uksolutions.co.uk> Odd scenario, and I am not sure whether services should/could support it, but since it seems to be the cause of a particular chain of log messages, it could well be something for the FAQ if it is not something that should/could be supported. A user logs on to IRC, identifies to NickServ then joins a channel that he has auto-op rights on. He then immediately changes nickname to another nickname (registered or not). Services logs the fact that a mode change was requested for a nonexistant user. The nicknames in the example are not linked. >From logs: [channel] [14:38] Damon (damon@xxxx) joined #channel. [14:38] Nick change: Damon -> Memphis [Services.log] [Mar 02 14:38:59 2002] nickserv/main: Damon!damon@xxxx identified for nick Damon [Mar 02 14:38:59 2002] channel: MODE #channel +o for nonexistent user Damon [Mar 02 14:39:13 2002] nickserv/main: Memphis!damon@xxxx identified for nick Memphis I have not managed to be quick enough to reproduce this 100% hence my lack of knowledge on whether this affects linked nicknames, but in my defence it is kinda late here and the timing is somewhat critical :). I suspect that it may apply to linked nicknames as well but assuming that services logs an error returned by the attempt to set a mode, I imagine the linked nick would trigger another test which may make mitigate the problem from a user's perspective. I guess it would quite complex for services to track the user and supress the error as well as leading to potential circular lockup, so maybe just one for the FAQ. -- Mark. From achurch at achurch.org Sun Mar 3 12:10:15 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] The case of the non-existant user Message-ID: <3c819472.07350@achurch.org> This shouldn't happen; if it does, it's either a Services bug or an ircd bug. --Andrew Church achurch@achurch.org http://achurch.org/ >Odd scenario, and I am not sure whether services should/could support it, >but since it seems to be the cause of a particular chain of log messages, >it could well be something for the FAQ if it is not something that >should/could be supported. > >A user logs on to IRC, identifies to NickServ then joins a channel that he >has auto-op rights on. He then immediately changes nickname to another >nickname (registered or not). Services logs the fact that a mode change was >requested for a nonexistant user. The nicknames in the example are not >linked. > >>From logs: > >[channel] >[14:38] Damon (damon@xxxx) joined #channel. >[14:38] Nick change: Damon -> Memphis > >[Services.log] >[Mar 02 14:38:59 2002] nickserv/main: Damon!damon@xxxx identified for nick >Damon >[Mar 02 14:38:59 2002] channel: MODE #channel +o for nonexistent user Damon >[Mar 02 14:39:13 2002] nickserv/main: Memphis!damon@xxxx identified for >nick Memphis > >I have not managed to be quick enough to reproduce this 100% hence my lack >of knowledge on whether this affects linked nicknames, but in my defence it >is kinda late here and the timing is somewhat critical :). I suspect that >it may apply to linked nicknames as well but assuming that services logs an >error returned by the attempt to set a mode, I imagine the linked nick >would trigger another test which may make mitigate the problem from a >user's perspective. > >I guess it would quite complex for services to track the user and supress >the error as well as leading to potential circular lockup, so maybe just >one for the FAQ. > > >-- >Mark. > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From rg at tcslon.com Sun Mar 3 01:33:48 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] The case of the non-existant user In-Reply-To: <3c819472.07350@achurch.org> Message-ID: > This shouldn't happen; if it does, it's either a > Services bug or an > ircd bug. Certainly leaving your options open there ;) Russ From wetrixz at hotmail.com Tue Mar 5 11:14:47 2002 From: wetrixz at hotmail.com (Le Merveilleux Jason) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] need help with ircservices with UnrealIRCD 3.2 Message-ID: An HTML attachment was scrubbed... URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20020305/a5b09c79/attachment.htm From rg at tcslon.com Tue Mar 5 12:14:07 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:17 2004 Subject: [IRCServices Coding] need help with ircservices with UnrealIRCD 3.2 In-Reply-To: Message-ID: >hi everybody, im oXez >i installed UnrealIRCD and IRCServices.4.5.39 and i >have a little question... >when im logging to the services (/operserv su (password)) i want >that when i /whois myself i can see: oXez is a Services Root This should really go to the ircservices@ircservices.za.net list, not the coding one. It's really an ircd problem, not a services query. From my limited knowledge of Unreal3.2 (before I was converted to Bahamut ;) I'd say that there is no automatic "is a Services Root" statement (I may be wrong). It would require modifications on the ircd (hmmm...bloat) or in services (in the form of an SWHOIS command - not standard with what happens with other user states though). Russ Garrett (russ@garrett.co.uk) From kfiresun at ix.netcom.com Tue Mar 5 12:19:46 2002 From: kfiresun at ix.netcom.com (Kelmar K. Firesun) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] need help with ircservices with UnrealIRCD 3.2 References: Message-ID: <000901c1c483$180a1b80$0200000a@stormkeepers.com> ----- Original Message ----- From: "Russell Garrett" To: Sent: Tuesday, March 05, 2002 2:14 PM Subject: RE: [IRCServices Coding] need help with ircservices with UnrealIRCD 3.2 > >hi everybody, im oXez > >i installed UnrealIRCD and IRCServices.4.5.39 and i > >have a little question... > >when im logging to the services (/operserv su (password)) i want > >that when i /whois myself i can see: oXez is a Services Root > > This should really go to the ircservices@ircservices.za.net list, not > the coding one. > > It's really an ircd problem, not a services query. From my limited > knowledge of Unreal3.2 (before I was converted to Bahamut ;) I'd say > that there is no automatic "is a Services Root" statement (I may be > wrong). It would require modifications on the ircd (hmmm...bloat) or > in services (in the form of an SWHOIS command - not standard with > what happens with other user states though). > Nope you are correct. The Services Administrator tag that some daemons have, noteably Bahamut & DreamForge, use a +Aa user modes. Thus when someone does a /whois on a +Aa user they get the "Is a Server/Services Admin" message. Services in of itself does not process the /whois command. Kelmar K. Firesun (IRL: Bryce Simonds) Acting Admin: dream.esper.net From dwd at buli.net Sat Mar 9 03:26:35 2002 From: dwd at buli.net (dwd@buli.net) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Restart failed: No such file or directory, latest ircservices-4.3.3-daylight Message-ID: Hi! Please help me! 1. [Mar 09 12:18:31 2002] OperServ: dwd: set debug on [Mar 09 12:18:31.700000 2002] Debug mode activated [Mar 09 12:18:31.700000 2002] debug: Sent: :OperServ NOTICE dwd :Services is now in debug mode. [Mar 09 12:18:48.780000 2002] debug: Received: :dwd PRIVMSG OperServ@services.datachat.net :restart [Mar 09 12:18:49.770000 2002] OperServ: dwd: restart [Mar 09 12:18:49.770000 2002] Received SIGHUP, restarting. [Mar 09 12:18:49.770000 2002] debug: Running expire routines [Mar 09 12:18:49.770000 2002] debug: Saving databases [Mar 09 12:18:49.770000 2002] Restarting [Mar 09 12:18:49.820000 2002] debug: Sent: :services.datachat.net SQUIT services.datachat.net :RESTART command received from dwd [Mar 09 12:18:49.820000 2002] Restart failed: No such file or directory Version: (351) ircservices-4.3.3-daylight(9) services.datachat.net -- build #17, compiled Jul 30 2000 15:03:36 Path: D:\win32-daylight\Services.exe Why? 2. Where can we download the latest version from (Win32 version)? Thx! -- dwd ICQ#108548590 From andrewk at isdial.net Sat Mar 9 03:35:11 2002 From: andrewk at isdial.net (Andrew Kempe) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Restart failed: No such file or directory, latest ircservices-4.3.3-daylight References: Message-ID: <00ad01c1c75e$79bfa2e0$9c011ac4@africa.didata.local> This mailing list does NOT support the version of IRC Services you're trying to use. Please contact its author for support or download the original version of IRC Services from ftp.ircservices.za.net - which we will support. Regards, Andrew ----- Original Message ----- From: To: ; Sent: Saturday, March 09, 2002 1:26 PM Subject: [IRCServices Coding] Restart failed: No such file or directory, latest ircservices-4.3.3-daylight Hi! Please help me! 1. [Mar 09 12:18:31 2002] OperServ: dwd: set debug on [Mar 09 12:18:31.700000 2002] Debug mode activated [Mar 09 12:18:31.700000 2002] debug: Sent: :OperServ NOTICE dwd :Services is now in debug mode. [Mar 09 12:18:48.780000 2002] debug: Received: :dwd PRIVMSG OperServ@services.datachat.net :restart [Mar 09 12:18:49.770000 2002] OperServ: dwd: restart [Mar 09 12:18:49.770000 2002] Received SIGHUP, restarting. [Mar 09 12:18:49.770000 2002] debug: Running expire routines [Mar 09 12:18:49.770000 2002] debug: Saving databases [Mar 09 12:18:49.770000 2002] Restarting [Mar 09 12:18:49.820000 2002] debug: Sent: :services.datachat.net SQUIT services.datachat.net :RESTART command received from dwd [Mar 09 12:18:49.820000 2002] Restart failed: No such file or directory Version: (351) ircservices-4.3.3-daylight(9) services.datachat.net -- build #17, compiled Jul 30 2000 15:03:36 Path: D:\win32-daylight\Services.exe Why? 2. Where can we download the latest version from (Win32 version)? Thx! -- dwd ICQ#108548590--------------------------------------------------------------- --- To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From mark at ctcp.net Sun Mar 10 14:02:03 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Qline avoidance bug in /ns link nickname Message-ID: <21024.193.237.130.98.1015797723.squirrel@secure.uksolutions.co.uk> The protection of guest nicknames and qline protection within SQLINES and IRCD.CONF QLines can be circumvented via the use of the '/ns link' command: nickserv/main: nick!user@host identified for nick Nick nickserv/link: nick!user@host linked nick oper to Nick nickserv/link: nick!user@host linked nick ircop to Nick nickserv/link: nick!user@host linked nick admin to Nick nickserv/link: nick!user@host linked nick Guest0 to Nick nickserv/link: nick!user@host linked nick Guest1 to Nick nickserv/link: nick!user@host linked nick Guest2 to Nick ... etc I imagine protecting guest nicks will be a trivial matter of adding the same check as used in '/ns register' to the '/ns link' command. Protecting against standard QLines would like;y prove more complex. I am happy to move/add all QLines to SQLines if there is a way for services to support protection from registration when used in this manner. Although the QLines will probably still protect against these registered names being actually used, they will allow the primary nick to receive memos to these banned nicknames and I guess there is the potential for further problems. -- Mark. From mark at ctcp.net Sun Mar 10 14:36:49 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] channel: MODE #channel -b *!*@host: ban not found Message-ID: <21024.193.237.130.98.1015799809.squirrel@secure.uksolutions.co.uk> Services v 5.0a23 Not sure exactly on the causes of this one yet, but logs indicate that something is wrong so am reporting it in case it is something obvious while I research further. Basically, whenever ChanServ sets +b*!user@host in a channel in response to an autokick entry, the subsequent attempt to remove the ban from a channel results in services logging: channel: MODE #channel -b *!*@host: ban not found The bans are usually removed automatically by channel bots to keep the channel ban list manageable so I am assuing there is some discrepancy between the original announcement by Chanserv of the ban it has set and the actual ban it sets or Chanserv incorrectly parsing the /mode -b. >From channel: DOS_BOT_77 (~username@ctcp-35163.cas-lon.golden.net) joined #channel. #channel: mode change '+b dos_bot*!*@*' by ChanServ!services@ctcp.net DOS_BOT_77 kicked from #channel by ChanServ: User has been banned from the channel .... (#channel) Channel ban on dos_bot*!*@* expired. #channel: mode change '-b dos_bot*!*@*' by Bot services.log: channel: MODE #channel -b dos_bot*!*@*: ban not found -- Mark. CTCP Networks. From achurch at achurch.org Mon Mar 11 13:46:41 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Qline avoidance bug in /ns link nickname Message-ID: <3c8c3b02.64141@achurch.org> Fixed with respect to guest nicks. I'll work on the SQLINE stuff later. --Andrew Church achurch@achurch.org http://achurch.org/ >The protection of guest nicknames and qline protection within SQLINES and >IRCD.CONF QLines can be circumvented via the use of the '/ns link' command: > >nickserv/main: nick!user@host identified for nick Nick >nickserv/link: nick!user@host linked nick oper to Nick >nickserv/link: nick!user@host linked nick ircop to Nick >nickserv/link: nick!user@host linked nick admin to Nick >nickserv/link: nick!user@host linked nick Guest0 to Nick >nickserv/link: nick!user@host linked nick Guest1 to Nick >nickserv/link: nick!user@host linked nick Guest2 to Nick > >... etc > >I imagine protecting guest nicks will be a trivial matter of adding the >same check as used in '/ns register' to the '/ns link' command. Protecting >against standard QLines would like;y prove more complex. I am happy to >move/add all QLines to SQLines if there is a way for services to support >protection from registration when used in this manner. > >Although the QLines will probably still protect against these registered >names being actually used, they will allow the primary nick to receive >memos to these banned nicknames and I guess there is the potential for >further problems. > >-- >Mark. > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Mon Mar 11 14:50:19 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Services 5.0 alpha 24 released Message-ID: <3c8c4610.01457@achurch.org> Services 5.0 alpha 24 is out at the usual place. I'm afraid that between much work and much stress I haven't been able to make too much progress lately, so please be patient for a bit longer. Version 5.0 alpha 24 -------------------- 2002/03/11 Fixed bug in LINK allowing guest nicks to be registered. Reported by Mark Hetherington 2002/03/01 Fixed crash with Unreal and +S clients. Reported by Mark Hetherington 2002/02/28 Optimized processing for MSNotifyAll with MemoServ SEND. 2002/02/28 The main OperServ module can no longer be unloaded via the OperServ REHASH command (doing so would cause a crash). 2002/02/28 Fixed a potential crash if databases got corrupted. 2002/02/28 Fixed CSRestrictDelay option (finally!) to not give free rides to users who would be unprivileged anyway, and enabled it by default (with a timeout of 15 seconds). --Andrew Church achurch@achurch.org http://achurch.org/ From eengin at talesoft.de Mon Mar 11 17:05:20 2002 From: eengin at talesoft.de (Ekim Engin) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Suggestion for nickserv list Message-ID: <006f01c1c961$fb72a5d0$092a14ac@hadiko.de> Hi all, it looks like a good idea to make sadmins list nicks by their emails like: /ns list *@talesoft.de MAIL -NickServ- Ekim eengin@talesoft.de -NickServ- ! Talesin eengin@talesoft.de Greets Ekim "Talesin" Engin TTnet IRC Sorumlusu http://www.ttchat.net - irc://irc.ttnet.net.tr PGP-Fingerprint: 8627 180C 1397 34FB 6BB0 8B65 9CBF 8ED5 456C 48F9 --- Chat begins as it ends - without reason From achurch at achurch.org Tue Mar 12 12:58:17 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Re: [IRCServices] IRC Services 5.0a24 segfault on startup Message-ID: <3c8d7cf4.03755@achurch.org> If you can track this down it would be appreciated. Oh, and wrong list. --Andrew Church achurch@achurch.org http://achurch.org/ >Seems the bug regarding the 0 nickgroup that had some ignore code to in >version 5.0a23 crashes the latest version of services on startup. From >services.log: > >IRC Services 5.0a24 starting up >database/version4: PANIC: add_nickgroupinfo: ngi->id==0 > >-- >Mark. > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices From mark at ctcp.net Tue Mar 12 13:27:24 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Re: [IRCServices] IRC Services 5.0a24 segfault on startup Message-ID: <21032.193.237.130.98.1015968444.squirrel@secure.uksolutions.co.uk> > If you can track this down it would be appreciated. The crash was much easier to find that I thought. The function add_nickgroupinfo raises the SEGFAULT "on purpose" if(ngi->id==0) { module_log("PANIC: add_nickgroupinfo: ngi->id==0");raise(/*SIGSEGV*/11); } As to where this self resurrecting nickgroup is, well an XML output from the httpd shows: 0 list help 0 0 0 -2147483648 0 -1 32767 -1 0 list and help are forbidden nicks. When they were first forbidden, I believe they had actually been registered to a user. Since this happened so long ago, I cannot be 100% sure on that. As a suggestion, maybe forbidden nicks could also store the date/time of the forbid and display it through /ns list forbidden and the httpd since it would help when tracking oddities like this one. I have archived services log files but since they are archived by date, it would take a long time to track this without an indication. How it gets written to disk, I have no idea since version 5.0a23 should skip the write and logs that it does so. Since the XML dump does not report all nicknames, I am unable to find out if any other entries have a nickgroup of 0. I am going to try dropping the nicknames that have reported an ngi->id of zero and seeing if that solves the problem completely and will report back once more is known. > Oh, and wrong > list. Sorry, I thought I had sent it to it to the coding list. -- Mark. From mark at ctcp.net Tue Mar 12 14:19:29 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Re: [IRCServices] IRC Services 5.0a24 segfault on startup Message-ID: <21037.193.237.130.98.1015971569.squirrel@secure.uksolutions.co.uk> Dropping the nicknames does not result in the removal of the nickgroup 0 entries. Reregistering them, means two nickgroups now have a list nickname. Seems that nickgroup is stuck there :( Mark. > -----Original Message----- > From: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net]On Behalf Of Mark > Hetherington > Sent: 12 March 2002 21:27 > To: ircservices-coding@ircservices.za.net > Subject: RE: [IRCServices Coding] Re: [IRCServices] IRC Services 5.0a24 > segfault on startup > > > > If you can track this down it would be appreciated. > > The crash was much easier to find that I thought. The function > add_nickgroupinfo raises the SEGFAULT "on purpose" > if(ngi->id==0) > { > module_log("PANIC: add_nickgroupinfo: ngi->id==0");raise(/*SIGSEGV*/11); > } > > As to where this self resurrecting nickgroup is, well an XML output from > the httpd shows: > > > 0 > > list > help > > 0 > > 0 > 0 > -2147483648 > 0 > -1 > 32767 > -1 > > > > > > > > 0 > > > > > > list and help are forbidden nicks. When they were first forbidden, I > believe they had actually been registered to a user. Since this > happened so > long ago, I cannot be 100% sure on that. > > As a suggestion, maybe forbidden nicks could also store the date/time of > the forbid and display it through /ns list forbidden and the > httpd since it > would help when tracking oddities like this one. I have archived services > log files but since they are archived by date, it would take a > long time to > track this without an indication. > > How it gets written to disk, I have no idea since version 5.0a23 should > skip the write and logs that it does so. > > Since the XML dump does not report all nicknames, I am unable to find out > if any other entries have a nickgroup of 0. > > I am going to try dropping the nicknames that have reported an ngi->id of > zero and seeing if that solves the problem completely and will > report back > once more is known. > > > > Oh, and wrong > > list. > > Sorry, I thought I had sent it to it to the coding list. > > -- > Mark. > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From mark at ctcp.net Tue Mar 12 14:38:43 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Services 5.0a24 /ns unlink nick force text error Message-ID: <21038.193.237.130.98.1015972723.squirrel@secure.uksolutions.co.uk> When force unlinking a nickname, an erroneous nickname results in the following error message: /ns unlink Guest14 force -NickServ- Nick Guest14 isn't linked to your nick. The message ought to be something along the lines of: -NickServ- Nick Guest14 isn't linked to any nickname. -- Mark. From mark at ctcp.net Tue Mar 12 14:52:19 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Solution to the nickgroup 0 problem. Message-ID: <21025.193.237.130.98.1015973539.squirrel@secure.uksolutions.co.uk> After much fiddling, I have finally both removed the 0 nickgroups from my database and upgraded to services 5.0a24 :) For anyone affected by this bug, the following steps should remove the erroneous names and allow you to upgrade to the new version: 1) Make sure you are running version 5.0a23 which has code to not write nickgroup 0 nicknames to the database file. 2) Identify those nicknames with a nickgroup of 0. I suggest using the httpd module and the XML download feature. IME this does not display all nicknames in the database, but nickgroup 0 seemed to always be the first entry and always list correctly. 3) Drop the nicknames identified as being of nickgroup 0. In my case they were forbidden nicks so this affected no users. If the nickname is valid, it is likely not working correctly so although you might want to warn the users affected, they are likely not using those names anyway. 4) Shutdown services with /os shutdown so it saves the new database. 5) Restart Services 5.0a23, ensuring you do not get any warnings in services.log for your current database (both on startup and on first write which you can force with an /os update). Also check that the XML download does not report any more nickgroup zero entries. If any remain, goto 2 and repeat until you have cleared them out. 6) Backup your databases. This is important. Even though the startup fails, I had problems with completely trashed databases when services segfaulted. 7) Install Services 5.0a24 and start them. If they bootup, the nickgroup bug is now cured. If not, restore your backup and return to version 5.0a23 and goto 2 to find the erroneous entry. I know at least one other person on the list has problems with this bug, so HTH. -- Mark. From mark at ctcp.net Tue Mar 12 14:54:19 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] 5.0a24, /ns link guestxxx bug Message-ID: <21030.193.237.130.98.1015973659.squirrel@secure.uksolutions.co.uk> The bug fix for this is not working. >From services.log: IRC Services 5.0a24 starting up nickserv/link: nick!user@host linked nick guest0 to nick -- Mark. From mark at ctcp.net Tue Mar 12 15:31:53 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] 5.0a24 and +S clients Message-ID: <21027.193.237.130.98.1015975913.squirrel@secure.uksolutions.co.uk> This is much better in 5.0a24 and if a +S client is on the network when Services joins, it correctly ignores the client and does not change it's modes. :) However, if the +S client joins after services is running, services will enforce modes against it: In channel: *** StatServ (stats@stats.xxxxx.net) has joined #stats *** stats.xxxxx.net sets mode: +o StatServ *** StatServ sets mode: +a StatServ *** ChanServ sets mode: -ooa StatServ StatServ StatServ In services.log: unknown message from server (:StatServ n StatServ +Sq) Andrew, anything specific I should look for that would help nail this one down? I am guessing that services misses the /mode +S issued by StatServ, and the error message in the log suggests this is what is happening. I am going to check the StatServ startup code now to see exactly what it thinks it is sending. -- Mark. From achurch at achurch.org Wed Mar 13 14:14:16 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Re: [IRCServices] IRC Services 5.0a24 segfault on startup Message-ID: <3c8ee07c.04774@achurch.org> >> If you can track this down it would be appreciated. > >The crash was much easier to find that I thought. The function >add_nickgroupinfo raises the SEGFAULT "on purpose" Yes, I know that because I added it. :P I was hoping for a backtrace or some other hint of why the nickgroup was being added in the first place. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Wed Mar 13 14:39:49 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Re: [IRCServices] IRC Services 5.0a24 segfault on startup Message-ID: <3c8ee6f0.10360@achurch.org> >>> If you can track this down it would be appreciated. >> >>The crash was much easier to find that I thought. The function >>add_nickgroupinfo raises the SEGFAULT "on purpose" > > Yes, I know that because I added it. :P I was hoping for a backtrace >or some other hint of why the nickgroup was being added in the first place. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ Okay, I think I've found it--try the following patch: --- modules/database/version4.c 1 Mar 2002 01:49:24 -0000 2.81 +++ modules/database/version4.c 13 Mar 2002 05:25:18 -0000 2.82 @@ -277,7 +277,15 @@ ngi->language = LANG_DEFAULT; ngi->timezone = TIMEZONE_DEFAULT; ni->nickgroup = ngi->id; - add_nickgroupinfo(ngi); + if (ngi->id != 0) { + add_nickgroupinfo(ngi); + } else { + free_nickgroupinfo(ngi); + if (!(ni->status & NS_VERBOTEN)) { + module_log("warning: nick %s has no nick group but is not" + " forbidden (corrupt database or BUG?)", ni->nick); + } + } } return ni; --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Wed Mar 13 14:43:18 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Services 5.0a24 /ns unlink nick force text error Message-ID: <3c8ee702.10367@achurch.org> Fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ >When force unlinking a nickname, an erroneous nickname results in the >following error message: > >/ns unlink Guest14 force >-NickServ- Nick Guest14 isn't linked to your nick. > >The message ought to be something along the lines of: > >-NickServ- Nick Guest14 isn't linked to any nickname. > > >-- >Mark. > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Wed Mar 13 14:46:24 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] 5.0a24, /ns link guestxxx bug Message-ID: <3c8ee7c4.10426@achurch.org> Duh, that was a stupid one. Fixed. --Andrew Church achurch@achurch.org http://achurch.org/ >The bug fix for this is not working. > >>From services.log: >IRC Services 5.0a24 starting up >nickserv/link: nick!user@host linked nick guest0 to nick > >-- >Mark. > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Wed Mar 13 14:58:13 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] 5.0a24 and +S clients Message-ID: <3c8eeaba.11106@achurch.org> It looks like this is because the other program is sending a message not understood by Services (whichever message corresponds to the "n" token in the log below, I haven't looked it up). It's probably SVSMODE or some such and just needs to have a handler added--I'll take a look. --Andrew Church achurch@achurch.org http://achurch.org/ >This is much better in 5.0a24 and if a +S client is on the network when >Services joins, it correctly ignores the client and does not change it's >modes. :) > >However, if the +S client joins after services is running, services will >enforce modes against it: > >In channel: >*** StatServ (stats@stats.xxxxx.net) has joined #stats >*** stats.xxxxx.net sets mode: +o StatServ >*** StatServ sets mode: +a StatServ >*** ChanServ sets mode: -ooa StatServ StatServ StatServ > >In services.log: >unknown message from server (:StatServ n StatServ +Sq) > >Andrew, anything specific I should look for that would help nail this one >down? I am guessing that services misses the /mode +S issued by StatServ, >and the error message in the log suggests this is what is happening. I am >going to check the StatServ startup code now to see exactly what it thinks >it is sending. > >-- >Mark. > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Wed Mar 13 15:24:19 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] 5.0a24 and +S clients Message-ID: <3c8ef0a0.11623@achurch.org> Okay, this should be fixed now. --Andrew Church achurch@achurch.org http://achurch.org/ > It looks like this is because the other program is sending a message >not understood by Services (whichever message corresponds to the "n" token >in the log below, I haven't looked it up). It's probably SVSMODE or some >such and just needs to have a handler added--I'll take a look. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > >>This is much better in 5.0a24 and if a +S client is on the network when >>Services joins, it correctly ignores the client and does not change it's >>modes. :) >> >>However, if the +S client joins after services is running, services will >>enforce modes against it: >> >>In channel: >>*** StatServ (stats@stats.xxxxx.net) has joined #stats >>*** stats.xxxxx.net sets mode: +o StatServ >>*** StatServ sets mode: +a StatServ >>*** ChanServ sets mode: -ooa StatServ StatServ StatServ >> >>In services.log: >>unknown message from server (:StatServ n StatServ +Sq) >> >>Andrew, anything specific I should look for that would help nail this one >>down? I am guessing that services misses the /mode +S issued by StatServ, >>and the error message in the log suggests this is what is happening. I am >>going to check the StatServ startup code now to see exactly what it thinks >>it is sending. >> >>-- >>Mark. >> >> >>------------------------------------------------------------------ >>To unsubscribe or change your subscription options, visit: >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From master at xchat.gr Wed Mar 13 08:33:05 2002 From: master at xchat.gr (George Stamatiou) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Solution to the nickgroup 0 problem. References: <21025.193.237.130.98.1015973539.squirrel@secure.uksolutions.co.uk> Message-ID: <3C8F7F41.9090700@xchat.gr> hello. i have a few days in mailing list and i didn't understand how to fix the problem with the nickgroup 0. I have the version 5.0a23 and in services log i take this. "[Mar 13 11:12:58 2002] database/version4: BUG: nickgroup with ID 0 found during write (skipping) ". what does it means? is it dangerous to loose nicknames? can i fix it or i have to upgrade to 5.0a24 ? Thanks From achurch at achurch.org Thu Mar 14 01:37:46 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Solution to the nickgroup 0 problem. Message-ID: <3c8f8079.00623@achurch.org> >hello. >i have a few days in mailing list and i didn't understand how to fix the >problem with the nickgroup 0. >I have the version 5.0a23 and in services log i take this. "[Mar 13 >11:12:58 2002] database/version4: BUG: nickgroup with ID 0 found during >write (skipping) ". >what does it means? is it dangerous to loose nicknames? can i fix it or >i have to upgrade to 5.0a24 ? It's not a serious problem right now, but if you upgrade Services won't start at all. I'd recommend waiting for 5.0a25 which should fix the problem. --Andrew Church achurch@achurch.org http://achurch.org/ From mark at ctcp.net Wed Mar 13 10:09:09 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Re: [IRCServices] IRC Services 5.0a24 segfault on startup Message-ID: <1060.193.237.130.98.1016042949.squirrel@secure.uksolutions.co.uk> > Andrew Church wrote: > >> If you can track this down it would be appreciated. > > > >The crash was much easier to find that I thought. The function > >add_nickgroupinfo raises the SEGFAULT "on purpose" > > Yes, I know that because I added it. :P I was hoping for a backtrace > or some other hint of why the nickgroup was being added in the > first place. Ah sorry, I did prepare a backtrace, but then since the SEGAULT was coded, thought it probably wouldn't be of any use so tried to locate the dodgy nickgroup instead thinking it would be more useful. -- Mark. From mark at ctcp.net Wed Mar 13 10:35:36 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Re: [IRCServices] IRC Services 5.0a24 segfault on startup Message-ID: <1150.193.237.130.98.1016044536.squirrel@secure.uksolutions.co.uk> > Andrew Church wrote: > Okay, I think I've found it--try the following patch: [snip] Well, it detects the problem as a bug before segfaulting now. From services.log: IRC Services 5.0a24 starting up database/version4: BUG: Unable to find nickgroup 0 for linked nick help (parent = list, root = list) Just on my way out, so will try and track it down when I get back. Mark. From achurch at achurch.org Thu Mar 14 09:07:55 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Re: [IRCServices] IRC Services 5.0a24 segfault on startup Message-ID: <3c8fea22.01024@achurch.org> >> Andrew Church wrote: >> Okay, I think I've found it--try the following patch: >[snip] > >Well, it detects the problem as a bug before segfaulting now. From >services.log: > >IRC Services 5.0a24 starting up >database/version4: BUG: Unable to find nickgroup 0 for linked nick help >(parent = list, root = list) Okay, I think this is because of the way 5.0 saves nicks with the same nickgroup, and it's not treating forbidden nicks properly. Can you send me your DBs so I can test it myself? --Andrew Church achurch@achurch.org http://achurch.org/ From mark at ctcp.net Wed Mar 13 16:22:45 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Re: [IRCServices] IRC Services 5.0a24 segfault on startup Message-ID: <1274.193.237.130.98.1016065365.squirrel@secure.uksolutions.co.uk> > Andrew Church wrote > Okay, I think this is because of the way 5.0 saves nicks with the > same nickgroup, and it's not treating forbidden nicks properly. Can you > send me your DBs so I can test it myself? DB files sent off list. Since I managed to develop a workaround for the problem to upgrade the version running on my production network, I now have the patched 5.0a24 running on 5.0a23 db files on a test machine here and producing the same error, so if you need me to do any more tests/patches let me know. Current output from gdb is: Starting program: /home/markh/services/bin/./ircservices Program received signal SIGSEGV, Segmentation fault. open_nick_db (dbname=0x8120bc0 "nick.db") at version4.c:469 469 ARRAY_EXTEND(ngi->nicks); (gdb) backtrace #0 open_nick_db (dbname=0x8120bc0 "nick.db") at version4.c:469 #1 0x401888a3 in init_module (module_=0x8120a60) at main.c:1524 #2 0x80541ac in internal_init_module (module=0x8120a60) at modules.c:354 #3 0x805423f in load_module (modulename=0x807abe8 "nickserv/main") at modules.c:383 #4 0x8050438 in init (ac=1, av=0xbffffaf4) at init.c:681 #5 0x80520ec in main (ac=1, av=0xbffffaf4, envp=0xbffffafc) at main.c:175 -- Mark. From achurch at achurch.org Thu Mar 14 09:28:09 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Re: [IRCServices] IRC Services 5.0a24 segfault on startup Message-ID: <3c8feec1.02571@achurch.org> >>> Andrew Church wrote: >>> Okay, I think I've found it--try the following patch: >>[snip] >> >>Well, it detects the problem as a bug before segfaulting now. From >>services.log: >> >>IRC Services 5.0a24 starting up >>database/version4: BUG: Unable to find nickgroup 0 for linked nick help >>(parent = list, root = list) Problem solved, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ From v13 at it.teithe.gr Thu Mar 14 16:25:39 2002 From: v13 at it.teithe.gr (V13) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Fwd: Re: [IRCServices] /ns ghost exploit Message-ID: <200203150225.40021.v13@it.teithe.gr> I'm forwarding this here, since i'm not 'directly' subscribed to irc-services list and it will not accept it... ---------- Forwarded Message ---------- Subject: Re: [IRCServices] /ns ghost exploit Date: Fri, 15 Mar 2002 01:41:17 +0200 From: V13 To: ircservices@ircservices.za.net On Thursday 14 March 2002 10:47, J.Brown (Ender/Amigo) wrote: > Personally, I really don't see too much of a problem with this. Sure, it > would be nice if the new user was just asked by Nickserv to change his > nickname - but.. For Andrew... Why not change the nickname instead of killing him and also send a notice about 'nickname bellongs to another one'? IRCDs will take care of dead connections. Or even better, make this an option to services.conf > (James Brown) | [Nehahra, ScummVM, PureLS, www.QuakeSrc.org] <> ------------------------------------------------------- From mark at ctcp.net Thu Mar 14 16:42:23 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] XML database download Message-ID: <21027.193.237.130.98.1016152943.squirrel@secure.uksolutions.co.uk> Having tried various browsers (IE, NetScape, Opera) and OS' (Windows and Linux) I am still unable to get a complete XML download from the httpd module. Both Opera and IE fail at the same point. Although I can get a "correctly" closed page (as in a subset of all records appear) with Netscape, not all records are listed (for example, not one of the admin/oper nicks are listed in the XML download!). Since the import/export option is something that would prove useful in a number of scenarios, maybe in addition to the XML feature there could be an exporter (either in Services itself or as a seperate program similar to the convertdb tools) which would export/import to/from say plain text or CSV format. In addition to providing a different option for import/export, this would help track down exactly what is going wrong in the XML download and which records are being missed. At present I know that admin and oper listed nicks do not display in the XML download. Forbidden and noexpire nicks also seem to not display. There are also a large number of other nicks that do not display. Without checking every nick in the database I cannot confirm why they are affected. There is no channel information at all in the export. StatServ information is only partial. (two server names that were temporary and no longer used appear but no others). I am sure this part was working in version 5.0a23 but doesn't now. I imagine this is all partly down to the fact that the xml output appears to get confused part way through (Netscape output follows)... ... 266 TamperProof 0 2it_message>Diego .... Andrew, let me know if you want a copy of the databases to look into this. -- Mark. From mark at ctcp.net Fri Mar 15 17:24:47 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] 5.0a24 - Problem with szline Message-ID: <21027.193.237.130.98.1016241887.squirrel@secure.uksolutions.co.uk> When an szline has been set and has expired allowing the user to reconnect, it is impossible to set a new szline on the same IP address unless another szline command (list or del) is issued, i.e.: *** Global -- from OperServ: Mark added an SZLINE for xx.xx.xx.xx(expires in 1 minute) *** Notice -- Client exiting: xxxxx (xxxx@xxxxx) [Z:lined (Z-lined: test)] -OperServ- xx.xx.xx.xx already exists on SZLINE list. [expected operation] *** Expiring Global Z:Line (*@xx.xx.xx.xx) made by Mark (Reason: Z-lined: test) set 26 seconds ago -OperServ- xx.xx.xx.xx already exists on SZLINE list. *** Notice -- Client connecting on port 6667: xxxxx (xxxx@xxxxxx) -OperServ- xx.xx.xx.xx already exists on SZLINE list. [unexpected operation] (xxx for privacy) An szline list produces an empty list (assuming no other szlines exists) so services has in one way removed the entry, but it appears to retain the entry in it's checking for multiple add calls until the next szline command resets it. This problem may exist in all sline commands, but I have only tested szline so far. -- Mark. From frostycoolslug at hotmail.com Fri Mar 15 17:37:14 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Services Killing Unreal... Message-ID: I dunno if this prob has been delt with b4.. i'm testing beta24, downloaded about an hour ago.. got it connected to my Unreal3.2-beta7 server, worked a dream.. found something i hadnt configured right, did an operserv shutdown.. and b000m the IRCd dies. AFAIK its not segfaulting, or giving a valid reason for the shutdown.. it just does. I thought i would report this here instead of to the Unreal ppl, cause Services are causeing the prob :) ne help appreaciated! -- Craig McLure Craig@e-tidalwave.org WaveAdmin on the e-tidalwave IRC Network Ride the Wave! www.e-tidalwave.org _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From mark at ctcp.net Fri Mar 15 17:52:34 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] 5.0a24 - Problem with szline Message-ID: <21025.193.237.130.98.1016243554.squirrel@secure.uksolutions.co.uk> My apologies, I forgot to interleave the commands in the log extract which might make the problem difficult to see, new version follows: /os szline add +26 xx.xx.xx.xx test *** Global -- from OperServ: Mark added an SZLINE for xx.xx.xx.xx(expires in 1 minute) *** Notice -- Client exiting: xxxxx (xxxx@xxxxx) [Z:lined (Z-lined: test)] /os szline add +26 xx.xx.xx.xx test -OperServ- xx.xx.xx.xx already exists on SZLINE list. [expected operation] *** Expiring Global Z:Line (*@xx.xx.xx.xx) made by Mark (Reason: Z-lined: test) set 26 seconds ago /os szline add +26 xx.xx.xx.xx test -OperServ- xx.xx.xx.xx already exists on SZLINE list. [unexpected operation] *** Notice -- Client connecting on port 6667: xxxxx (xxxx@xxxxxx) /os szline add +26 xx.xx.xx.xx test -OperServ- xx.xx.xx.xx already exists on SZLINE list. [unexpected operation] -- Mark. > -----Original Message----- > From: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net]On Behalf Of Mark > Hetherington > Sent: 16 March 2002 01:25 > To: ircservices-coding@ircservices.za.net > Subject: [IRCServices Coding] 5.0a24 - Problem with szline > > > When an szline has been set and has expired allowing the user to > reconnect, > it is impossible to set a new szline on the same IP address > unless another > szline command (list or del) is issued, i.e.: > > *** Global -- from OperServ: Mark added an SZLINE for xx.xx.xx.xx(expires > in 1 minute) > *** Notice -- Client exiting: xxxxx (xxxx@xxxxx) [Z:lined (Z-lined: test)] > -OperServ- xx.xx.xx.xx already exists on SZLINE list. > [expected operation] > *** Expiring Global Z:Line (*@xx.xx.xx.xx) made by Mark (Reason: Z-lined: > test) set 26 seconds ago > -OperServ- xx.xx.xx.xx already exists on SZLINE list. > *** Notice -- Client connecting on port 6667: xxxxx (xxxx@xxxxxx) > -OperServ- xx.xx.xx.xx already exists on SZLINE list. > [unexpected operation] > > (xxx for privacy) > > An szline list produces an empty list (assuming no other szlines > exists) so > services has in one way removed the entry, but it appears to retain the > entry in it's checking for multiple add calls until the next > szline command > resets it. > > This problem may exist in all sline commands, but I have only > tested szline > so far. > > -- > Mark. > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From uhc0 at rz.uni-karlsruhe.de Sat Mar 16 03:09:26 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:18 2004 Subject: AW: [IRCServices Coding] Services Killing Unreal... In-Reply-To: Message-ID: <000301c1ccdb$1b1771f0$02c8a8c0@nygmatech.local> Hello; I would suggest contacting Unreal coders also. It looks like that services is sending a line, where unreal does expect more parameteres than recevied. It probably goes through the code and because of the missing parameter, it cores. (NULL pointer reference) You either have a coredump of the ircd, of which a backtrace would show up which line was in a matter of being parsed, or you have the services.log and you might see, if run with -debug, which was the last line services sent, before the ircd cored. With the help of a small fix in this case, Unreal will solve the problem in their next beta version. But if you do not contact them... You must also admit, that ircservices is not the source of the problem, but the wrong coding in unreal ircd. This means, even if ircservices will find a way not to cause this, the problem with the ircd would persist. There are other ways (like RAW) which can be used to cause the core. Because in general, no irc protocol message should lead into a segfaulting ircd. So again, you also ought to contact Unreal coders, so that they can solve the problem for the next beta version. Regards; yusuf ---------------------------------------------------------------------- | Yusuf Iskenderoglu | You get to meet all sorts, | | eMail - uhc0@stud.uni-karlsruhe.de| in this line of work... | | eMail - s_iskend@ira.uka.de | | | ICQ UIN : 20587464 \ TimeMr14C | | ---------------------------------------------------------------------- > -----Urspr?ngliche Nachricht----- > Von: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net] Im > Auftrag von Craig McLure > Gesendet: Samstag, 16. M?rz 2002 02:37 > An: ircservices-coding@ircservices.za.net > Betreff: [IRCServices Coding] Services Killing Unreal... > > > I dunno if this prob has been delt with b4.. i'm testing > beta24, downloaded > about an hour ago.. got it connected to my Unreal3.2-beta7 > server, worked a > dream.. found something i hadnt configured right, did an > operserv shutdown.. > and b000m the IRCd dies. AFAIK its not segfaulting, or giving > a valid reason > for the shutdown.. it just does. I thought i would report > this here instead > of to the Unreal ppl, cause Services are causeing the prob :) > ne help appreaciated! > > -- > Craig McLure > Craig@e-tidalwave.org > WaveAdmin on the e-tidalwave IRC Network > Ride the Wave! www.e-tidalwave.org > > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo> /ircservices-coding > From frostycoolslug at hotmail.com Sat Mar 16 12:21:46 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Mail-Auth really needed for sendpass? Message-ID: is it possible to have sendmail work without mail auth? we dont wanna put our users though the annoying processes of authing nicknames, just so they can use sendpass.. i'm not sure if this is a feature.. but could be concidered, if u like a nickname it automatically becomes authed? as this nick should share the email address.. maybe then this wouldnt be so much of a problem :P -- Craig McLure Craig@e-tidalwave.org WaveAdmin on the e-tidalwave IRC Network Ride the Wave! www.e-tidalwave.org _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From frostycoolslug at hotmail.com Sat Mar 16 15:17:33 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] HTTPd Possible feature.. Message-ID: Maybe /~nick could display the nickserv info as a user would see them.. with a command to edit the nick settings, logging in with the nickname password.. also maybe a way to template the pages that are viewed for better interdration into a website? :) -- Craig McLure Craig@e-tidalwave.org WaveAdmin on the e-tidalwave IRC Network Ride the Wave! www.e-tidalwave.org _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From achurch at achurch.org Sun Mar 17 12:05:07 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Mail-Auth really needed for sendpass? Message-ID: <3c940805.26364@achurch.org> Yes, it's necessary, because otherwise malicious users could flood other users' mailboxes. --Andrew Church achurch@achurch.org http://achurch.org/ >is it possible to have sendmail work without mail auth? we dont wanna put >our users though the annoying processes of authing nicknames, just so they >can use sendpass.. >i'm not sure if this is a feature.. but could be concidered, if u like a >nickname it automatically becomes authed? as this nick should share the >email address.. >maybe then this wouldnt be so much of a problem :P > > > >-- >Craig McLure >Craig@e-tidalwave.org >WaveAdmin on the e-tidalwave IRC Network >Ride the Wave! www.e-tidalwave.org > > >_________________________________________________________________ >Join the world?s largest e-mail service with MSN Hotmail. >http://www.hotmail.com > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From frostycoolslug at hotmail.com Sat Mar 16 19:12:12 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Mail-Auth really needed for sendpass? Message-ID: yeah, i know.. i think i was asleep when sending this mail.. both physically and mentally :) what about the linking nick? maybe /ns NEWLINK .. this could register a new nickname, and automatically link it without having to send the mail? i think several ppl would agree, this would be a nice feature *nods* :) >From: achurch@achurch.org (Andrew Church) >Reply-To: ircservices-coding@ircservices.za.net >To: ircservices-coding@ircservices.za.net >Subject: Re: [IRCServices Coding] Mail-Auth really needed for sendpass? >Date: Sun, 17 Mar 2002 12:05:07 JST > > Yes, it's necessary, because otherwise malicious users could flood >other users' mailboxes. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > > >is it possible to have sendmail work without mail auth? we dont wanna put > >our users though the annoying processes of authing nicknames, just so >they > >can use sendpass.. > >i'm not sure if this is a feature.. but could be concidered, if u like a > >nickname it automatically becomes authed? as this nick should share the > >email address.. > >maybe then this wouldnt be so much of a problem :P > > > > > > > >-- > >Craig McLure > >Craig@e-tidalwave.org > >WaveAdmin on the e-tidalwave IRC Network > >Ride the Wave! www.e-tidalwave.org > > > > > >_________________________________________________________________ > >Join the world’s largest e-mail service with MSN Hotmail. > >http://www.hotmail.com > > > >------------------------------------------------------------------ > >To unsubscribe or change your subscription options, visit: > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding -- Craig McLure Craig@e-tidalwave.org WaveAdmin on the e-tidalwave IRC Network Ride the Wave! www.e-tidalwave.org _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From mark at ctcp.net Sun Mar 17 05:49:40 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] Mail-Auth really needed for sendpass? Message-ID: <1064.193.237.130.98.1016372980.squirrel@secure.uksolutions.co.uk> /ns link nick from a registered nick will already link a new nick and does not require an authorisation by email. -- Mark. > -----Original Message----- > From: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net]On Behalf Of Craig > McLure > Sent: 17 March 2002 03:12 > To: ircservices-coding@ircservices.za.net > Subject: Re: [IRCServices Coding] Mail-Auth really needed for sendpass? > > > yeah, i know.. i think i was asleep when sending this mail.. both > physically > and mentally :) > what about the linking nick? > maybe /ns NEWLINK .. > this could register a new nickname, and automatically link it > without having > to send the mail? > > i think several ppl would agree, this would be a nice feature *nods* :) > > > >From: achurch@achurch.org (Andrew Church) > >Reply-To: ircservices-coding@ircservices.za.net > >To: ircservices-coding@ircservices.za.net > >Subject: Re: [IRCServices Coding] Mail-Auth really needed for sendpass? > >Date: Sun, 17 Mar 2002 12:05:07 JST > > > > Yes, it's necessary, because otherwise malicious users could flood > >other users' mailboxes. > > > > --Andrew Church > > achurch@achurch.org > > http://achurch.org/ > > > > >is it possible to have sendmail work without mail auth? we > dont wanna put > > >our users though the annoying processes of authing nicknames, just so > >they > > >can use sendpass.. > > >i'm not sure if this is a feature.. but could be concidered, > if u like a > > >nickname it automatically becomes authed? as this nick should share the > > >email address.. > > >maybe then this wouldnt be so much of a problem :P > > > > > > > > > > > >-- > > >Craig McLure > > >Craig@e-tidalwave.org > > >WaveAdmin on the e-tidalwave IRC Network > > >Ride the Wave! www.e-tidalwave.org > > > > > > > > >_________________________________________________________________ > > >Join the worlds largest e-mail service with MSN Hotmail. > > >http://www.hotmail.com > > > > > >------------------------------------------------------------------ > > >To unsubscribe or change your subscription options, visit: > > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > >------------------------------------------------------------------ > >To unsubscribe or change your subscription options, visit: > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > > > > -- > Craig McLure > Craig@e-tidalwave.org > WaveAdmin on the e-tidalwave IRC Network > Ride the Wave! www.e-tidalwave.org > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Mon Mar 18 11:51:11 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] XML database download Message-ID: <3c955701.26653@achurch.org> >Having tried various browsers (IE, NetScape, Opera) and OS' (Windows and >Linux) I am still unable to get a complete XML download from the httpd >module. Both Opera and IE fail at the same point. Although I can get >a "correctly" closed page (as in a subset of all records appear) with >Netscape, not all records are listed (for example, not one of the >admin/oper nicks are listed in the XML download!). [...] >At present I know that admin and oper listed nicks do not display in the >XML download. Forbidden and noexpire nicks also seem to not display. There >are also a large number of other nicks that do not display. Without >checking every nick in the database I cannot confirm why they are affected. I can't reproduce this--I get a complete download (or at least what looks like a complete download without feeding it back to the importer; at the least I get channel information and oper/admin nicks). >Since the import/export option is something that would prove useful in a >number of scenarios, maybe in addition to the XML feature there could be an >exporter (either in Services itself or as a seperate program similar to the >convertdb tools) which would export/import to/from say plain text or CSV >format. Um, why? There's nothing special about XML that would cause this problem to happen. I'm using XML because it's self-documenting as to the meaning of each field. If you don't like XML write your own converter to something else. >I imagine this is all partly down to the fact that the xml output appears >to get confused part way through (Netscape output follows)... >... > >266 > >TamperProof > >0 >2it_message>Diego > >.... I don't get this either, at least with the previous copy of your databases that you sent me. Send me the current versions and I'll try again. --Andrew Church achurch@achurch.org http://achurch.org/ From mark at ctcp.net Mon Mar 18 12:37:20 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] XML database download Message-ID: <1171.193.237.130.98.1016483840.squirrel@secure.uksolutions.co.uk> > Andrew Church wrote: > Um, why? There's nothing special about XML that would cause this > problem to happen. I'm using XML because it's self-documenting as to the > meaning of each field. If you don't like XML write your own converter to > something else. I never expressed my feelings wrt XML one way or another, merely suggested an alternative. My reasons for suggesting an alternative were that I have yet to see the XML download actually work correctly despite trying various browsers and operating systems, plus for debugging what seems to trigger the failures as I previously mentioned. Until the database format for version 5 exists, it would be somewhat redundant to develop an application myself that would have to be rewritten once the new format is released. [snip] > I don't get this either, at least with the previous copy of your > databases that you sent me. Send me the current versions and I'll try > again. Databases sent off list. The problems are different again (stats information appears to be complete yet, but no channels and many missing nicks), so the problem seems to change as the database evolves. -- Mark. From achurch at achurch.org Tue Mar 19 10:07:27 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] XML database download Message-ID: <3c96923f.27232@achurch.org> >The problems are different again (stats information appears to be complete >yet, but no channels and many missing nicks), so the problem seems to >change as the database evolves. I still can't reproduce this, even with the new databases. It looks like socket buffering isn't being handled correctly, at least at a guess. Can you send me the complete XML output you get so I can try and figure out where the problem is? Also, are you accessing the page directly via localhost or from a different machine, and if the latter at what link speed? --Andrew Church achurch@achurch.org http://achurch.org/ From mark at ctcp.net Mon Mar 18 17:37:17 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:18 2004 Subject: [IRCServices Coding] XML database download Message-ID: <21026.193.237.130.98.1016501837.squirrel@secure.uksolutions.co.uk> > Andrew Church wrote: > I still can't reproduce this, even with the new databases. It looks > like socket buffering isn't being handled correctly, at least at a guess. > Can you send me the complete XML output you get so I can try and figure > out where the problem is? Also, are you accessing the page directly via > localhost or from a different machine, and if the latter at what link > speed? Accessing from different machine. Have tried over ISDN (64K and 128K) and over a T3 with similar results. -- Mark. From achurch at achurch.org Tue Mar 19 11:08:20 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] XML export problem fixed Message-ID: <3c969e2f.31143@achurch.org> It turned out to be a problem in the socket write buffer handling after all, which I just wasn't seeing because I was always accessing from localhost (which obviously doesn't incur network delays and thus require buffering). Fixed, thanks for the help. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Mar 19 11:12:01 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] Services 5.0 alpha 25 released Message-ID: <3c96a0af.46413@achurch.org> Slowly but surely, slowly but surely... Changes in version 5.0 alpha 25 ------------------------------- 2002/03/19 Fixed a bug in socket write buffer handling causing data to be lost. Reported by Mark Hetherington 2002/03/14 Fixed a bug causing crashes with a corrupt database. 2002/03/13 Fixes and changes suggested by Mark Hetherington : - Fixed bug causing nick groups with ID 0 to be created. - Fixed cosmetic bug with NickServ UNLINK FORCE. - Fixed bug in bugfix for linking of guest nicks. - Added support for SVSMODE on Dreamforge/Bahamut/Unreal. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Mar 19 11:47:54 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] channel: MODE #channel -b *!*@host: ban not found Message-ID: <3c96a7aa.46762@achurch.org> Fixed (the ban wasn't getting added to the internal list). --Andrew Church achurch@achurch.org http://achurch.org/ >Services v 5.0a23 > >Not sure exactly on the causes of this one yet, but logs indicate that >something is wrong so am reporting it in case it is something obvious while >I research further. > >Basically, whenever ChanServ sets +b*!user@host in a channel in response to >an autokick entry, the subsequent attempt to remove the ban from a channel >results in services logging: > >channel: MODE #channel -b *!*@host: ban not found > >The bans are usually removed automatically by channel bots to keep the >channel ban list manageable so I am assuing there is some discrepancy >between the original announcement by Chanserv of the ban it has set and the >actual ban it sets or Chanserv incorrectly parsing the /mode -b. > >>From channel: >DOS_BOT_77 (~username@ctcp-35163.cas-lon.golden.net) joined #channel. >#channel: mode change '+b dos_bot*!*@*' by ChanServ!services@ctcp.net >DOS_BOT_77 kicked from #channel by ChanServ: User has been banned from the >channel >.... >(#channel) Channel ban on dos_bot*!*@* expired. >#channel: mode change '-b dos_bot*!*@*' by Bot > >services.log: >channel: MODE #channel -b dos_bot*!*@*: ban not found > > > >-- >Mark. >CTCP Networks. > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From mark at ctcp.net Tue Mar 19 14:17:21 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] Services 5.0a25 - Couple minor conf things Message-ID: <21028.193.237.130.98.1016576241.squirrel@secure.uksolutions.co.uk> Noticed a new directive in the conf file, CSForbidShortChannel. Although it should be obvious from the comment, the usual default entry is missing. I.e. no CSForbidShortChannel or #CSForbidShortChannel following the comment. SQLine and SGline are missing 'examples' using "%s" which are usually included for such directives. One of the previous services updates changed some *akill* directives to *autokill*. Not sure if you want to apply the same naming convention to them. Only five directives now remain that use akill rather than autokill: KillClonesAkill, ImmediatelySendAkill, WallOSAkill, WallAkillExpire and SessionLimitAkill. -- Mark. From mark at ctcp.net Tue Mar 19 14:24:13 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] Services 5.0a25 - /ns link guestxxxx bug Message-ID: <21029.193.237.130.98.1016576653.squirrel@secure.uksolutions.co.uk> The bug fix for the guest linking bug appears to be case sensitive meaning that the fix is not 100% effective: /ns link Guest666 -NickServ- Nickname Guest666 may not be registered. /ns link guest666 -NickServ- Nick guest666 has been linked to your nick. strncmp needs to be strnicmp. -- Mark. From master at xchat.gr Wed Mar 20 04:57:26 2002 From: master at xchat.gr (George Stamatiou) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] Services 5.0a25 - ChanServ SENDPASS References: <21028.193.237.130.98.1016576241.squirrel@secure.uksolutions.co.uk> Message-ID: <3C988736.2090908@xchat.gr> I think there is a bug in the ChanServ SENDPASS command. I receive the email but not with the pass of my channel but from my nickname :/ From gue_raja at yahoo.com Wed Mar 20 05:24:04 2002 From: gue_raja at yahoo.com (_DaruDoanK_) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] need help Message-ID: <01a701c1d012$81542a50$90069bca@darudoank> I've installed IRCD bahalmut and IRCservice. my IRCD is running well but not with IRCService. every I run the services, I always got error message CLOSING LINK 0.0.0.0 (No N line) how to fix that. e.g : my IP server : 202.155.16.16 and host name chat.my.com IRCD and IRCservices are installed in the same machine. need reply soon, please thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20020320/e61868af/attachment.html From master at xchat.gr Wed Mar 20 08:54:56 2002 From: master at xchat.gr (George Stamatiou) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] Services 5.0a25 - ChanServ SENDPASS Solution Message-ID: <3C98BEE0.4050005@xchat.gr> Ok i found it. in file /modules/chanserv/sendpass.c just replace the line snprintf(body, sizeof(body), getstring(ngi,CHAN_SENDPASS_MAIL_BODY), ci->name, passbuf, s_ChanServ, u->username, u->host); with the following snprintf(body, sizeof(body), getstring(ngi,CHAN_SENDPASS_MAIL_BODY), ci->name, ci->founderpass, s_ChanServ, u->username, u->host); i test it and it's ok now :) From ayottew at sympatico.ca Wed Mar 20 17:24:44 2002 From: ayottew at sympatico.ca (Wayne Ayotte) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] help files Message-ID: <000d01c1d077$2ec93b30$0201a8c0@webdevint.com> which files contain the help text in the new beta version, and where is the d/l site again, I don't want to go through like 5000 archived mail msgs :), and by the way Andrew, can you really speak and write Japanese? Wayne A. Web Developers International From achurch at achurch.org Thu Mar 21 11:52:09 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] help files Message-ID: <3c994b93.47565@achurch.org> >which files contain the help text in the new beta version, and where is the >d/l site again, I don't want to go through like 5000 archived mail msgs :), The help files are in lang/*.l as always, and there's a link on the home page (http://www.ircservices.za.net/) to the alpha release page. >and by the way Andrew, can you really speak and write Japanese? ???? -- yes, I can. ;) You wouldn't know it from the Japanese language file, but that's because I wrote that 4-5 years ago when I knew much less Japanese than I do now. I'm going to fix it up Real Soon Now... --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Mar 26 13:49:17 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] Services 5.0a25 - Couple minor conf things Message-ID: <3ca00151.76044@achurch.org> >Noticed a new directive in the conf file, CSForbidShortChannel. Although it >should be obvious from the comment, the usual default entry is missing. >I.e. no CSForbidShortChannel or #CSForbidShortChannel following the comment. > >SQLine and SGline are missing 'examples' using "%s" which are usually >included for such directives. Fixed. >One of the previous services updates changed some *akill* directives to >*autokill*. Not sure if you want to apply the same naming convention to >them. Only five directives now remain that use akill rather than autokill: >KillClonesAkill, ImmediatelySendAkill, WallOSAkill, WallAkillExpire and >SessionLimitAkill. Fixed, except for WallOSAkill which refers to the command (AKILL) rather than the word (autokill). --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Mar 26 14:12:05 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] Services 5.0a25 - /ns link guestxxxx bug Message-ID: <3ca0035f.02264@achurch.org> >The bug fix for the guest linking bug appears to be case sensitive meaning >that the fix is not 100% effective: > >/ns link Guest666 >-NickServ- Nickname Guest666 may not be registered. > >/ns link guest666 >-NickServ- Nick guest666 has been linked to your nick. > >strncmp needs to be strnicmp. Actually, it needs to be irc_strnicmp, but fixed. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Mar 26 14:14:29 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] Services 5.0a25 - ChanServ SENDPASS Solution Message-ID: <3ca00474.03652@achurch.org> >Ok i found it. >in file /modules/chanserv/sendpass.c just replace the line >snprintf(body, sizeof(body), getstring(ngi,CHAN_SENDPASS_MAIL_BODY), > ci->name, passbuf, s_ChanServ, u->username, u->host); >with the following > >snprintf(body, sizeof(body), getstring(ngi,CHAN_SENDPASS_MAIL_BODY), > ci->name, ci->founderpass, s_ChanServ, u->username, >u->host); >i test it and it's ok now :) This is wrong--you'll get garbage if encryption is in use. The proper fix is change ngi->pass to ci->founderpass slightly above that. Fixed for the next alpha. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Mar 26 14:19:26 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] 5.0a24 - Problem with szline Message-ID: <3ca00569.03666@achurch.org> I'm planning to (before the beta release) rework the expiration system to take care of this, so it won't get fixed immediately. For now, just do an "SLINE DEL *@xx.xx.xx.xx" (or alternatively UPDATE, which checks for expiration as well) if you run into this. --Andrew Church achurch@achurch.org http://achurch.org/ >When an szline has been set and has expired allowing the user to reconnect, >it is impossible to set a new szline on the same IP address unless another >szline command (list or del) is issued, i.e.: > >*** Global -- from OperServ: Mark added an SZLINE for xx.xx.xx.xx(expires >in 1 minute) >*** Notice -- Client exiting: xxxxx (xxxx@xxxxx) [Z:lined (Z-lined: test)] >-OperServ- xx.xx.xx.xx already exists on SZLINE list. >[expected operation] >*** Expiring Global Z:Line (*@xx.xx.xx.xx) made by Mark (Reason: Z-lined: >test) set 26 seconds ago >-OperServ- xx.xx.xx.xx already exists on SZLINE list. >*** Notice -- Client connecting on port 6667: xxxxx (xxxx@xxxxxx) >-OperServ- xx.xx.xx.xx already exists on SZLINE list. >[unexpected operation] > >(xxx for privacy) > >An szline list produces an empty list (assuming no other szlines exists) so >services has in one way removed the entry, but it appears to retain the >entry in it's checking for multiple add calls until the next szline command >resets it. > >This problem may exist in all sline commands, but I have only tested szline >so far. > >-- >Mark. > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From andrewk at isdial.net Tue Mar 26 21:52:27 2002 From: andrewk at isdial.net (Andrew Kempe) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] Mailing List Archives Now Searchable Message-ID: <001501c1d553$93873c80$9c011ac4@africa.didata.local> Just to let you all know that the "current" archives for the mailing lists are now searchable from within the IRC Services website. Just head on over to http://www.ircservices.za.net/mailinglists.html Let me know if you have comments etc. Later, Andrew From gue_raja at yahoo.com Wed Mar 27 00:09:33 2002 From: gue_raja at yahoo.com (_DaruDoanK_) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] URGENT References: <3ca00151.76044@achurch.org> Message-ID: <03e801c1d566$ba557df0$90069bca@darudoank> hello guys, I have a problem here ... I've registered my nick, e.g my nick is TEST and then I try to connect to my IRC server using nick TEST I got message from nick serv that TEST is already registered and my nick will be changed. after a few seconds, I got notive from nickserv that my nick has been changed to Guest123 but, in fact .. my nick have not changed ... why ??? From Georges at Berscheid.lu Wed Mar 27 00:07:56 2002 From: Georges at Berscheid.lu (Georges Berscheid) Date: Sat Oct 23 23:09:19 2004 Subject: AW: [IRCServices Coding] URGENT In-Reply-To: <03e801c1d566$ba557df0$90069bca@darudoank> Message-ID: Your ircd probably does not know SVSNICK. Georges -----Ursprungliche Nachricht----- Von: ircservices-coding-admin@ircservices.za.net [mailto:ircservices-coding-admin@ircservices.za.net]Im Auftrag von _DaruDoanK_ Gesendet: Mittwoch, 27. Marz 2002 09:10 An: ircservices-coding@ircservices.za.net Betreff: [IRCServices Coding] URGENT hello guys, I have a problem here ... I've registered my nick, e.g my nick is TEST and then I try to connect to my IRC server using nick TEST I got message from nick serv that TEST is already registered and my nick will be changed. after a few seconds, I got notive from nickserv that my nick has been changed to Guest123 but, in fact .. my nick have not changed ... why ??? ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From eengin at talesoft.de Wed Mar 27 00:16:59 2002 From: eengin at talesoft.de (Ekim Engin) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] Features/contributions for ircservices version 5 In-Reply-To: Message-ID: <000a01c1d567$c47eb2f0$0155a8c0@talesoft.de> Hi first a question I posted 2 weeks ago, but got no response at all: For me it looks like a good idea to make sadmins list nicks by their emails like: /ns list *@talesoft.de MAIL -NickServ- Ekim eengin@talesoft.de -NickServ- Talesin eengin@talesoft.de The next question is, I just finished a man page for an ircd I am contributing, and while I did this, I had the Idea to do a man page for ircservices.conf.5 and modules.conf.5 too. I just wanted to ask if there is any neeed for such a thing... Greets Ekim "Talesin" Engin Network Administrator of TTNet (Turkey) http://www.ttchat.net - irc://irc.ttnet.net.tr PGP-Fingerprint: 8627 180C 1397 34FB 6BB0 8B65 9CBF 8ED5 456C 48F9 --- Chat begins as it ends - without reason From achurch at achurch.org Wed Mar 27 17:36:28 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] Features/contributions for ircservices version 5 Message-ID: <3ca1851f.04172@achurch.org> >Hi first a question I posted 2 weeks ago, but got no response at all: > >For me it looks like a good idea to make sadmins list nicks by their >emails >like: > >/ns list *@talesoft.de MAIL > >-NickServ- Ekim eengin@talesoft.de >-NickServ- Talesin eengin@talesoft.de Already listed in TODO; I don't know whether/when I'll implement it. >The next question is, I just finished a man page for an ircd I am >contributing, and while I did this, I had the Idea to do a man page for >ircservices.conf.5 and modules.conf.5 too. I just wanted to ask if there >is any neeed for such a thing... No, since the documentation is already available in HTML and I have no intention of maintaining multiple formats for the same documentation. --Andrew Church achurch@achurch.org http://achurch.org/ From gue_raja at yahoo.com Wed Mar 27 01:57:40 2002 From: gue_raja at yahoo.com (_DaruDoanK_) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] URGENT References: Message-ID: <04dd01c1d575$d5431dc0$90069bca@darudoank> so how to fix that ?? The QUESTION is ... ----------------------------------------------------- * http://widyan.da.ru * FREE of CHARGE ----- Original Message ----- From: "Georges Berscheid" To: Sent: Wednesday, March 27, 2002 3:07 PM Subject: AW: [IRCServices Coding] URGENT > Your ircd probably does not know SVSNICK. > > Georges > > -----Ursprungliche Nachricht----- > Von: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net]Im Auftrag von > _DaruDoanK_ > Gesendet: Mittwoch, 27. Marz 2002 09:10 > An: ircservices-coding@ircservices.za.net > Betreff: [IRCServices Coding] URGENT > > > hello guys, > > I have a problem here ... > > I've registered my nick, e.g my nick is TEST > and then I try to connect to my IRC server using nick TEST > > I got message from nick serv that TEST is already registered and my nick > will be changed. > after a few seconds, I got notive from nickserv that my nick has been > changed to Guest123 > > but, in fact .. my nick have not changed ... why ??? > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From sigma at algolx.net Thu Mar 28 20:38:12 2002 From: sigma at algolx.net (Tom Casartello) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] One little suggestion and a compliment Message-ID: <005c01c1d6db$896ba680$3624da18@ne.client2.attbi.com> Though this is probably not the place for this, I couldn't help complimenting the author and all of helping developers of IRC Services of version 5. It's looking pretty good so far, though it obviously has some bugs, the features are great. My suggestion is this: more in the HTTP server. I don't mean the user pages like DALnet has. But HTTP Authorization would be cool like DALnet's, or being able to change some of your info online. (Though I'm not sure this would be worth spending a lot of time on.) Just a suggestion. Thanks, Tom Casartello IRC Services User -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20020328/aedb9347/attachment.htm From achurch at achurch.org Sat Mar 30 05:12:18 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] Services 5.0 alpha 26 released Message-ID: <3ca4cae9.35264@achurch.org> Blah, blah, you know the story. Not really much point in this release except to let you all that yes, I'm still alive. (: Changes in version 5.0 alpha 26 ------------------------------- 2002/03/30 Fixed potential buffer overflow in HTTP daemon. 2002/03/27 Fixed bug processing commands with extra spaces in them. 2002/03/26 Fixed bug causing nickname password to be sent for ChanServ SENDPASS. Reported by George Stamatiou 2002/03/26 Fixed compilation warnings in modules/chanserv/check.c. 2002/03/26 Fixes and changes suggested by Mark Hetherington : - Changed "akill" to "autokill" in configuration options. - Fixed bug allowing guest nicks to be registered/linked. 2002/03/19 Fixed "ban not found" message when removing an autokick ban. Reported by Mark Hetherington --Andrew Church achurch@achurch.org http://achurch.org/ From frostycoolslug at hotmail.com Sun Mar 31 00:15:16 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] Modules? Message-ID: Has any1 started work on any Version5 modules yet? if so whatcha doing? i'm planning on making a botserv, but was wondering if ne1 was already making one :) -- Craig McLure Craig@e-tidalwave.org WaveAdmin on the e-tidalwave IRC Network Ride the Wave! www.e-tidalwave.org _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From uhc0 at rz.uni-karlsruhe.de Sun Mar 31 01:29:54 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:19 2004 Subject: AW: [IRCServices Coding] Modules? In-Reply-To: Message-ID: <001801c1d896$af9c13a0$02c8a8c0@nygmatech.local> Hello; I have written four modules for version5, a protocol module for trircd4 and 5 series. a module for the MemoServ to do the IGNORE command a module for the NickServ to do the AJOIN command a module for the OperServ to do the trircd specific autokill exclusion command. None of them is creating a BotServ ;-) The first three are already in services, you should have seen them. Regards; yusuf ---------------------------------------------------------------------- | Yusuf Iskenderoglu | You get to meet all sorts, | | eMail - uhc0@stud.uni-karlsruhe.de| in this line of work... | | eMail - s_iskend@ira.uka.de | | | ICQ UIN : 20587464 \ TimeMr14C | | ---------------------------------------------------------------------- > -----Urspr?ngliche Nachricht----- > Von: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net] Im > Auftrag von Craig McLure > Gesendet: Sonntag, 31. M?rz 2002 10:15 > An: ircservices-coding@ircservices.za.net > Betreff: [IRCServices Coding] Modules? > > > Has any1 started work on any Version5 modules yet? if so > whatcha doing? i'm planning on making a botserv, but was > wondering if ne1 was already > making one :) > > > > -- > Craig McLure > Craig@e-tidalwave.org > WaveAdmin on the e-tidalwave IRC Network > Ride the Wave! www.e-tidalwave.org > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo> /ircservices-coding > From Georges at Berscheid.lu Sun Mar 31 06:34:17 2002 From: Georges at Berscheid.lu (Georges Berscheid) Date: Sat Oct 23 23:09:19 2004 Subject: AW: [IRCServices Coding] Modules? In-Reply-To: Message-ID: Hi, I remember that some people were intrested in a mysql database module. Has anyone gone into that direction yet ? If not, is there anybody around who would like to help me ? Georges -----Urspr?ngliche Nachricht----- Von: ircservices-coding-admin@ircservices.za.net [mailto:ircservices-coding-admin@ircservices.za.net]Im Auftrag von Craig McLure Gesendet: Sonntag, 31. M?rz 2002 10:15 An: ircservices-coding@ircservices.za.net Betreff: [IRCServices Coding] Modules? Has any1 started work on any Version5 modules yet? if so whatcha doing? i'm planning on making a botserv, but was wondering if ne1 was already making one :) -- Craig McLure Craig@e-tidalwave.org WaveAdmin on the e-tidalwave IRC Network Ride the Wave! www.e-tidalwave.org _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From griever at t2n.org Sun Mar 31 06:50:18 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:19 2004 Subject: AW: [IRCServices Coding] Modules? In-Reply-To: Message-ID: On Sun, 31 Mar 2002, Georges Berscheid wrote: > Hi, > > I remember that some people were intrested in a mysql database module. Has > anyone gone into that direction yet ? If not, is there anybody around who > would like to help me ? > > Georges > I have started the mysql database module, if I can get around to it I'll finish it. If not, andrew will probably work on it after 5.0 becomes stable. From r-krisztian at softhome.net Sun Mar 31 07:10:07 2002 From: r-krisztian at softhome.net (=?iso-8859-2?Q?Romek_Kriszti=E1n?=) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] segmentation faults - ircservices 5.0a26 Message-ID: <002001c1d8c6$286338c0$0b00000a@rokusnet.hu> Hello! Your latest alpha version is pretty good, I want to use your program, but I had experienced the following errors at the first uses: *operserv*> exception add +0 *** Global -- from services.freechat.ods.org: PANIC! buffer = :AngryWolf !operserv :exception add +0 *** LocOps -- Received SQUIT services.freechat.ods.org from services.freechat.ods.org[127.0.0.1] (Services terminating: Segmentation fault) -freechat.ods.org- *** Global -- from services.freechat.ods.org: PANIC! buffer = :Toxyc ! nickserv :help -freechat.ods.org- *** LocOps -- Received SQUIT services.freechat.ods.org from services.freechat.ods.org[127.0.0.1] (Services terminating: Segmentation fault) -freechat.ods.org- *** Global -- from services.freechat.ods.org: PANIC! buffer = :omnii PRIVMSG ChanServ@services.freechat.ods.org :register #limp_bizkit fred -freechat.ods.org- *** LocOps -- Received SQUIT services.freechat.ods.org from services.freechat.ods.org[127.0.0.1] (Services terminating: Segmentation fault) Can you solve this problem me to use this services again? Thx for all Regards AngryWolf From frostycoolslug at hotmail.com Sun Mar 31 07:14:59 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] segmentation faults - ircservices 5.0a26 Message-ID: What IRCd are you using? >From: Romek Krisztián >Reply-To: ircservices-coding@ircservices.za.net >To: >Subject: [IRCServices Coding] segmentation faults - ircservices 5.0a26 >Date: Sun, 31 Mar 2002 17:10:07 +0200 > >Hello! > >Your latest alpha version is pretty good, I want to use your program, but I >had experienced the following errors at the first uses: > >*operserv*> exception add +0 >*** Global -- from services.freechat.ods.org: PANIC! buffer = :AngryWolf >!operserv :exception add +0 >*** LocOps -- Received SQUIT services.freechat.ods.org from >services.freechat.ods.org[127.0.0.1] (Services terminating: Segmentation >fault) > >-freechat.ods.org- *** Global -- from services.freechat.ods.org: PANIC! >buffer = :Toxyc ! nickserv :help >-freechat.ods.org- *** LocOps -- Received SQUIT services.freechat.ods.org >from services.freechat.ods.org[127.0.0.1] (Services terminating: >Segmentation fault) > >-freechat.ods.org- *** Global -- from services.freechat.ods.org: PANIC! >buffer = :omnii PRIVMSG ChanServ@services.freechat.ods.org :register >#limp_bizkit fred >-freechat.ods.org- *** LocOps -- Received SQUIT services.freechat.ods.org >from services.freechat.ods.org[127.0.0.1] (Services terminating: >Segmentation fault) > >Can you solve this problem me to use this services again? > >Thx for all > >Regards >AngryWolf > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding -- Craig McLure Craig@e-tidalwave.org WaveAdmin on the e-tidalwave IRC Network Ride the Wave! www.e-tidalwave.org _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From r-krisztian at softhome.net Sun Mar 31 07:23:48 2002 From: r-krisztian at softhome.net (=?iso-8859-2?Q?Romek_Kriszti=E1n?=) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] segmentation faults - ircservices 5.0a26 References: Message-ID: <002c01c1d8c8$114555e0$0b00000a@rokusnet.hu> Unreal3.2beta9 Sorry, I've forgot to tell you AgryWolf ----- Original Message ----- From: Craig McLure To: Sent: Sunday, March 31, 2002 5:14 PM Subject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 > What IRCd are you using? > > > >From: Romek Kriszti?n > >Reply-To: ircservices-coding@ircservices.za.net > >To: > >Subject: [IRCServices Coding] segmentation faults - ircservices 5.0a26 > >Date: Sun, 31 Mar 2002 17:10:07 +0200 > > > >Hello! > > > >Your latest alpha version is pretty good, I want to use your program, but I > >had experienced the following errors at the first uses: > > > >*operserv*> exception add +0 > >*** Global -- from services.freechat.ods.org: PANIC! buffer = :AngryWolf > >!operserv :exception add +0 > >*** LocOps -- Received SQUIT services.freechat.ods.org from > >services.freechat.ods.org[127.0.0.1] (Services terminating: Segmentation > >fault) > > > >-freechat.ods.org- *** Global -- from services.freechat.ods.org: PANIC! > >buffer = :Toxyc ! nickserv :help > >-freechat.ods.org- *** LocOps -- Received SQUIT services.freechat.ods.org > >from services.freechat.ods.org[127.0.0.1] (Services terminating: > >Segmentation fault) > > > >-freechat.ods.org- *** Global -- from services.freechat.ods.org: PANIC! > >buffer = :omnii PRIVMSG ChanServ@services.freechat.ods.org :register > >#limp_bizkit fred > >-freechat.ods.org- *** LocOps -- Received SQUIT services.freechat.ods.org > >from services.freechat.ods.org[127.0.0.1] (Services terminating: > >Segmentation fault) > > > >Can you solve this problem me to use this services again? > > > >Thx for all > > > >Regards > >AngryWolf > > > > > >------------------------------------------------------------------ > >To unsubscribe or change your subscription options, visit: > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > > > > -- > Craig McLure > Craig@e-tidalwave.org > WaveAdmin on the e-tidalwave IRC Network > Ride the Wave! www.e-tidalwave.org > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From frostycoolslug at hotmail.com Sun Mar 31 07:33:55 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] segmentation faults - ircservices 5.0a26 Message-ID: have u got a core dump handy? :) and could u paste me yer connection lines pls :) >From: Romek Krisztián >Reply-To: ircservices-coding@ircservices.za.net >To: >Subject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 >Date: Sun, 31 Mar 2002 17:23:48 +0200 > >Unreal3.2beta9 > >Sorry, I've forgot to tell you > >AgryWolf > > >----- Original Message ----- >From: Craig McLure >To: >Sent: Sunday, March 31, 2002 5:14 PM >Subject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 > > > > What IRCd are you using? > > > > > > >From: Romek Krisztián > > >Reply-To: ircservices-coding@ircservices.za.net > > >To: > > >Subject: [IRCServices Coding] segmentation faults - ircservices 5.0a26 > > >Date: Sun, 31 Mar 2002 17:10:07 +0200 > > > > > >Hello! > > > > > >Your latest alpha version is pretty good, I want to use your program, >but >I > > >had experienced the following errors at the first uses: > > > > > >*operserv*> exception add +0 > > >*** Global -- from services.freechat.ods.org: PANIC! buffer = >:AngryWolf > > >!operserv :exception add +0 > > >*** LocOps -- Received SQUIT services.freechat.ods.org from > > >services.freechat.ods.org[127.0.0.1] (Services terminating: >Segmentation > > >fault) > > > > > >-freechat.ods.org- *** Global -- from services.freechat.ods.org: PANIC! > > >buffer = :Toxyc ! nickserv :help > > >-freechat.ods.org- *** LocOps -- Received SQUIT >services.freechat.ods.org > > >from services.freechat.ods.org[127.0.0.1] (Services terminating: > > >Segmentation fault) > > > > > >-freechat.ods.org- *** Global -- from services.freechat.ods.org: PANIC! > > >buffer = :omnii PRIVMSG ChanServ@services.freechat.ods.org :register > > >#limp_bizkit fred > > >-freechat.ods.org- *** LocOps -- Received SQUIT >services.freechat.ods.org > > >from services.freechat.ods.org[127.0.0.1] (Services terminating: > > >Segmentation fault) > > > > > >Can you solve this problem me to use this services again? > > > > > >Thx for all > > > > > >Regards > > >AngryWolf > > > > > > > > >------------------------------------------------------------------ > > >To unsubscribe or change your subscription options, visit: > > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > > > > > > > > > -- > > Craig McLure > > Craig@e-tidalwave.org > > WaveAdmin on the e-tidalwave IRC Network > > Ride the Wave! www.e-tidalwave.org > > > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > ------------------------------------------------------------------ > > To unsubscribe or change your subscription options, visit: > > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding -- Craig McLure Craig@e-tidalwave.org WaveAdmin on the e-tidalwave IRC Network Ride the Wave! www.e-tidalwave.org _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From r-krisztian at softhome.net Sun Mar 31 08:09:48 2002 From: r-krisztian at softhome.net (=?iso-8859-2?Q?Romek_Kriszti=E1n?=) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] segmentation faults - ircservices 5.0a26 References: Message-ID: <000701c1d8ce$80a76080$0b00000a@rokusnet.hu> No, I haven't. Dunno, how to turn on core dumping. The server works good but if more users connect to my server it does many faults I think connection lines is okey. If you want... ------------------- ircservices.conf ------------------ RemoteServer 127.0.0.1 6665 "password" #LocalAddress host.name.here #LocalAddress host.name.here 6677 ServerName "services.freechat.ods.org" ------------------- unrealircd.conf ------------------ link services.freechat.ods.org { username *; hostname 127.0.0.1; bind-ip *; port 6665; hub *; password-connect "password"; password-receive "password"; class servers; options { autoconnect; }; }; AngryWolf ----- Original Message ----- From: Craig McLure To: Sent: Sunday, March 31, 2002 5:33 PM Subject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 > have u got a core dump handy? :) > and could u paste me yer connection lines pls :) > > >From: Romek Kriszti?n > >Reply-To: ircservices-coding@ircservices.za.net > >To: > >Subject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 > >Date: Sun, 31 Mar 2002 17:23:48 +0200 > > > >Unreal3.2beta9 > > > >Sorry, I've forgot to tell you > > > >AgryWolf > > > > > >----- Original Message ----- > >From: Craig McLure > >To: > >Sent: Sunday, March 31, 2002 5:14 PM > >Subject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 > > > > > > > What IRCd are you using? > > > > > > > > > >From: Romek Kriszti?n > > > >Reply-To: ircservices-coding@ircservices.za.net > > > >To: > > > >Subject: [IRCServices Coding] segmentation faults - ircservices 5.0a26 > > > >Date: Sun, 31 Mar 2002 17:10:07 +0200 > > > > > > > >Hello! > > > > > > > >Your latest alpha version is pretty good, I want to use your program, > >but > >I > > > >had experienced the following errors at the first uses: > > > > > > > >*operserv*> exception add +0 > > > >*** Global -- from services.freechat.ods.org: PANIC! buffer = > >:AngryWolf > > > >!operserv :exception add +0 > > > >*** LocOps -- Received SQUIT services.freechat.ods.org from > > > >services.freechat.ods.org[127.0.0.1] (Services terminating: > >Segmentation > > > >fault) > > > > > > > >-freechat.ods.org- *** Global -- from services.freechat.ods.org: PANIC! > > > >buffer = :Toxyc ! nickserv :help > > > >-freechat.ods.org- *** LocOps -- Received SQUIT > >services.freechat.ods.org > > > >from services.freechat.ods.org[127.0.0.1] (Services terminating: > > > >Segmentation fault) > > > > > > > >-freechat.ods.org- *** Global -- from services.freechat.ods.org: PANIC! > > > >buffer = :omnii PRIVMSG ChanServ@services.freechat.ods.org :register > > > >#limp_bizkit fred > > > >-freechat.ods.org- *** LocOps -- Received SQUIT > >services.freechat.ods.org > > > >from services.freechat.ods.org[127.0.0.1] (Services terminating: > > > >Segmentation fault) > > > > > > > >Can you solve this problem me to use this services again? > > > > > > > >Thx for all > > > > > > > >Regards > > > >AngryWolf > > > > > > > > > > > >------------------------------------------------------------------ > > > >To unsubscribe or change your subscription options, visit: > > > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > > > > > > > > > > > > > > -- > > > Craig McLure > > > Craig@e-tidalwave.org > > > WaveAdmin on the e-tidalwave IRC Network > > > Ride the Wave! www.e-tidalwave.org > > > > > > > > > _________________________________________________________________ > > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > > > ------------------------------------------------------------------ > > > To unsubscribe or change your subscription options, visit: > > > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > > >------------------------------------------------------------------ > >To unsubscribe or change your subscription options, visit: > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > > > > -- > Craig McLure > Craig@e-tidalwave.org > WaveAdmin on the e-tidalwave IRC Network > Ride the Wave! www.e-tidalwave.org > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From frostycoolslug at hotmail.com Sun Mar 31 08:16:20 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] segmentation faults - ircservices 5.0a26 Message-ID: well i see nothing wrong with that, althoug you could remove: --- options { autoconnect; }; --- As the IRCd should try and connect to services. As i say we need a core dump.. prolly says somewhere in the manual how to get 1 of these. do u get warnings or nething when compiling and under what OS? >From: Romek Krisztián >Reply-To: ircservices-coding@ircservices.za.net >To: >Subject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 >Date: Sun, 31 Mar 2002 18:09:48 +0200 > > >No, I haven't. Dunno, how to turn on core dumping. > >The server works good but if more users connect to my server it does many >faults > >I think connection lines is okey. If you want... > >------------------- >ircservices.conf >------------------ > >RemoteServer 127.0.0.1 6665 "password" > >#LocalAddress host.name.here >#LocalAddress host.name.here 6677 > >ServerName "services.freechat.ods.org" > >------------------- >unrealircd.conf >------------------ > >link services.freechat.ods.org >{ > username *; > hostname 127.0.0.1; > bind-ip *; > port 6665; > hub *; > password-connect "password"; > password-receive "password"; > class servers; > options { > autoconnect; > }; >}; > > > >AngryWolf > >----- Original Message ----- >From: Craig McLure >To: >Sent: Sunday, March 31, 2002 5:33 PM >Subject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 > > > > have u got a core dump handy? :) > > and could u paste me yer connection lines pls :) > > > > >From: Romek Krisztián > > >Reply-To: ircservices-coding@ircservices.za.net > > >To: > > >Subject: Re: [IRCServices Coding] segmentation faults - ircservices >5.0a26 > > >Date: Sun, 31 Mar 2002 17:23:48 +0200 > > > > > >Unreal3.2beta9 > > > > > >Sorry, I've forgot to tell you > > > > > >AgryWolf > > > > > > > > >----- Original Message ----- > > >From: Craig McLure > > >To: > > >Sent: Sunday, March 31, 2002 5:14 PM > > >Subject: Re: [IRCServices Coding] segmentation faults - ircservices >5.0a26 > > > > > > > > > > What IRCd are you using? > > > > > > > > > > > > >From: Romek Krisztián > > > > >Reply-To: ircservices-coding@ircservices.za.net > > > > >To: > > > > >Subject: [IRCServices Coding] segmentation faults - ircservices >5.0a26 > > > > >Date: Sun, 31 Mar 2002 17:10:07 +0200 > > > > > > > > > >Hello! > > > > > > > > > >Your latest alpha version is pretty good, I want to use your >program, > > >but > > >I > > > > >had experienced the following errors at the first uses: > > > > > > > > > >*operserv*> exception add +0 > > > > >*** Global -- from services.freechat.ods.org: PANIC! buffer = > > >:AngryWolf > > > > >!operserv :exception add +0 > > > > >*** LocOps -- Received SQUIT services.freechat.ods.org from > > > > >services.freechat.ods.org[127.0.0.1] (Services terminating: > > >Segmentation > > > > >fault) > > > > > > > > > >-freechat.ods.org- *** Global -- from services.freechat.ods.org: >PANIC! > > > > >buffer = :Toxyc ! nickserv :help > > > > >-freechat.ods.org- *** LocOps -- Received SQUIT > > >services.freechat.ods.org > > > > >from services.freechat.ods.org[127.0.0.1] (Services terminating: > > > > >Segmentation fault) > > > > > > > > > >-freechat.ods.org- *** Global -- from services.freechat.ods.org: >PANIC! > > > > >buffer = :omnii PRIVMSG ChanServ@services.freechat.ods.org >:register > > > > >#limp_bizkit fred > > > > >-freechat.ods.org- *** LocOps -- Received SQUIT > > >services.freechat.ods.org > > > > >from services.freechat.ods.org[127.0.0.1] (Services terminating: > > > > >Segmentation fault) > > > > > > > > > >Can you solve this problem me to use this services again? > > > > > > > > > >Thx for all > > > > > > > > > >Regards > > > > >AngryWolf > > > > > > > > > > > > > > >------------------------------------------------------------------ > > > > >To unsubscribe or change your subscription options, visit: > > > > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > > > > > > > > > > > > > > > > > > > -- > > > > Craig McLure > > > > Craig@e-tidalwave.org > > > > WaveAdmin on the e-tidalwave IRC Network > > > > Ride the Wave! www.e-tidalwave.org > > > > > > > > > > > > _________________________________________________________________ > > > > Chat with friends online, try MSN Messenger: >http://messenger.msn.com > > > > > > > > ------------------------------------------------------------------ > > > > To unsubscribe or change your subscription options, visit: > > > > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > > > > >------------------------------------------------------------------ > > >To unsubscribe or change your subscription options, visit: > > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > > > > > > > > > -- > > Craig McLure > > Craig@e-tidalwave.org > > WaveAdmin on the e-tidalwave IRC Network > > Ride the Wave! www.e-tidalwave.org > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > ------------------------------------------------------------------ > > To unsubscribe or change your subscription options, visit: > > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding -- Craig McLure Craig@e-tidalwave.org WaveAdmin on the e-tidalwave IRC Network Ride the Wave! www.e-tidalwave.org _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From r-krisztian at softhome.net Sun Mar 31 08:41:32 2002 From: r-krisztian at softhome.net (=?iso-8859-2?Q?Romek_Kriszti=E1n?=) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] segmentation faults - ircservices 5.0a26 References: Message-ID: <000b01c1d8d2$ee0c4d80$0b00000a@rokusnet.hu> Dunno how to make a core dump but would like to. I'll do one if I found it how to make one in the docs I have RedHat Linux 7.1 I have only one warning, about KillClonesAkill directive, dunno what did it say but i think it told me not to use. That's all. I'm asking now how to make a core dump... AngryWolf ----- Original Message ----- From: Craig McLure To: Sent: Sunday, March 31, 2002 6:16 PM Subject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 > well i see nothing wrong with that, althoug you could remove: > > --- > options { > autoconnect; > }; > --- > As the IRCd should try and connect to services. > > As i say we need a core dump.. prolly says somewhere in the manual how to > get 1 of these. > do u get warnings or nething when compiling and under what OS? > > >From: Romek Kriszti?n > >Reply-To: ircservices-coding@ircservices.za.net > >To: > >Subject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 > >Date: Sun, 31 Mar 2002 18:09:48 +0200 > > > > > >No, I haven't. Dunno, how to turn on core dumping. > > > >The server works good but if more users connect to my server it does many > >faults > > > >I think connection lines is okey. If you want... > > > >------------------- > >ircservices.conf > >------------------ > > > >RemoteServer 127.0.0.1 6665 "password" > > > >#LocalAddress host.name.here > >#LocalAddress host.name.here 6677 > > > >ServerName "services.freechat.ods.org" > > > >------------------- > >unrealircd.conf > >------------------ > > > >link services.freechat.ods.org > >{ > > username *; > > hostname 127.0.0.1; > > bind-ip *; > > port 6665; > > hub *; > > password-connect "password"; > > password-receive "password"; > > class servers; > > options { > > autoconnect; > > }; > >}; > > > > > > > >AngryWolf > > > >----- Original Message ----- > >From: Craig McLure > >To: > >Sent: Sunday, March 31, 2002 5:33 PM > >Subject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 > > > > > > > have u got a core dump handy? :) > > > and could u paste me yer connection lines pls :) > > > > > > >From: Romek Kriszti?n > > > >Reply-To: ircservices-coding@ircservices.za.net > > > >To: > > > >Subject: Re: [IRCServices Coding] segmentation faults - ircservices > >5.0a26 > > > >Date: Sun, 31 Mar 2002 17:23:48 +0200 > > > > > > > >Unreal3.2beta9 > > > > > > > >Sorry, I've forgot to tell you > > > > > > > >AgryWolf > > > > > > > > > > > >----- Original Message ----- > > > >From: Craig McLure > > > >To: > > > >Sent: Sunday, March 31, 2002 5:14 PM > > > >Subject: Re: [IRCServices Coding] segmentation faults - ircservices > >5.0a26 > > > > > > > > > > > > > What IRCd are you using? > > > > > > > > > > > > > > > >From: Romek Kriszti?n > > > > > >Reply-To: ircservices-coding@ircservices.za.net > > > > > >To: > > > > > >Subject: [IRCServices Coding] segmentation faults - ircservices > >5.0a26 > > > > > >Date: Sun, 31 Mar 2002 17:10:07 +0200 > > > > > > > > > > > >Hello! > > > > > > > > > > > >Your latest alpha version is pretty good, I want to use your > >program, > > > >but > > > >I > > > > > >had experienced the following errors at the first uses: > > > > > > > > > > > >*operserv*> exception add +0 > > > > > >*** Global -- from services.freechat.ods.org: PANIC! buffer = > > > >:AngryWolf > > > > > >!operserv :exception add +0 > > > > > >*** LocOps -- Received SQUIT services.freechat.ods.org from > > > > > >services.freechat.ods.org[127.0.0.1] (Services terminating: > > > >Segmentation > > > > > >fault) > > > > > > > > > > > >-fre