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) > > > > > > > > > > > >-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 > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From r-krisztian at softhome.net Sun Mar 31 09:40:44 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: <000b01c1d8d2$ee0c4d80$0b00000a@rokusnet.hu> Message-ID: <001501c1d8db$325ede00$0b00000a@rokusnet.hu> Okey, I know now that KillClonesAKill is no longer (a25), but KillClonesAutoKill (a26), and that's ok. I know that if I type /ns help and didn't specify more parameters then Services go down. What can I do? ----- Original Message ----- From: Romek Kriszti?n To: Sent: Sunday, March 31, 2002 6:41 PM Subject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 > > 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) > > > > > > > > > > > > > >-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 > > > > ------------------------------------------------------------------ > > 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 Sun Mar 31 10:19:41 2002 From: master at xchat.gr (George Stamatiou) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] segmentation faults - ircservices 5.0a26 References: <000b01c1d8d2$ee0c4d80$0b00000a@rokusnet.hu> <001501c1d8db$325ede00$0b00000a@rokusnet.hu> Message-ID: <3CA7533D.9090100@xchat.gr> well, seems that i have the same problem. when i do a /ns help serverices crashes.if i replace the strtok_remaining(); with strtok(NULL, ""); and it works ok. I don't know what's going wrong. I have bahamut 1.4(31).the version before (a25) hasn't got that problem. Thanks From r-krisztian at softhome.net Sun Mar 31 10:17:18 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: <000b01c1d8d2$ee0c4d80$0b00000a@rokusnet.hu> <001501c1d8db$325ede00$0b00000a@rokusnet.hu> <3CA7533D.9090100@xchat.gr> Message-ID: <000b01c1d8e0$505360c0$0b00000a@rokusnet.hu> Thank you for your message! It's the same if I don't use enough parameters for /cs register (without description). And also in version a25 it was okey. How did you do that? Where is that line to modify? Which file? ----- Original Message ----- From: George Stamatiou To: Sent: Sunday, March 31, 2002 8:19 PM Subject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 > well, seems that i have the same problem. > when i do a /ns help serverices crashes.if i replace the > strtok_remaining(); with strtok(NULL, ""); and it works ok. > I don't know what's going wrong. > I have bahamut 1.4(31).the version before (a25) hasn't got that problem. > > Thanks > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From master at xchat.gr Sun Mar 31 10:32:58 2002 From: master at xchat.gr (George Stamatiou) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] segmentation faults - ircservices 5.0a26 References: <000b01c1d8d2$ee0c4d80$0b00000a@rokusnet.hu> <001501c1d8db$325ede00$0b00000a@rokusnet.hu> <3CA7533D.9090100@xchat.gr> <000b01c1d8e0$505360c0$0b00000a@rokusnet.hu> Message-ID: <3CA7565A.7030507@xchat.gr> well.... there are a lot that you have to change.there are a lot of files with this line. only for the /ns help is on /modules/nickserv.then pico main.c.then on function static void do_help(User *u) { char *cmd = strtok_remaining(); replace the last line with the char *cmd = strtok(NULL, ""); it's ok ONLY for the /ns help.i hope there is an easier way to replace all and not by hand :/ Romek Kriszti?n wrote: >Thank you for your message! > >It's the same if I don't use enough parameters for /cs register (without >description). And also in version a25 it was okey. > >How did you do that? Where is that line to modify? Which file? > >----- Original Message ----- >From: George Stamatiou >To: >Sent: Sunday, March 31, 2002 8:19 PM >Subject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 > > >>well, seems that i have the same problem. >>when i do a /ns help serverices crashes.if i replace the >>strtok_remaining(); with strtok(NULL, ""); and it works ok. >>I don't know what's going wrong. >>I have bahamut 1.4(31).the version before (a25) hasn't got that problem. >> >>Thanks >> >> >>------------------------------------------------------------------ >>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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20020331/e17e621c/attachment.html From r-krisztian at softhome.net Sun Mar 31 11:01: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: <000b01c1d8d2$ee0c4d80$0b00000a@rokusnet.hu> <001501c1d8db$325ede00$0b00000a@rokusnet.hu> <3CA7533D.9090100@xchat.gr> <000b01c1d8e0$505360c0$0b00000a@rokusnet.hu> <3CA7565A.7030507@xchat.gr> Message-ID: <001e01c1d8e6$861e60a0$0b00000a@rokusnet.hu> Okey, it's now working, thank you! (I've replaced them by hand :)))) ircservices is too good to keep bugs in there! :)) Thx Lots of love AngryWolf ----- Original Message ----- From: George Stamatiou To: ircservices-coding@ircservices.za.net Sent: Sunday, March 31, 2002 8:32 PM Subject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 well.... there are a lot that you have to change.there are a lot of files with this line. only for the /ns help is on /modules/nickserv.then pico main.c.then on function static void do_help(User *u) { char *cmd = strtok_remaining(); replace the last line with the char *cmd = strtok(NULL, ""); it's ok ONLY for the /ns help.i hope there is an easier way to replace all and not by hand :/ Romek Kriszti?n wrote: Thank you for your message!It's the same if I don't use enough parameters for /cs register (withoutdescription). And also in version a25 it was okey.How did you do that? Where is that line to modify? Which file?----- Original Message -----From: George Stamatiou To: Sent: Sunday, March 31, 2002 8:19 PMSubject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 well, seems that i have the same problem.when i do a /ns help serverices crashes.if i replace thestrtok_remaining(); with strtok(NULL, ""); and it works ok.I don't know what's going wrong.I have bahamut 1.4(31).the version before (a25) hasn't got that problem.Thanks-------------------------------------------------------------- ----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 r-krisztian at softhome.net Sun Mar 31 11:05:59 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: <000b01c1d8d2$ee0c4d80$0b00000a@rokusnet.hu> <001501c1d8db$325ede00$0b00000a@rokusnet.hu> <3CA7533D.9090100@xchat.gr> <000b01c1d8e0$505360c0$0b00000a@rokusnet.hu> <3CA7565A.7030507@xchat.gr> Message-ID: <002301c1d8e7$1c2953c0$0b00000a@rokusnet.hu> Ahh, I was too fast. Sorry. If I use /cs register and give a description, the only one word is added to the description. So strtok(NULL, "") gives back one parameter, strtok_remaining() gives all that is remaining. Can you help me? AngryWolf ----- Original Message ----- From: George Stamatiou To: ircservices-coding@ircservices.za.net Sent: Sunday, March 31, 2002 8:32 PM Subject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 well.... there are a lot that you have to change.there are a lot of files with this line. only for the /ns help is on /modules/nickserv.then pico main.c.then on function static void do_help(User *u) { char *cmd = strtok_remaining(); replace the last line with the char *cmd = strtok(NULL, ""); it's ok ONLY for the /ns help.i hope there is an easier way to replace all and not by hand :/ Romek Kriszti?n wrote: Thank you for your message!It's the same if I don't use enough parameters for /cs register (withoutdescription). And also in version a25 it was okey.How did you do that? Where is that line to modify? Which file?----- Original Message -----From: George Stamatiou To: Sent: Sunday, March 31, 2002 8:19 PMSubject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 well, seems that i have the same problem.when i do a /ns help serverices crashes.if i replace thestrtok_remaining(); with strtok(NULL, ""); and it works ok.I don't know what's going wrong.I have bahamut 1.4(31).the version before (a25) hasn't got that problem.Thanks-------------------------------------------------------------- ----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 Apr 1 11:28:15 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] segmentation faults - ircservices 5.0a26 Message-ID: <3ca7c5d7.15076@achurch.org> >well, seems that i have the same problem. >when i do a /ns help serverices crashes.if i replace the >strtok_remaining(); with strtok(NULL, ""); and it works ok. >I don't know what's going wrong. >I have bahamut 1.4(31).the version before (a25) hasn't got that problem. Fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ From r-krisztian at softhome.net Sun Mar 31 22:23:42 2002 From: r-krisztian at softhome.net (Romek Krisztián) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] segmentation faults - ircservices 5.0a26 References: <3ca7c5d7.15076@achurch.org> Message-ID: <001d01c1d945$caa275e0$0b00000a@rokusnet.hu> > Fixed, thanks. That's good but I would like to have the next release. Can you tell me when will it be downloadable? Thank you! AngryWolf From achurch at achurch.org Mon Apr 1 15:41:38 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] segmentation faults - ircservices 5.0a26 Message-ID: <3ca801c2.17515@achurch.org> >> Fixed, thanks. > >That's good but I would like to have the next release. Can you tell me when >will it be downloadable? Thank you! When I release a new alpha, whenever that is. In the meantime, apply this patch: --- misc.c 27 Mar 2002 12:28:25 -0000 2.17 +++ misc.c 1 Apr 2002 02:28:15 -0000 2.18 @@ -213,8 +213,10 @@ char *strtok_remaining(void) { char *s = strtok(NULL, ""); - while (isspace(*s)) - s++; + if (s) { + while (isspace(*s)) + s++; + } return s; } --Andrew Church achurch@achurch.org http://achurch.org/ From r-krisztian at softhome.net Mon Apr 1 03:20:40 2002 From: r-krisztian at softhome.net (Romek Krisztián) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] segmentation faults - ircservices 5.0a26 References: <3ca801c2.17515@achurch.org> Message-ID: <000e01c1d96f$46e38e40$0b00000a@rokusnet.hu> This patch is working! Thx! AngryWolf ----- Original Message ----- From: Andrew Church To: Sent: Monday, April 01, 2002 8:41 AM Subject: Re: [IRCServices Coding] segmentation faults - ircservices 5.0a26 > >> Fixed, thanks. > > > >That's good but I would like to have the next release. Can you tell me when > >will it be downloadable? Thank you! > > When I release a new alpha, whenever that is. In the meantime, apply > this patch: > > --- misc.c 27 Mar 2002 12:28:25 -0000 2.17 > +++ misc.c 1 Apr 2002 02:28:15 -0000 2.18 > @@ -213,8 +213,10 @@ > char *strtok_remaining(void) > { > char *s = strtok(NULL, ""); > - while (isspace(*s)) > - s++; > + if (s) { > + while (isspace(*s)) > + s++; > + } > return s; > } > > > --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 master at xchat.gr Tue Apr 2 04:17:31 2002 From: master at xchat.gr (George Stamatiou) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] Unknown command raw - ircservices 5.0a26 References: <3ca801c2.17515@achurch.org> <000e01c1d96f$46e38e40$0b00000a@rokusnet.hu> Message-ID: <3CA9A15B.3000000@xchat.gr> I don't know if mine services has that problem.i think that no. try /os raw.you get a -OperServ- Unknown command raw. Type /msg OperServ HELP for help. From master at xchat.gr Tue Apr 2 04:19:46 2002 From: master at xchat.gr (George Stamatiou) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] util.c - ircservices 5.0a26 References: <3ca801c2.17515@achurch.org> <000e01c1d96f$46e38e40$0b00000a@rokusnet.hu> Message-ID: <3CA9A1E2.3050209@xchat.gr> hmm i have the force nick change and the nickserv shows me that i'm gonna bwe disconnect me . the error propably is on util.c. change the DISCONNECT_IN_1_MINUTE with FORCENICKCHANGE_IN_1_MINUTE and DISCONNECT_IN_20_SECONDS with FORCENICKCHANGE_IN_20_SECONDS From achurch at achurch.org Tue Apr 2 21:50:12 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] Unknown command raw - ircservices 5.0a26 Message-ID: <3ca9a987.24522@achurch.org> >I don't know if mine services has that problem.i think that no. >try /os raw.you get a -OperServ- Unknown command raw. Type /msg OperServ >HELP for help. RAW is disabled by default; see the AllowRaw directive (this was missing from the Changes file). --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Apr 2 21:52:26 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] util.c - ircservices 5.0a26 Message-ID: <3ca9a9b5.24531@achurch.org> >hmm i have the force nick change and the nickserv shows me that i'm >gonna bwe disconnect me . >the error propably is on util.c. >change the DISCONNECT_IN_1_MINUTE with FORCENICKCHANGE_IN_1_MINUTE >and >DISCONNECT_IN_20_SECONDS with FORCENICKCHANGE_IN_20_SECONDS These are correct as written. Have you actually enabled NSForceNickChange and does your IRC server support it? Check the log for possible error messages. --Andrew Church achurch@achurch.org http://achurch.org/ From k.hawkes at zombies.force9.net Tue Apr 2 10:12:50 2002 From: k.hawkes at zombies.force9.net (K. Hawkes) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] Modules? References: <001801c1d896$af9c13a0$02c8a8c0@nygmatech.local> Message-ID: <00e001c1da77$de790100$01000001@quinn> What is this 'trircd' I've not heard of it before, do you know where I can obtain more information on it? What's it based on etc... Thanks Kris ----- Original Message ----- From: "Yusuf Iskenderoglu" To: Sent: Sunday, March 31, 2002 10:29 AM Subject: AW: [IRCServices Coding] Modules? 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 > ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding --- Outgoing mail is certified Virus Free by AVG 6. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.343 / Virus Database: 190 - Release Date: 22/03/2002 From uhc0 at rz.uni-karlsruhe.de Tue Apr 2 12:27:07 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: <00e001c1da77$de790100$01000001@quinn> Message-ID: <000601c1da84$d410bed0$04000100@nygmatech.local> TR-IRCD is the name of the ircd & services development line, of which I am the main coder. To keep it short, the ircd versions 3.x and 4.x are based on Bahamut. In order not to convert this mailing list to a publicity list, I do not explain what changes it has, you can read them all on http://tr-ircd.sourceforge.net or http://www.tr-ircd.net The version 5.x is no longer directly based on anything, but you will notice hybrid-7 influenced code at most, and it has unique technologies like modular channelmodes, which do not exist on any other ircd. It also incorporates a "run as" technique which makes it be able to support Bahamut both pelennor and halcyon by disabling extra features and using protocol modules. The services development was started to make ircservices compatible with the ircd. Thanks Andrews protocol module idea, ircservices 5.x is able to support trircd, and the TR-IRCD team therefore decided to stop services development after ircservices 5.x is released. Hoping that noone is disturbed with this email, since it does not have anything directly to do with ircservices coding... 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 K. Hawkes > Gesendet: Dienstag, 2. April 2002 20:13 > An: ircservices-coding@ircservices.za.net > Betreff: Re: [IRCServices Coding] Modules? > > > What is this 'trircd' I've not heard of it before, do you > know where I can obtain more information on it? What's it > based on etc... > > Thanks > > Kris > ----- Original Message ----- > From: "Yusuf Iskenderoglu" > To: > Sent: Sunday, March 31, 2002 10:29 AM > Subject: AW: [IRCServices Coding] Modules? > > > > 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 > > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-cod ing --- Outgoing mail is certified Virus Free by AVG 6. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.343 / Virus Database: 190 - Release Date: 22/03/2002 ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Fri Apr 5 18:37:01 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] Services 5.0 alpha 27 released Message-ID: <3cad76cc.57473@achurch.org> Services 5.0 alpha 27 is out at the usual place. The big change, and the one I'd most appreciate bug reports or other comments about, is the change to the expiration functionality: expirations are now handled when a nick/channel/autokill/exception/S-line is looked up, either by name/mask or via first_xxx()/next_xxx() iteration, rather than by periodically going through every registered item and checking for expiration. This has the advantage that an expired entry is _never_ seen by the code--this includes both the SxLINE ADD bug mentioned earlier as well as 1-minute autokills lasting until the next expiration (sometimes 30 minutes later) and similar situations. On the other hand, it's theoretically possible for records to be left in the database forever if they're never touched, taking up extra space--though this won't happen with the current database format, since it cycles through all records while writing them to disk. Note that I'm aware that the mail-auth and memo expiration isn't updated to use this system yet, so don't bother telling me about that.(: Changes in version 5.0 alpha 27 ------------------------------- 2002/04/05 Reworked expiration logic to avoid long blocks checking for expired data and missed expirations. 2002/04/05 Fixed improper aborts when reading in corrupted databases. 2002/04/01 Fixed crash when certain commands did not receive enough parameters. Reported by several people. --Andrew Church achurch@achurch.org http://achurch.org/ From r-krisztian at softhome.net Fri Apr 5 06:30:12 2002 From: r-krisztian at softhome.net (Romek Krisztián) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] ircservices5.0a27 -> /ns set info (Another bug?) References: <3cad76cc.57473@achurch.org> Message-ID: <004001c1dcae$6a496660$0b00000a@rokusnet.hu> Dunno if another users told you this bug, but /ns set info accepts only one word, not more. Can you fix it? AngryWolf From WaZtReLoS at vip.gr Fri Apr 5 10:15:23 2002 From: WaZtReLoS at vip.gr (Stefanos Falkonakis) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] ircservices5.0a27 -> /ns set info (Another bug?) Message-ID: <200204052115.AA2408055194@vip.gr> I will try, if i found it i will email you :) ?????????? ??? ??????, email ?? ????????????? ?? 1 ?????! Sponsored by NET FORCE http://www.vip.gr ????????? ????????? INTERNET ?? ??????? ! ______________________________________________________________________ From master at xchat.gr Sat Apr 6 21:26:35 2002 From: master at xchat.gr (George Stamatiou) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] ircservices5.0a26 /cs set secureops References: <3cad76cc.57473@achurch.org> <004001c1dcae$6a496660$0b00000a@rokusnet.hu> Message-ID: <3CAFD88B.7030505@xchat.gr> Is there any problem with secureops ? i have :/ i have enabled it but chanserv never deop any user with 0 access on the channel. my ircd is bahamut and the conf lines are ok. From r-krisztian at softhome.net Sun Apr 7 01:20:10 2002 From: r-krisztian at softhome.net (Romek Krisztián) Date: Sat Oct 23 23:09:19 2004 Subject: [IRCServices Coding] ircservices5.0a26 /cs set secureops References: <3cad76cc.57473@achurch.org> <004001c1dcae$6a496660$0b00000a@rokusnet.hu> <3CAFD88B.7030505@xchat.gr> Message-ID: <001a01c1de15$6dc82fc0$0b00000a@rokusnet.hu> ./cs set #channel restricted on AngryWolf ----- Original Message ----- From: George Stamatiou To: Sent: Sunday, April 07, 2002 7:26 AM Subject: Re: [IRCServices Coding] ircservices5.0a26 /cs set secureops > Is there any problem with secureops ? i have :/ > i have enabled it but chanserv never deop any user with 0 access on the > channel. > my ircd is bahamut and the conf lines are ok. > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From Georges at Berscheid.lu Sun Apr 7 01:46:20 2002 From: Georges at Berscheid.lu (Georges Berscheid) Date: Sat Oct 23 23:09:19 2004 Subject: AW: [IRCServices Coding] ircservices5.0a26 /cs set secureops In-Reply-To: <001a01c1de15$6dc82fc0$0b00000a@rokusnet.hu> Message-ID: The Restricted access option disallows these users (with <= 0 access level) to stay on the channel. They will be kick-banned instead. Are you sure secureops is really set on your channel ? Check it with /cs info #channel. On the other hand you must have U-Lines for ircservices set, to allow them to change modes. Georges -----Ursprungliche Nachricht----- Von: ircservices-coding-admin@ircservices.za.net [mailto:ircservices-coding-admin@ircservices.za.net]Im Auftrag von Romek Kriszti? Gesendet: Sonntag, 7. April 2002 11:20 An: ircservices-coding@ircservices.za.net Betreff: Re: [IRCServices Coding] ircservices5.0a26 /cs set secureops ./cs set #channel restricted on AngryWolf ----- Original Message ----- From: George Stamatiou To: Sent: Sunday, April 07, 2002 7:26 AM Subject: Re: [IRCServices Coding] ircservices5.0a26 /cs set secureops > Is there any problem with secureops ? i have :/ > i have enabled it but chanserv never deop any user with 0 access on the > channel. > my ircd is bahamut and the conf lines are ok. > > > ------------------------------------------------------------------ > 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 Sun Apr 7 05:33:11 2002 From: master at xchat.gr (George Stamatiou) Date: Sat Oct 23 23:09:20 2004 Subject: AW: [IRCServices Coding] ircservices5.0a26 /cs set secureops References: Message-ID: <3CB03C87.4050104@xchat.gr> The problem is not that i dont want users with 0 level to join on my channel. The problem is that somebody who has access in channel can give op with the command /mode #channel +o nick. -ChanServ- Options: Topic Retention, Secure Ops, Secure, Op-Notice here are the modes of my channel.Chanserv never deops them :/ Georges Berscheid wrote: >The Restricted access option disallows these users (with <= 0 access level) >to stay on the channel. They will be kick-banned instead. >Are you sure secureops is really set on your channel ? Check it with /cs >info #channel. >On the other hand you must have U-Lines for ircservices set, to allow them >to change modes. > >Georges > > >-----Ursprungliche Nachricht----- >Von: ircservices-coding-admin@ircservices.za.net >[mailto:ircservices-coding-admin@ircservices.za.net]Im Auftrag von Romek >Kriszti? >Gesendet: Sonntag, 7. April 2002 11:20 >An: ircservices-coding@ircservices.za.net >Betreff: Re: [IRCServices Coding] ircservices5.0a26 /cs set secureops > > >./cs set #channel restricted on > >AngryWolf > >----- Original Message ----- >From: George Stamatiou >To: >Sent: Sunday, April 07, 2002 7:26 AM >Subject: Re: [IRCServices Coding] ircservices5.0a26 /cs set secureops > > >>Is there any problem with secureops ? i have :/ >>i have enabled it but chanserv never deop any user with 0 access on the >>channel. >>my ircd is bahamut and the conf lines are ok. >> >> >>------------------------------------------------------------------ >>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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20020407/a78feac1/attachment.htm From dan at viaraix.net Sun Apr 7 16:37:34 2002 From: dan at viaraix.net (Dan Jones) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] segfault on /msg XXXXServ help (5.0a26) Message-ID: <3CB0D83E.7020303@viaraix.net> Hi, Installed IRCServices and got them configured/linked etc... all fine and can perform most commands except 'help' [Apr 07 20:40:01 2002] operserv/main: ViaraiX: help [Apr 07 20:40:01 2002] PANIC! buffer = :ViaraiX PRIVMSG operserv :help [Apr 07 20:40:01 2002] Services terminating: Segmentation fault (also tried other services and ended in same result) Any help will be greatly appreciated. Best Regards Dan 'ViaraiX' Jones From gue_raja at yahoo.com Sun Apr 7 20:43:25 2002 From: gue_raja at yahoo.com (_DaruDoanK_) Date: Sat Oct 23 23:09:20 2004 Subject: Fw: [IRCServices Coding] URGENT Message-ID: <011a01c1deaf$89ff0840$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 does not changed ... why ??? > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Mon Apr 8 13:35:48 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] segfault on /msg XXXXServ help (5.0a26) Message-ID: <3cb11e2e.67421@achurch.org> Fixed in alpha 27. Please stay current. >Hi, > >Installed IRCServices and got them configured/linked etc... all fine and >can perform most commands except 'help' > >[Apr 07 20:40:01 2002] operserv/main: ViaraiX: help >[Apr 07 20:40:01 2002] PANIC! buffer = :ViaraiX PRIVMSG operserv :help >[Apr 07 20:40:01 2002] Services terminating: Segmentation fault > >(also tried other services and ended in same result) > >Any help will be greatly appreciated. > >Best Regards > >Dan 'ViaraiX' Jones > >------------------------------------------------------------------ >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 master at xchat.gr Mon Apr 8 07:09:41 2002 From: master at xchat.gr (George Stamatiou) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] /cs set secureops References: <3cb11e2e.67421@achurch.org> Message-ID: <3CB1A4A5.8020600@xchat.gr> Well.The same problem i have with 5.0a27. ChanServ DOES NOT deop the user who hasn't access in any channel and anyone who is operator can give op with the command /mode #channel +o user.I tried the 4.5.27 and is working properly. my ircd is bahamut 1.4(31). has anybody any idea ? From dan at viaraix.net Mon Apr 8 07:20:15 2002 From: dan at viaraix.net (Dan Jones) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] segfault on /msg XXXXServ help (5.0a26) References: <3cb11e2e.67421@achurch.org> Message-ID: <3CB1A71F.30600@viaraix.net> Apr 5 01:33 ircservices-5.0a26 :/ soz, must have downloaded it a few hours before 27 was released Andrew Church wrote: > Fixed in alpha 27. Please stay current. > From adrian.cantrill at dial.pipex.com Mon Apr 8 09:04:17 2002 From: adrian.cantrill at dial.pipex.com (Adrian Cantrill) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] DB Conversion Message-ID: <001601c1df17$09a11cc0$0100a8c0@ado> Hi, I am hoping someone will have some idea of this one, because its driving me insane hehe :) OK.. I recently decided to switch from Epona 1.4.10 to ircservices due to the ability not to have to re-identify if you change nicks i.e Ado-> Ado|away -> Ado dosnt require me to re-identify =) The problem is, I need if possible to preserve my existing channel and nicks records but when I attempt a import I get the following output. Line 3618: Channel "#" not supported Line 3931: Channel "#" not supported Line 3972: Channel "#" not supported Line 4021: Channel "#" not supported Line 4045: Channel "#" not supported Line 4102: Channel "#" not supported Line 4175: Channel "#" not supported Line 4235: Channel "#" not supported Line 4295: Channel "#" not supported Line 4340: Channel "#" not supported Line 4441: Channel "#" not supported Line 4490: Channel "#" not supported Line 4839: Channel "#" not supported Line 4892: Channel "#" not supported Line 4965: Channel "#" not supported Line 5002: Channel "#" not supported Line 5063: Channel "#" not supported Line 5100: Channel "#" not supported Line 5173: Channel "#" not supported Line 5234: Channel "#" not supported Line 5335: Channel "#" not supported All the nicks import fine... just non of my channels. Any ideas peeps ? Thanks Adrian From achurch at achurch.org Tue Apr 9 01:33:04 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] DB Conversion Message-ID: <3cb1c6df.10561@achurch.org> This is a stupid bug... fixed for alpha 28, thanks. Also, though I presume you read the notice on the download page, be aware that alpha versions are not suited for using on live networks and are likely to crash or experience other problems often. Bug reports of such problems are welcome, but don't expect much sympathy if your users complain. --Andrew Church achurch@achurch.org http://achurch.org/ >Hi, > >I am hoping someone will have some idea of this one, because its driving >me insane hehe :) >OK.. I recently decided to switch from Epona 1.4.10 to ircservices due >to the ability not to have to re-identify if you change nicks i.e > >Ado-> Ado|away -> Ado dosnt require me to re-identify =) > >The problem is, I need if possible to preserve my existing channel and >nicks records but when I attempt a import I get the following output. > >Line 3618: Channel "#" not supported >Line 3931: Channel "#" not supported >Line 3972: Channel "#" not supported >Line 4021: Channel "#" not supported >Line 4045: Channel "#" not supported >Line 4102: Channel "#" not supported >Line 4175: Channel "#" not supported >Line 4235: Channel "#" not supported >Line 4295: Channel "#" not supported >Line 4340: Channel "#" not supported >Line 4441: Channel "#" not supported >Line 4490: Channel "#" not supported >Line 4839: Channel "#" not supported >Line 4892: Channel "#" not supported >Line 4965: Channel "#" not supported >Line 5002: Channel "#" not supported >Line 5063: Channel "#" not supported >Line 5100: Channel "#" not supported >Line 5173: Channel "#" not supported >Line 5234: Channel "#" not supported >Line 5335: Channel "#" not supported > >All the nicks import fine... just non of my channels. > >Any ideas peeps ? > >Thanks > >Adrian > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From dan at viaraix.net Mon Apr 8 10:11:57 2002 From: dan at viaraix.net (Dan Jones) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] services http module Message-ID: <3CB1CF5D.7040204@viaraix.net> Is it possible (or if not can this be considered as a suggestion) to customise the http output. atm for main page i just have Not Found The requested resource could not be found. which i would like to replace with something more informative From r-krisztian at softhome.net Mon Apr 8 10:31:11 2002 From: r-krisztian at softhome.net (Romek =?iso-8859-1?q?Kriszti=E9n?=) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] services http module In-Reply-To: <3CB1CF5D.7040204@viaraix.net> References: <3CB1CF5D.7040204@viaraix.net> Message-ID: <02040819311101.06234@adsl52096.vnet.hu> Me too, I can browse only dbaccess. AngryWolf 2002. ?prilis 8. 19:11 d?tummal ezt ?rta: > Is it possible (or if not can this be considered as a suggestion) to > customise the http output. > > atm for main page i just have > > Not Found > The requested resource could not be found. > > which i would like to replace with something more informative > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From adrian.cantrill at dial.pipex.com Mon Apr 8 10:24:24 2002 From: adrian.cantrill at dial.pipex.com (Adrian Cantrill) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] DB Conversion In-Reply-To: <3cb1c6df.10561@achurch.org> Message-ID: <000001c1df22$3ae4cd80$0100a8c0@ado> Hi, Thanks for the info, yes I realise it's a project in devel :) but its seems more fit for purpose than epona. Any chance on being able to get hold of a patch or a copy of the changes necessary?. Ideally I want help test this and my users (who are picky) will hopefully identify a lot of bugs for you. I understand the alpha status and am willing to accept any bugs etc. Thanks in advance Adrian -----Original Message----- From: ircservices-coding-admin@ircservices.za.net [mailto:ircservices-coding-admin@ircservices.za.net] On Behalf Of Andrew Church Sent: 08 April 2002 17:33 To: ircservices-coding@ircservices.za.net Subject: Re: [IRCServices Coding] DB Conversion This is a stupid bug... fixed for alpha 28, thanks. Also, though I presume you read the notice on the download page, be aware that alpha versions are not suited for using on live networks and are likely to crash or experience other problems often. Bug reports of such problems are welcome, but don't expect much sympathy if your users complain. --Andrew Church achurch@achurch.org http://achurch.org/ From frostycoolslug at hotmail.com Mon Apr 8 17:28:40 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] services http module Message-ID: me too.. :) >From: Romek Krisztién >Reply-To: ircservices-coding@ircservices.za.net >To: ircservices-coding@ircservices.za.net >Subject: Re: [IRCServices Coding] services http module >Date: Mon, 8 Apr 2002 19:31:11 +0200 > >Me too, I can browse only dbaccess. > >AngryWolf > >2002. április 8. 19:11 dátummal ezt írta: > > Is it possible (or if not can this be considered as a suggestion) to > > customise the http output. > > > > atm for main page i just have > > > > Not Found > > The requested resource could not be found. > > > > which i would like to replace with something more informative > > > > ------------------------------------------------------------------ > > 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 _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From achurch at achurch.org Tue Apr 9 10:09:30 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] DB Conversion Message-ID: <3cb23f8d.11032@achurch.org> Sorry, I meant to include the patch in my previous message. Now you can see just how stupid a bug it was. ;) --- modules/misc/xml-import.c 6 Feb 2002 23:43:38 -0000 2.8 +++ modules/misc/xml-import.c 8 Apr 2002 16:31:12 -0000 2.9 @@ -1476,7 +1476,7 @@ error(" tag missing from channel, ignoring"); my_free_channelinfo(ci); return CONTINUE; - } else if (strcmp(ci->name, "#")) { + } else if (strcmp(ci->name, "#") == 0) { error("Channel \"#\" not supported"); my_free_channelinfo(ci); return CONTINUE; --Andrew Church achurch@achurch.org http://achurch.org/ >Hi, > >Thanks for the info, yes I realise it's a project in devel :) but its >seems more fit for purpose than epona. Any chance on being able to get >hold of a patch or a copy of the changes necessary?. Ideally I want help >test this and my users (who are picky) will hopefully identify a lot of >bugs for you. I understand the alpha status and am willing to accept any >bugs etc. > >Thanks in advance > >Adrian > > >-----Original Message----- >From: ircservices-coding-admin@ircservices.za.net >[mailto:ircservices-coding-admin@ircservices.za.net] On Behalf Of Andrew >Church >Sent: 08 April 2002 17:33 >To: ircservices-coding@ircservices.za.net >Subject: Re: [IRCServices Coding] DB Conversion > > This is a stupid bug... fixed for alpha 28, thanks. Also, though I >presume you read the notice on the download page, be aware that alpha >versions are not suited for using on live networks and are likely to >crash >or experience other problems often. Bug reports of such problems are >welcome, but don't expect much sympathy if your users complain. > > --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 Apr 9 10:11:21 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] services http module Message-ID: <3cb2406f.11044@achurch.org> The Services HTTP server is not intended to be a full-fledged server, only to provide certain information through the HTTP protocol. If you want an index page or something of the sort, put it up on a separate (real) HTTP server. I'm considering adding a feature to redirect / accesses to another URL, but I have no plans to add any file-serving or similar functions. --Andrew Church achurch@achurch.org http://achurch.org/ >Is it possible (or if not can this be considered as a suggestion) to >customise the http output. > >atm for main page i just have > > Not Found > The requested resource could not be found. > >which i would like to replace with something more informative > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From ron885 at axenet.org Mon Apr 8 22:06:12 2002 From: ron885 at axenet.org (Ron885) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] Database Module Message-ID: <000d01c1df84$4abc5c20$8d126244@HOME> Ok, i THINK this was discussed once before, but i'm not sure. Are there any plans to move for instance, the loading and saving of the nick db into the nickserv module directory, and same for chanserv, etc. I am trying to make some modules that use their own dbs and I am being quite unccessful as of now, but I will continue to try. Any guidance in adding a DB would be quite welcome. --- Ron885 NetAdmin @ irc.axenet.org From achurch at achurch.org Tue Apr 9 14:24:09 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] Database Module Message-ID: <3cb27b93.11172@achurch.org> >Ok, i THINK this was discussed once before, but i'm not sure. > >Are there any plans to move for instance, the loading and saving of the nick db >into the nickserv module directory, and same for chanserv, etc. I am trying to >make some modules that use their own dbs and I am being quite unccessful as of >now, but I will continue to try. Any guidance in adding a DB would be quite >welcome. The DB module interface is very much unfinished, and I think I'm going to leave it that way for at least version 5.0, because too much needs to change to do it properly, and if I keep trying to add things 5.0 will never be done. ;) You're welcome to play around with it and let me know if you come up with any ideas. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Apr 9 20:25:42 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] 5.0a24 - Problem with szline Message-ID: <3cb2cfc4.13321@achurch.org> This is taken care of now for the next alpha. --Andrew Church achurch@achurch.org http://achurch.org/ >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 > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Tue Apr 9 20:30:40 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] ircservices5.0a27 -> /ns set info (Another bug?) Message-ID: <3cb2d0eb.13337@achurch.org> Fixed for alpha 28, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ >Dunno if another users told you this bug, but /ns set info accepts >only one word, not more. Can you fix it? > >AngryWolf > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Tue Apr 9 20:42:11 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] ircservices5.0a26 /cs set secureops Message-ID: <3cb2d3b1.14034@achurch.org> >Is there any problem with secureops ? i have :/ >i have enabled it but chanserv never deop any user with 0 access on the >channel. >my ircd is bahamut and the conf lines are ok. Works for me: -> *ChanServ* set #123 secureops on -ChanServ- Secure ops option is now ON. *** Mode change "+o zop" on channel #123 by Alcan *** Mode change "-o zop" on channel #123 by ChanServ --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Apr 9 22:35:39 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] Services 5.0 alpha 28 released Message-ID: <3cb2f556.43160@achurch.org> Services 5.0 alpha 28 is out at the usual place. Big stuff this time is that memos now expire when accessed instead of periodically, like the expiration changes last time, and autokill exclusion support is added (note that this is based on a trircd extension to RFC1459, and making it work on other ircds requires _not_ sending AKILL/GLINE commmands--which can result in kill floods, so be careful). Changes in version 5.0 alpha 28 ------------------------------- 2002/04/09 Added support for autokill exclusions. Suggested by Yusuf Iskenderoglu 2002/04/09 Fixed bug causing NickServ SET INFO to ignore all words given after the first one. 2002/04/09 Fixed bug causing xml-import to ignore all channels. Reported by Adrian Cantrill 2002/04/08 Autokills are now sent after wallops when the ImmediatelySendAkill option is set. 2002/04/08 Improved trircd IRC server support and trircd-services database conversion support, thanks to Yusuf Iskenderoglu 2002/04/08 Reworked memo expiration logic as below. --Andrew Church achurch@achurch.org http://achurch.org/ From adrian.cantrill at dial.pipex.com Tue Apr 9 09:04:45 2002 From: adrian.cantrill at dial.pipex.com (Adrian Cantrill) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] Cosmetics Message-ID: <000c01c1dfe0$44cdf060$0100a8c0@ado> This is going to sounds majorly pedantic I know.. but its just something I have seen before that I thought would be more... usable for less experienced users. Take the following scenario. Ado (registered nick) I change to this nick and nickserv informs me its registered, all well and good. So I identify with it etc and it again informs me the password was correct. Then I go away Ado|food Then I come back and switch back to Ado How about nickserv saying something along the lines of "Nickserv : you have already authenticated for this nick", just makes the whole thing more user friendly by providing feedback. Anyways let me know what you think. Adrian From adrian.cantrill at dial.pipex.com Tue Apr 9 11:16:33 2002 From: adrian.cantrill at dial.pipex.com (Adrian Cantrill) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] Services Admin : Global Access to Channel Settings Message-ID: <000d01c1dff2$ae354190$0100a8c0@ado> Hi again, Another "bug" possibly not sure if its intentional. Should a service oper / admin be able to modify the access list on channels where they have no specific access ? it kinda seems logical to me that they should be able to, but on alpha 27 (going to upgrade to 28 later) I seem not to be able to. Just checking if its intentional, and if not, that you are aware of it. Thanks Adrian From mark at ctcp.net Tue Apr 9 11:46:32 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] Services Admin : Global Access to Channel Settings Message-ID: <1174.193.237.130.98.1018377992.squirrel@secure.uksolutions.co.uk> > Adrian Cantrill wrote: > Another "bug" possibly not sure if its intentional. > > Should a service oper / admin be able to modify the access list on > channels where they have no specific access ? it kinda seems logical to > me that they should be able to, but on alpha 27 (going to upgrade to 28 > later) I seem not to be able to. I am pretty sure it is intentional. Services opers have restrictions on what they can change via services. Services admins have more powers but still cannot alter every possible setting of channels/nicknames. Personally, I see no need for services users to have the power to manage channel access lists where they have not been given such access. It should be entirely up to the channel founder and his/her selected opers to manage the access list for a channel. -- Mark. From master at xchat.gr Tue Apr 9 14:53:42 2002 From: master at xchat.gr (George Stamatiou) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] ircservices5.0a28 /cs set secureops References: <3cb2d3b1.14034@achurch.org> Message-ID: <3CB362E6.80004@xchat.gr> the same error on every version. msg(chanserv)] set #test secureops on -ChanServ- Secure ops option is now ON. -ChanServ- Information for channel #test: -ChanServ- Founder: test -ChanServ- Options: Topic Retention, Secure Ops, Secure -ChanServ- Mode lock: +nt --- test gives channel operator status to George -ChanServ- Access level settings for channel #test: -ChanServ- AUTODEOP -1 -ChanServ- NOJOIN -100 if somebody does not believe it,simply do a connect on /server 62.103.210.20 i tried both to my pc (linux) and my shell (freebsd). Andrew Church wrote: >>Is there any problem with secureops ? i have :/ >>i have enabled it but chanserv never deop any user with 0 access on the >>channel. >>my ircd is bahamut and the conf lines are ok. >> > > Works for me: > >-> *ChanServ* set #123 secureops on >-ChanServ- Secure ops option is now ON. >*** Mode change "+o zop" on channel #123 by Alcan >*** Mode change "-o zop" on channel #123 by ChanServ > > --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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20020410/96b471e6/attachment.html From adrian.cantrill at dial.pipex.com Tue Apr 9 15:36:55 2002 From: adrian.cantrill at dial.pipex.com (Adrian Cantrill) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] Services Admin : Global Access to Channel Settings In-Reply-To: <1174.193.237.130.98.1018377992.squirrel@secure.uksolutions.co.uk> Message-ID: <001801c1e017$0db7bf20$0100a8c0@ado> Yus... one viewpoint... I tend to go with the flip side.. that service admin should have 100% access to all channels etc... but I just watched to check if it was a intentional design decision. Maybe have this as a option though? Services as a whole will be more flexible then. -----Original Message----- From: ircservices-coding-admin@ircservices.za.net [mailto:ircservices-coding-admin@ircservices.za.net] On Behalf Of Mark Hetherington Sent: 09 April 2002 19:47 To: ircservices-coding@ircservices.za.net Subject: RE: [IRCServices Coding] Services Admin : Global Access to Channel Settings > Adrian Cantrill wrote: > Another "bug" possibly not sure if its intentional. > > Should a service oper / admin be able to modify the access list on > channels where they have no specific access ? it kinda seems logical to > me that they should be able to, but on alpha 27 (going to upgrade to 28 > later) I seem not to be able to. I am pretty sure it is intentional. Services opers have restrictions on what they can change via services. Services admins have more powers but still cannot alter every possible setting of channels/nicknames. Personally, I see no need for services users to have the power to manage channel access lists where they have not been given such access. It should be entirely up to the channel founder and his/her selected opers to manage the access list for a channel. -- Mark. ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From mark at ctcp.net Tue Apr 9 15:59:58 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] Services Admin : Global Access to Channel Settings Message-ID: <1457.193.237.130.98.1018393198.squirrel@secure.uksolutions.co.uk> Adrian Cantrill wrote: > Yus... one viewpoint... I tend to go with the flip side.. that service > admin should have 100% access to all channels etc... but I just watched > to check if it was a intentional design decision. > > Maybe have this as a option though? Services as a whole will be more > flexible then. AIUI Services is not trying to be "Big Brother" and is there to provide protection to users as well as assistance to those that run the network so I don't really see such a thing becoming an option. Why would you want to manage the access list of somebody else's channel anyway? I think if you had and used the power you would find affected channels would swiftly relocate. Look at the currently available support to remove the ability of users to register channels. In such an environment a services admin/root would have to register channels on demand so a services admin/root would become founder and would have full rights to the access list. See CSEnableRegister in modules.conf for more information. -- Mark. From adrian.cantrill at dial.pipex.com Tue Apr 9 16:06:52 2002 From: adrian.cantrill at dial.pipex.com (Adrian Cantrill) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] Services Admin : Global Access to Channel Settings In-Reply-To: <1457.193.237.130.98.1018393198.squirrel@secure.uksolutions.co.uk> Message-ID: <001b01c1e01b$3c845990$0100a8c0@ado> A channel takeover situation where a channel founders password is gained and the services admin wishes to remove / add channel access to secure the situation. I can think of many legitimate situations where a service admin should have access control privileges globally. And on many other services distributions this is the case. -----Original Message----- From: ircservices-coding-admin@ircservices.za.net [mailto:ircservices-coding-admin@ircservices.za.net] On Behalf Of Mark Hetherington Sent: 10 April 2002 00:00 To: ircservices-coding@ircservices.za.net Subject: RE: [IRCServices Coding] Services Admin : Global Access to Channel Settings Adrian Cantrill wrote: > Yus... one viewpoint... I tend to go with the flip side.. that service > admin should have 100% access to all channels etc... but I just watched > to check if it was a intentional design decision. > > Maybe have this as a option though? Services as a whole will be more > flexible then. AIUI Services is not trying to be "Big Brother" and is there to provide protection to users as well as assistance to those that run the network so I don't really see such a thing becoming an option. Why would you want to manage the access list of somebody else's channel anyway? I think if you had and used the power you would find affected channels would swiftly relocate. Look at the currently available support to remove the ability of users to register channels. In such an environment a services admin/root would have to register channels on demand so a services admin/root would become founder and would have full rights to the access list. See CSEnableRegister in modules.conf for more information. -- Mark. ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From mark at ctcp.net Tue Apr 9 16:38:23 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] Services Admin : Global Access to Channel Settings Message-ID: <1626.193.237.130.98.1018395503.squirrel@secure.uksolutions.co.uk> Adrian Cantrill wrote: > A channel takeover situation where a channel founders password is gained > and the services admin wishes to remove / add channel access to secure > the situation. /msg chanserv suspend #channel is the easy quick fix. The founder/ops can then fix it themselves at a later time. /msg operserv clear #channel ops would remove everybody with current ops requiring them to re request ops from ChanServ or hop providing time to do whatever you feel you need to, to rectify the situation. /msg chanserv set #channel password newpassword would fix the problem of a compromised password. This should obviously be followed by pointing out the need for a decent password to the founder if this is a common problem on your network. There are various other commands which could be used, none of which require comprimising the founder's right to manage their own access list. It is up to the founder and designated ops to manage a channel, not a services admin. If you have problem users hacking founder passwords, surely it is better to deal with such users or (permanently) remove them from your network than start altering channel access lists. > I can think of many legitimate situations where a service > admin should have access control privileges globally. And on many other > services distributions this is the case. Well your single example so far can be handled far better using the current provisions of IRCServices so the ability to manipulate the access list is not required for that one. IRCServices is open source so you could add your own support. It would be quite trivial to implement as a custom patch for your network. If as you say "many" other packages offer it, maybe one of those would be better for you. A number of packages are branches of IRCServices so you are likely to find such packages very similar in operation. -- Mark. From achurch at achurch.org Wed Apr 10 10:04:10 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] Cosmetics Message-ID: <3cb38f91.00526@achurch.org> I don't see why. >This is going to sounds majorly pedantic I know.. but its just something >I have seen before that I thought would be more... usable for less >experienced users. Take the following scenario. > >Ado (registered nick) > >I change to this nick and nickserv informs me its registered, all well >and good. So I identify with it etc and it again informs me the password >was correct. > >Then I go away > >Ado|food > >Then I come back and switch back to > >Ado > >How about nickserv saying something along the lines of "Nickserv : you >have already authenticated for this nick", just makes the whole thing >more user friendly by providing feedback. > >Anyways let me know what you think. > >Adrian > > > >------------------------------------------------------------------ >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 Wed Apr 10 10:05:15 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] Services Admin : Global Access to Channel Settings Message-ID: <3cb39001.00537@achurch.org> This is intentional. If you absolutely must modify a channel's access list, use SET PASSWORD as a Services admin to change the channel's password and then identify for it using that password. >Hi again, > >Another "bug" possibly not sure if its intentional. > >Should a service oper / admin be able to modify the access list on >channels where they have no specific access ? it kinda seems logical to >me that they should be able to, but on alpha 27 (going to upgrade to 28 >later) I seem not to be able to. > >Just checking if its intentional, and if not, that you are aware of it. > >Thanks > >Adrian > > >------------------------------------------------------------------ >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 Wed Apr 10 10:08:52 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] ircservices5.0a28 /cs set secureops Message-ID: <3cb39100.00555@achurch.org> >if somebody does not believe it,simply do a connect on /server 62.103.210.20 >i tried both to my pc (linux) and my shell (freebsd). *** Connecting to port 6667 of server 62.103.210.20 *** Connection closed from 62.103.210.20: No route to host That's awfully convincing. As far as I'm concerned, this bug is closed. If anyone else can reproduce it from a clean install, please let me know. --Andrew Church achurch@achurch.org http://achurch.org/ >Andrew Church wrote: > >>>Is there any problem with secureops ? i have :/ >>>i have enabled it but chanserv never deop any user with 0 access on the >>>channel. >>>my ircd is bahamut and the conf lines are ok. >>> >> >> Works for me: >> >>-> *ChanServ* set #123 secureops on >>-ChanServ- Secure ops option is now ON. >>*** Mode change "+o zop" on channel #123 by Alcan >>*** Mode change "-o zop" on channel #123 by ChanServ >> >> --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 >> >> > > >--------------090606090409010802090400 >Content-Type: text/html; charset=ISO-2022-JP >Content-Transfer-Encoding: 7bit > > > > > >the same error on every version.
>
>msg(chanserv)] set #test secureops on
> -ChanServ- Secure ops option is now ON.
>
>-ChanServ- Information for channel #test:
> -ChanServ-         Founder: test
>-ChanServ-         Options: Topic Retention, Secure Ops, Secure
> -ChanServ-       Mode lock: +nt
>
>--- test gives channel operator status to George
>
> -ChanServ- Access level settings for channel #test:
> -ChanServ-     AUTODEOP    -1
> -ChanServ-     NOJOIN      -100
>
>if somebody does not believe it,simply do a connect on /server 62.103.210.20
>i tried both to my pc (linux) and my shell (freebsd).
>
>
>Andrew Church wrote:
>
>
> 
Is there any problem with secureops ? i have :/
i have enabled it but chanserv never deop any user with 0 access on the
channel.
my ircd is bahamut and the conf lines are ok.
>
> 

     Works for me:

-> *ChanServ* set #123 secureops on
-ChanServ- Secure ops option is now ON.
*** Mode change "+o zop" on channel #123 by Alcan
*** Mode change "-o zop" on channel #123 by ChanServ

  -
>-Andrew Church
    achurch@achurch.org
    http://achurch.org/
---------------------------------------------
>---------------------
To unsubscribe or change your subscription options, visit:
http://www.ircservices.za.net/mailman/listinfo/ircservices-cod
>ing


>
>
> > > >--------------090606090409010802090400-- > From griever at t2n.org Tue Apr 9 18:38:43 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] list Message-ID: Is there a way in /ns and /cs LIST to list anything other than the first 50 nicks? Can you like... list nicks 50-100? From achurch at achurch.org Wed Apr 10 13:13:37 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] list Message-ID: <3cb3bc60.00642@achurch.org> >Is there a way in /ns and /cs LIST to list anything other than the first >50 nicks? Can you like... list nicks 50-100? No. Think of LIST like a simple search engine: if the results get cut off, you need to use a more precise search term. --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Tue Apr 9 22:11:33 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] Cygnus Message-ID: Andrew, have you looked at cygnus services' IO engine? from what skold showed me, it synchs in about 15 seconds what ircservices takes 15 minutes. From achurch at achurch.org Wed Apr 10 14:20:56 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] Cygnus Message-ID: <3cb3cbd4.00711@achurch.org> >Andrew, have you looked at cygnus services' IO engine? from what skold >showed me, it synchs in about 15 seconds what ircservices takes 15 >minutes. Um, what are you talking about? I've never seen Services take 15 minutes to do _anything_. --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Tue Apr 9 22:55:21 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] Cygnus In-Reply-To: <3cb3cbd4.00711@achurch.org> Message-ID: On Wed, 10 Apr 2002, Andrew Church wrote: > >Andrew, have you looked at cygnus services' IO engine? from what skold > >showed me, it synchs in about 15 seconds what ircservices takes 15 > >minutes. > > Um, what are you talking about? I've never seen Services take 15 > minutes to do _anything_. > Skold was running this server with like... I think it was 1200000 clones on it. > --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 quension at softhome.net Tue Apr 9 23:03:24 2002 From: quension at softhome.net (Trevor Talbot) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] Cygnus In-Reply-To: Message-ID: On Tuesday, April 9, 2002, at 10:55 PM, Finny Merrill wrote: > On Wed, 10 Apr 2002, Andrew Church wrote: > >>> Andrew, have you looked at cygnus services' IO engine? from >>> what skold >>> showed me, it synchs in about 15 seconds what ircservices takes 15 >>> minutes. >> >> Um, what are you talking about? I've never seen Services take 15 >> minutes to do _anything_. > > Skold was running this server with like... I think it was > 1200000 clones > on it. On a single server? -- Quension From andrewk at isdial.net Tue Apr 9 23:10:32 2002 From: andrewk at isdial.net (Andrew Kempe) Date: Sat Oct 23 23:09:20 2004 Subject: [IRCServices Coding] Cygnus References: Message-ID: <00fd01c1e056$75245850$9c011ac4@africa.didata.local> Are you sure it's the IO engine? What happens after the data has been received is far more likely to take time than the actual socket IO. Do you have profiling reports for the two processes? Andrew ----- Original Message ----- From: "Finny Merrill" To: Sent: Wednesday, April 10, 2002 7:55 AM Subject: Re: [IRCServices Coding] Cygnus > On Wed, 10 Apr 2002, Andrew Church wrote: > > > >Andrew, have you looked at cygnus services' IO engine? from what skold > > >showed me, it synchs in about 15 seconds what ircservices takes 15 > > >minutes. > > > > Um, what are you talking about? I've never seen Services take 15 > > minutes to do _anything_. > > > > Skold was running this server with like... I think it was 1200000 clones > on it. > > > --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 Wed Apr 10 15:12:15 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Cygnus Message-ID: <3cb3d7e6.04322@achurch.org> If you've got a million clones on your network then you have far greater problems than whether Services can keep up or not. Show me a _real_ case where Services has problems and I'll look into it. --Andrew Church achurch@achurch.org http://achurch.org/ >On Wed, 10 Apr 2002, Andrew Church wrote: > >> >Andrew, have you looked at cygnus services' IO engine? from what skold >> >showed me, it synchs in about 15 seconds what ircservices takes 15 >> >minutes. >> >> Um, what are you talking about? I've never seen Services take 15 >> minutes to do _anything_. >> > >Skold was running this server with like... I think it was 1200000 clones >on it. > >> --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 master at xchat.gr Wed Apr 10 00:57:33 2002 From: master at xchat.gr (George Stamatiou) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 /cs set secureops References: <3cb39100.00555@achurch.org> Message-ID: <3CB3F06D.6050807@xchat.gr> I'm sorry andrew, but that ip was from my isdn dialup.i don't leave the connection all day online. try this 62.103.238.77 Thanks Andrew Church wrote: >>if somebody does not believe it,simply do a connect on /server 62.103.210.20 >>i tried both to my pc (linux) and my shell (freebsd). >> > >*** Connecting to port 6667 of server 62.103.210.20 >*** Connection closed from 62.103.210.20: No route to host > > That's awfully convincing. > > As far as I'm concerned, this bug is closed. If anyone else can >reproduce it from a clean install, please let me know. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > >>Andrew Church wrote: >> >>>>Is there any problem with secureops ? i have :/ >>>>i have enabled it but chanserv never deop any user with 0 access on the >>>>channel. >>>>my ircd is bahamut and the conf lines are ok. >>>> >>> Works for me: >>> >>>-> *ChanServ* set #123 secureops on >>>-ChanServ- Secure ops option is now ON. >>>*** Mode change "+o zop" on channel #123 by Alcan >>>*** Mode change "-o zop" on channel #123 by ChanServ >>> >>> --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 >>> >>> >> >>--------------090606090409010802090400 >>Content-Type: text/html; charset=ISO-2022-JP >>Content-Transfer-Encoding: 7bit >> >> >> >> >> >>the same error on every version.
>>
>>msg(chanserv)] set #test secureops on
>> -ChanServ- Secure ops option is now ON.
>>
>>-ChanServ- Information for channel #test:
>> -ChanServ-         Founder: test
>>-ChanServ-         Options: Topic Retention, Secure Ops, Secure
>> -ChanServ-       Mode lock: +nt
>>
>>--- test gives channel operator status to George
>>
>> -ChanServ- Access level settings for channel #test:
>> -ChanServ-     AUTODEOP    -1
>> -ChanServ-     NOJOIN      -100
>>
>>if somebody does not believe it,simply do a connect on /server 62.103.210.20
>>i tried both to my pc (linux) and my shell (freebsd).
>>
>>
>>Andrew Church wrote:
>>
>>
>> 
Is there any problem with secureops ? i have :/
i have enabled it but chanserv never deop any user with 0 access on the
channel.
my ircd is bahamut and the conf lines are ok.
>>
>> 

     Works for me:

-> *ChanServ* set #123 secureops on
-ChanServ- Secure ops option is now ON.
*** Mode change "+o zop" on channel #123 by Alcan
*** Mode change "-o zop" on channel #123 by ChanServ

  -
>>-Andrew Church
    achurch@achurch.org
    http://achurch.org/
---------------------------------------------
>>---------------------
To unsubscribe or change your subscription options, visit:
http://www.ircservices.za.net/mailman/listinfo/ircservices-cod
>>ing


>>
>>
>> >> >> >>--------------090606090409010802090400-- >> >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20020410/576f00c7/attachment.htm From adrian.cantrill at dial.pipex.com Wed Apr 10 08:52:00 2002 From: adrian.cantrill at dial.pipex.com (Adrian Cantrill) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Services Admin : Global Access to Channel Settings In-Reply-To: <3cb39001.00537@achurch.org> Message-ID: <002b01c1e0a7$a7245160$0100a8c0@ado> Hi, Thanks for that its just "another" method of doing it and it seems fine once I use it. Thanks again. -----Original Message----- From: ircservices-coding-admin@ircservices.za.net [mailto:ircservices-coding-admin@ircservices.za.net] On Behalf Of Andrew Church Sent: 10 April 2002 02:05 To: ircservices-coding@ircservices.za.net Subject: Re: [IRCServices Coding] Services Admin : Global Access to Channel Settings This is intentional. If you absolutely must modify a channel's access list, use SET PASSWORD as a Services admin to change the channel's password and then identify for it using that password. From griever at t2n.org Wed Apr 10 12:50:26 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Cygnus In-Reply-To: <00fd01c1e056$75245850$9c011ac4@africa.didata.local> Message-ID: On Wed, 10 Apr 2002, Andrew Kempe wrote: > Are you sure it's the IO engine? What happens after the data has been > received is far more likely to take time than the actual socket IO. > > Do you have profiling reports for the two processes? > > Andrew > Well: Cygnus is partially based on ircservices (just the core, the *Servs are complete rewrites). Previously, they took about the same time to synch. Then, skold redid the IO engine and cygnus' speed increased a whole lot. From griever at t2n.org Wed Apr 10 13:05:47 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Cygnus In-Reply-To: <3cb3d7e6.04322@achurch.org> Message-ID: On Wed, 10 Apr 2002, Andrew Church wrote: > If you've got a million clones on your network then you have far > greater problems than whether Services can keep up or not. Show me a > _real_ case where Services has problems and I'll look into it. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > Sorry, I blew the numbers up a bit. It was: 100000 user, 60000 channel, 30 server. From beng at nc.rr.com Wed Apr 10 15:58:51 2002 From: beng at nc.rr.com (Ben Goldstein) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various Message-ID: <01fb01c1e0ec$a6d78390$0300a8c0@asi200> [Apr 10 18:39:18 2002] IRC Services 5.0a28 starting up [Apr 10 18:39:20 2002] modules.conf:384: Unknown directive `SessionLimitAkill' I don't know if this just isn't being mentioned on the list or what.. changed to SessionLimitAutokill, it works. [Apr 10 18:49:30 2002] protocol/bahamut: WARNING: missing IP address for new nick Irch This happens when you use bahamut's oper hostmasking. I guess bahamut doesn't send the IP when connecting with a masked host. Also, should non-AUTH'd nicks be set kill enforced? This setting gets applied to new nicks if specified in the config. Shouldn't the default settings be applied after the nick is fully registered? [Apr 10 18:54:04 2002] mail/smtp: Connection to server broken for socket 0x8151e80 smtp still doesn't work for FreeBSD. I guess. I havn't had time to dig into this one. And finally.. a switch to turn of the annoying /ns(cs,ms,os) HELP COMMANDS would be nice. There was nothing wrong with /ns HELP. I expect all the people who issue a help follow it up with a help commands anyways. -- Ben Goldstein (beng@nc.rr.com) 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 bahamut-1.4(29). irc.bstu.dhs.org CDHiIY TS3ow-r[RELEASE] ircservices-5.0a28 services.bstu.dhs.org build #2, compiled Wed Apr 10 18:20:25 EDT 2002 From achurch at achurch.org Thu Apr 11 13:39:28 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Cygnus Message-ID: <3cb5148a.04633@achurch.org> I still haven't heard of a _real_ network with 100k users, but even assuming that's comparable to a real-world circumstance, Services frankly isn't designed to handle that many users. I haven't put any focus at all on speed in version 5.0, either--my priorities are (1) get it working and (2) get it stable and secure. If it works with 100k users, great, if not, don't use it; unlike some people (*cough*M$*cough*) I don't claim my software is the best for every imaginable circumstance. Also, it's worth noting that Services' I/O engine has been completely redesigned for 5.0, so any comparisons done with 4.x don't count. --Andrew Church achurch@achurch.org http://achurch.org/ >On Wed, 10 Apr 2002, Andrew Church wrote: > >> If you've got a million clones on your network then you have far >> greater problems than whether Services can keep up or not. Show me a >> _real_ case where Services has problems and I'll look into it. >> >> --Andrew Church >> achurch@achurch.org >> http://achurch.org/ >> >Sorry, I blew the numbers up a bit. > >It was: 100000 user, 60000 channel, 30 server. > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From rplume at cablemo.net Wed Apr 10 21:59:43 2002 From: rplume at cablemo.net (RP) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Cygnus References: <3cb5148a.04633@achurch.org> Message-ID: <001801c1e115$b35e5070$8cfeda42@ryan> Out of curiousity, how many users do you think services could handle efficiently? ----- Original Message ----- From: "Andrew Church" To: Sent: Wednesday, April 10, 2002 11:39 PM Subject: Re: [IRCServices Coding] Cygnus > I still haven't heard of a _real_ network with 100k users, but even > assuming that's comparable to a real-world circumstance, Services frankly > isn't designed to handle that many users. I haven't put any focus at all > on speed in version 5.0, either--my priorities are (1) get it working and > (2) get it stable and secure. If it works with 100k users, great, if not, > don't use it; unlike some people (*cough*M$*cough*) I don't claim my > software is the best for every imaginable circumstance. > > Also, it's worth noting that Services' I/O engine has been completely > redesigned for 5.0, so any comparisons done with 4.x don't count. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ From griever at t2n.org Thu Apr 11 01:22:05 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Cygnus In-Reply-To: <3cb5148a.04633@achurch.org> Message-ID: On Thu, 11 Apr 2002, Andrew Church wrote: > I still haven't heard of a _real_ network with 100k users, but even You've never heard of dalnet? > assuming that's comparable to a real-world circumstance, Services frankly > isn't designed to handle that many users. I haven't put any focus at all > on speed in version 5.0, either--my priorities are (1) get it working and > (2) get it stable and secure. If it works with 100k users, great, if not, > don't use it; unlike some people (*cough*M$*cough*) I don't claim my > software is the best for every imaginable circumstance. > > Also, it's worth noting that Services' I/O engine has been completely > redesigned for 5.0, so any comparisons done with 4.x don't count. > Actually, if I remember correctly 5.0 was slower. May be because of added features It's of point to note that both versions of ircservices sent a lot more to the server. Any idea what this could be? From admin at nevernet.net Thu Apr 11 01:25:02 2002 From: admin at nevernet.net (Elijah) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Cygnus In-Reply-To: Message-ID: <04b001c1e132$60431cf0$010210ac@noc4> I think he said REAL network. DALnet just attempts to be a network between netsplits and lag bursts :) ELIJAH(1) -----Original Message----- From: ircservices-coding-admin@ircservices.za.net [mailto:ircservices-coding-admin@ircservices.za.net] On Behalf Of Finny Merrill Sent: Thursday, April 11, 2002 9:22 AM To: ircservices-coding@ircservices.za.net Subject: Re: [IRCServices Coding] Cygnus On Thu, 11 Apr 2002, Andrew Church wrote: > I still haven't heard of a _real_ network with 100k users, but > even You've never heard of dalnet? > assuming that's comparable to a real-world circumstance, Services > frankly isn't designed to handle that many users. I haven't put any > focus at all on speed in version 5.0, either--my priorities are (1) > get it working and > (2) get it stable and secure. If it works with 100k users, great, if not, > don't use it; unlike some people (*cough*M$*cough*) I don't claim my > software is the best for every imaginable circumstance. > > Also, it's worth noting that Services' I/O engine has been > completely redesigned for 5.0, so any comparisons done with 4.x don't > count. > Actually, if I remember correctly 5.0 was slower. May be because of added features It's of point to note that both versions of ircservices sent a lot more to the server. Any idea what this could be? ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Thu Apr 11 17:41:23 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Cygnus Message-ID: <3cb54e39.05033@achurch.org> : >Out of curiousity, how many users do you think services could handle >efficiently? Earlier versions ran borderline with about 25k users from reports I heard. 5.0 has more efficient I/O but more overhead per command, so maybe more, maybe less, I don't know. Obviously it all depends on the system you run it on; I remember Services on EsperNet having lag trouble on startup with just 700 simultaneous users, but at the time it was running on a 486/100. Give it an Athlon 1900 or some such and maybe it can handle 100k users, I don't know--but to be honest it's not really designed to handle that many users efficiently. : >> I still haven't heard of a _real_ network with 100k users, but even > >You've never heard of dalnet? I wasn't aware they had 100k simultaneous users, but then I haven't gone there in a while. >> Also, it's worth noting that Services' I/O engine has been completely >> redesigned for 5.0, so any comparisons done with 4.x don't count. >> >Actually, if I remember correctly 5.0 was slower. May be because of added >features As mentioned above, commands have more overhead (mostly because they use callbacks), so any comparisons done with 4.x don't count even more. >It's of point to note that both versions of ircservices sent a lot more >to the server. Any idea what this could be? Because they're friendlier and want to chat with the server more? --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Thu Apr 11 23:33:13 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various Message-ID: <3cb59f67.05204@achurch.org> >[Apr 10 18:39:18 2002] IRC Services 5.0a28 starting up >[Apr 10 18:39:20 2002] modules.conf:384: Unknown directive >`SessionLimitAkill' > >I don't know if this just isn't being mentioned on the list or what.. >changed to SessionLimitAutokill, it works. This directive had its name changed a few releases back; you'll need to update your config files. >[Apr 10 18:49:30 2002] protocol/bahamut: WARNING: missing IP address for new >nick Irch >This happens when you use bahamut's oper hostmasking. I guess bahamut >doesn't send the IP when connecting with a masked host. What is oper hostmasking, anyway? >Also, should non-AUTH'd nicks be set kill enforced? This setting gets >applied to new nicks if specified in the config. Shouldn't the default >settings be applied after the nick is fully registered? Good point. >[Apr 10 18:54:04 2002] mail/smtp: Connection to server broken for socket >0x8151e80 >smtp still doesn't work for FreeBSD. I guess. I havn't had time to dig into >this one. I'll try and find time for this, but if you or someone else could take a closer look it would help. >And finally.. a switch to turn of the annoying /ns(cs,ms,os) HELP COMMANDS >would be nice. There was nothing wrong with /ns HELP. I expect all the >people who issue a help follow it up with a help commands anyways. HELP COMMANDS is there because it was impossible (well, close enough) to deal with changed to the command list from modules getting loaded and unloaded otherwise. Plus, I can see plenty of cases where you might want to do a HELP COMMANDS without the extra junk from HELP. HELP COMMANDS stays. --Andrew Church achurch@achurch.org http://achurch.org/ From uhc0 at rz.uni-karlsruhe.de Thu Apr 11 07:50:35 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:21 2004 Subject: AW: [IRCServices Coding] ircservices5.0a28 various In-Reply-To: <3cb59f67.05204@achurch.org> Message-ID: <000601c1e168$4ecde7d0$02c8a8c0@nygmatech.local> Hi, > >[Apr 10 18:49:30 2002] protocol/bahamut: WARNING: missing IP address > >for new nick Irch This happens when you use bahamut's oper > hostmasking. > >I guess bahamut doesn't send the IP when connecting with a > masked host. > > What is oper hostmasking, anyway? It is the way Bahamut uses to fake ircop hostnames via the #define STAFF_HOST The function bahamut uses for this feature removes the sptr->ip and replaces sptr->hostip with 0.0.0.0 leading to a 0 in the NICK line. This is by design. That log warning can be ignored, I believe. > > >Also, should non-AUTH'd nicks be set kill enforced? This > setting gets > >applied to new nicks if specified in the config. Shouldn't > the default > >settings be applied after the nick is fully registered? > > Good point. Services should even not set users +r when identifying to a non authenticated nickname, to prevent clone attacks to +R channels or flooding +R users, by simply registered and identifying. 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 | | ---------------------------------------------------------------------- From r-krisztian at softhome.net Thu Apr 11 08:02:44 2002 From: r-krisztian at softhome.net (=?iso-8859-1?Q?Romek_Kriszti=E1n?=) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various References: <000601c1e168$4ecde7d0$02c8a8c0@nygmatech.local> Message-ID: <000901c1e169$f14c2700$0b00000a@rokusnet.hu> Hello! About hostnames I have also a notice ignoring problem on on Unreal IRCd protocol, because my services gives a warning that services can't get IP address from hostnames. If I'm right, it's because of hidden hostnames, but dunno. yusuf: I think you should ignore these notices if you know what you're doing. AngryWolf From mark at ctcp.net Thu Apr 11 10:20:07 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] 5.0a28 seemingly inaccurate startup warnings in log Message-ID: <1130.193.237.130.98.1018545607.squirrel@secure.uksolutions.co.uk> After installing Services 5.0a28, I booted services, used /operserv shutdown, then started services again. >From that point and on all subsequent runs of Services, a number of warnings appear in the log file from services of the format: IRC Services 5.0a28 starting up database/version4: warning: autokick mismatch in extension data for channel #admins (corrupt database?): expected 2, got 2 As can be seen from this example, the two numbers where services thinks it has found a problem are equal so I am not sure what services actually thinks the problem is. The warning output code seems to be performing a check with one set of parameters but reporting the error using a different set of parameters: if (count != ci->access_count && ci != &dummy_ci) { module_log("warning: autokick mismatch in extension data" " for channel %s (corrupt database?): expected" " %d, got %d", ci->name, ci->akick_count, count); i.e. ci->access_count as used for the check is not the same variable as ci- >akick_count as used for the message output. -- Mark. From beng at nc.rr.com Thu Apr 11 12:30:45 2002 From: beng at nc.rr.com (Ben Goldstein) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various References: <3cb59f67.05204@achurch.org> Message-ID: <022d01c1e18f$7df42610$0300a8c0@asi200> > >[Apr 10 18:39:18 2002] IRC Services 5.0a28 starting up > >[Apr 10 18:39:20 2002] modules.conf:384: Unknown directive > >`SessionLimitAkill' > > > >I don't know if this just isn't being mentioned on the list or what.. > >changed to SessionLimitAutokill, it works. > > This directive had its name changed a few releases back; you'll need > to update your config files. In the most recent example-modules.conf, the example needs to be changed. (line 372) #SessionLimitAkill 10s 5 30m "Exceeding session limit" -- Ben Goldstein (beng@nc.rr.com) From admin at nevernet.net Thu Apr 11 13:49:37 2002 From: admin at nevernet.net (Elijah) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various In-Reply-To: <022d01c1e18f$7df42610$0300a8c0@asi200> Message-ID: <055e01c1e19a$64d701b0$010210ac@noc4> Another question, would it be possible to have logging ignore various things? Maybe options for logging like MINIMAL and VERBOSE...so that every nick identify isn't logged if you don't want it to be. Same with unknown messages and the like. CHATOPS and it's close relatives are always logged as unknown messages, but it's really not necessary. Thanks, ELIJAH(1) From kfiresun at ix.netcom.com Thu Apr 11 15:06:59 2002 From: kfiresun at ix.netcom.com (Kelmar K. Firesun) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Cygnus References: <3cb54e39.05033@achurch.org> Message-ID: <002201c1e1a5$33845ad0$0200000a@stormkeepers.com> ----- Original Message ----- From: "Andrew Church" To: Sent: Thursday, April 11, 2002 3:41 AM Subject: Re: [IRCServices Coding] Cygnus > : > >Out of curiousity, how many users do you think services could handle > >efficiently? > > Earlier versions ran borderline with about 25k users from reports I > heard. 5.0 has more efficient I/O but more overhead per command, so maybe > more, maybe less, I don't know. Obviously it all depends on the system you > run it on; I remember Services on EsperNet having lag trouble on startup > with just 700 simultaneous users, but at the time it was running on a > 486/100. Give it an Athlon 1900 or some such and maybe it can handle 100k > users, I don't know--but to be honest it's not really designed to handle > that many users efficiently. > > : > >> I still haven't heard of a _real_ network with 100k users, but even > > > >You've never heard of dalnet? > > I wasn't aware they had 100k simultaneous users, but then I haven't > gone there in a while. > Current local users: 10288 Max: 25358 Current global users: 120185 Max: 135705 I don't think you'd want to go back to Dalnet anytime soon: -twisted.ma.us.dal.net- *** Autokilled for [exp/ident] Enable ident in your client. Send email to exploits@dal.net with a subject of [exp/ident] for more details. [AKILL ID:969137152K-a] (2002/04/11 14.58) *Tries not to go on tirade about how using IDENT for security is a Bad Idea(tm)* > > >> Also, it's worth noting that Services' I/O engine has been completely > >> redesigned for 5.0, so any comparisons done with 4.x don't count. > >> > >Actually, if I remember correctly 5.0 was slower. May be because of added > >features > > As mentioned above, commands have more overhead (mostly because they > use callbacks), so any comparisons done with 4.x don't count even more. > That and loadable modules, which would have the additional overhead of context switching. *shudder* > >It's of point to note that both versions of ircservices sent a lot more > >to the server. Any idea what this could be? > > Because they're friendlier and want to chat with the server more? > *laugh* Kelmar K. Firesun (IRL: Bryce Simonds) Acting Admin: dream.esper.net From griever at t2n.org Thu Apr 11 15:50:04 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Cygnus In-Reply-To: <002201c1e1a5$33845ad0$0200000a@stormkeepers.com> Message-ID: On Thu, 11 Apr 2002, Kelmar K. Firesun wrote: > > Current local users: 10288 Max: 25358 > Current global users: 120185 Max: 135705 > > I don't think you'd want to go back to Dalnet anytime soon: > -twisted.ma.us.dal.net- *** Autokilled for [exp/ident] Enable ident in your > client. Send email to exploits@dal.net with a subject of [exp/ident] for > more > details. [AKILL ID:969137152K-a] (2002/04/11 14.58) > > *Tries not to go on tirade about how using IDENT for security is a Bad > Idea(tm)* Oh shut up, seriously. We've already discussed this :P From achurch at achurch.org Fri Apr 12 10:17:05 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Cygnus Message-ID: <3cb6370f.05461@achurch.org> >> As mentioned above, commands have more overhead (mostly because they >> use callbacks), so any comparisons done with 4.x don't count even more. > >That and loadable modules, which would have the additional overhead of >context switching. *shudder* Er, modules and context switching have nothing to do with each other. The only overhead outside of callbacks used by modules is when actually loading them, and if that's such a concern you can always compile the modules statically which dramatically reduces that overhead. (On second thought, that's not _quite_ true because there are cases where you have to look up symbols in other modules, but I've tried to keep those to a minimum so they shouldn't significantly impact anything.) --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Fri Apr 12 10:55:19 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] 5.0a28 seemingly inaccurate startup warnings in log Message-ID: <3cb63e93.05530@achurch.org> Thanks, fixed. >After installing Services 5.0a28, I booted services, used /operserv >shutdown, then started services again. > >>From that point and on all subsequent runs of Services, a number of >warnings appear in the log file from services of the format: > >IRC Services 5.0a28 starting up >database/version4: warning: autokick mismatch in extension data for channel >#admins (corrupt database?): expected 2, got 2 > >As can be seen from this example, the two numbers where services thinks it >has found a problem are equal so I am not sure what services actually >thinks the problem is. > >The warning output code seems to be performing a check with one set of >parameters but reporting the error using a different set of parameters: > > if (count != ci->access_count && ci != &dummy_ci) { > module_log("warning: autokick mismatch in extension data" > " for channel %s (corrupt database?): expected" > " %d, got %d", ci->name, ci->akick_count, count); > >i.e. ci->access_count as used for the check is not the same variable as ci- >>akick_count as used for the message output. > >-- >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 achurch at achurch.org Fri Apr 12 10:57:24 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various Message-ID: <3cb63f14.05547@achurch.org> Logging is going to be redone in a future release. >Another question, would it be possible to have logging ignore various >things? Maybe options for logging like MINIMAL and VERBOSE...so that >every nick identify isn't logged if you don't want it to be. Same with >unknown messages and the like. CHATOPS and it's close relatives are >always logged as unknown messages, but it's really not necessary. > >Thanks, > >ELIJAH(1) > >------------------------------------------------------------------ >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 quension at softhome.net Thu Apr 11 18:57:29 2002 From: quension at softhome.net (Trevor Talbot) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Cygnus In-Reply-To: <002201c1e1a5$33845ad0$0200000a@stormkeepers.com> Message-ID: On Thursday, April 11, 2002, at 03:06 PM, Kelmar K. Firesun wrote: >> : >>>> I still haven't heard of a _real_ network with 100k >>>> users, but even >>> >>> You've never heard of dalnet? >> >> I wasn't aware they had 100k simultaneous users, but then >> I haven't >> gone there in a while. > > Current local users: 10288 Max: 25358 > Current global users: 120185 Max: 135705 > > I don't think you'd want to go back to Dalnet anytime soon: > -twisted.ma.us.dal.net- *** Autokilled for [exp/ident] Enable > ident in your > client. Send email to exploits@dal.net with a subject of > [exp/ident] for > more > details. [AKILL ID:969137152K-a] (2002/04/11 14.58) > > *Tries not to go on tirade about how using IDENT for security is a Bad > Idea(tm)* Don't worry; it's not being used for security. >>>> Also, it's worth noting that Services' I/O engine has >>>> been completely >>>> redesigned for 5.0, so any comparisons done with 4.x don't count. >>>> >>> Actually, if I remember correctly 5.0 was slower. May be >>> because of added >>> features >> >> As mentioned above, commands have more overhead (mostly >> because they >> use callbacks), so any comparisons done with 4.x don't count >> even more. > > That and loadable modules, which would have the additional overhead of > context switching. *shudder* > >>> It's of point to note that both versions of ircservices sent a >>> lot more >>> to the server. Any idea what this could be? >> >> Because they're friendlier and want to chat with the server more? While we're on this topic, I took a look at Cygnus' 0.0.2 socket code. It appears to use a blocking socket, and I see possible issues with receive buffering. Did it handle everything it was supposed to? More details really are needed for decent comparisons. -- Quension From achurch at achurch.org Fri Apr 12 10:58:07 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various Message-ID: <3cb63f35.06222@achurch.org> Fixed, thanks. >> >[Apr 10 18:39:18 2002] IRC Services 5.0a28 starting up >> >[Apr 10 18:39:20 2002] modules.conf:384: Unknown directive >> >`SessionLimitAkill' >> > >> >I don't know if this just isn't being mentioned on the list or what.. >> >changed to SessionLimitAutokill, it works. >> >> This directive had its name changed a few releases back; you'll need >> to update your config files. > >In the most recent example-modules.conf, the example needs to be changed. >(line 372) > #SessionLimitAkill 10s 5 30m "Exceeding session limit" > > >-- Ben Goldstein (beng@nc.rr.com) > > >------------------------------------------------------------------ >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 Fri Apr 12 11:13:50 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:21 2004 Subject: AW: [IRCServices Coding] ircservices5.0a28 various Message-ID: <3cb6438e.10035@achurch.org> >> >[Apr 10 18:49:30 2002] protocol/bahamut: WARNING: missing IP address >> >for new nick Irch This happens when you use bahamut's oper >> hostmasking. >> >I guess bahamut doesn't send the IP when connecting with a >> masked host. >> >> What is oper hostmasking, anyway? > >It is the way Bahamut uses to fake ircop hostnames via the #define >STAFF_HOST > >The function bahamut uses for this feature removes the sptr->ip and >replaces sptr->hostip with 0.0.0.0 leading to a 0 in the NICK line. This >is by design. That log warning can be ignored, I believe. That may be about the only thing to do; I'll put a note somewhere. >Services should even not set users +r when identifying to a non >authenticated nickname, to prevent clone attacks to +R channels or >flooding +R users, by simply registered and identifying. You can't identify to a non-authed nickname in the first place, so this is a non-issue. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Fri Apr 12 11:16:56 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various Message-ID: <3cb643b3.10044@achurch.org> >About hostnames I have also a notice ignoring problem on on Unreal IRCd >protocol, because my services gives a warning that services can't get IP >address from hostnames. If I'm right, it's because of hidden hostnames, but >dunno. I wasn't aware Unreal sent IP addresses in the first place; I haven't seen these warnings (Unreal 3.1.whatever). --Andrew Church achurch@achurch.org http://achurch.org/ From r-krisztian at softhome.net Thu Apr 11 21:33:09 2002 From: r-krisztian at softhome.net (Romek Krisztián) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various References: <3cb643b3.10044@achurch.org> Message-ID: <002a01c1e1db$2acc3d00$0b00000a@rokusnet.hu> Sorry, I was wrong, the real message is the following and the version is Unreal 3.2beta9 I think it's not going to be a services problem... *** Checking ident... *** Couldn't resolve your hostname; using your IP address instead *** Received identd response After # ./ircservices I have a warning message: *** Global -- from OperServ: WARNING: Client IP addresses are not available with this IRC server; SZLINEs cannot be used unless ImmediatelySendSline is enabled in modules.conf. How can I solves this? Enable ImmediatelySendSline? ----- Original Message ----- From: Andrew Church To: Sent: Friday, April 12, 2002 4:16 AM Subject: Re: [IRCServices Coding] ircservices5.0a28 various > >About hostnames I have also a notice ignoring problem on on Unreal IRCd > >protocol, because my services gives a warning that services can't get IP > >address from hostnames. If I'm right, it's because of hidden hostnames, but > >dunno. > > I wasn't aware Unreal sent IP addresses in the first place; I haven't > seen these warnings (Unreal 3.1.whatever). > > --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 Fri Apr 12 14:11:19 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various Message-ID: <3cb66c85.12215@achurch.org> >Sorry, I was wrong, the real message is the following and the version is >Unreal 3.2beta9 > >I think it's not going to be a services problem... > >*** Checking ident... >*** Couldn't resolve your hostname; using your IP address instead >*** Received identd response > >After ># ./ircservices >I have a warning message: > >*** Global -- from OperServ: WARNING: Client IP addresses are not available >with this IRC server; SZLINEs cannot be used unless ImmediatelySendSline is >enabled in modules.conf. > >How can I solves this? Enable ImmediatelySendSline? Yes, that would seem to be the optimal solution. >----- Original Message ----- >From: Andrew Church >To: >Sent: Friday, April 12, 2002 4:16 AM >Subject: Re: [IRCServices Coding] ircservices5.0a28 various > > >> >About hostnames I have also a notice ignoring problem on on Unreal IRCd >> >protocol, because my services gives a warning that services can't get IP >> >address from hostnames. If I'm right, it's because of hidden hostnames, >but >> >dunno. >> >> I wasn't aware Unreal sent IP addresses in the first place; I haven't >> seen these warnings (Unreal 3.1.whatever). >> >> --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 --Andrew Church achurch@achurch.org http://achurch.org/ From pcockrell at satx.rr.com Thu Apr 11 22:14:33 2002 From: pcockrell at satx.rr.com (Phillip C.) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0 References: <3cb66c85.12215@achurch.org> Message-ID: <006701c1e1e0$efe746c0$1901a8c0@lightspeed> How close are we to seeing a beta release? Any time frame? Phil From kfiresun at ix.netcom.com Thu Apr 11 23:12:20 2002 From: kfiresun at ix.netcom.com (Kelmar K. Firesun) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Cygnus References: Message-ID: <002001c1e1e9$00e769c0$0200000a@stormkeepers.com> ----- Original Message ----- From: "Trevor Talbot" To: Sent: Thursday, April 11, 2002 8:57 PM Subject: Re: [IRCServices Coding] Cygnus > > > > *Tries not to go on tirade about how using IDENT for security is a Bad > > Idea(tm)* > > Don't worry; it's not being used for security. > I hate arguing this point. If it's not letting me on becuase I'm not running it then, it certinaly does look like security to me. I could continue on this point, but I wont. This is not the list to argue such a point. I'm not out to start a flame war on this. Kelmar K. Firesun (IRL: Bryce Simonds) Acting Admin: dream.esper.net From achurch at achurch.org Fri Apr 12 15:53:41 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0 Message-ID: <3cb6847b.12237@achurch.org> >How close are we to seeing a beta release? Any time frame? I have no clue. --Andrew Church achurch@achurch.org http://achurch.org/ From admin at nevernet.net Fri Apr 12 00:35:50 2002 From: admin at nevernet.net (Elijah) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Another question Message-ID: <05e801c1e1f4$ab90ade0$010210ac@noc4> How about a numbered akill list? Would just make it easier to remove them. Handling similar to the channel access lists. From v13 at it.teithe.gr Fri Apr 12 09:37:22 2002 From: v13 at it.teithe.gr (V13) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Another question In-Reply-To: <05e801c1e1f4$ab90ade0$010210ac@noc4> References: <05e801c1e1f4$ab90ade0$010210ac@noc4> Message-ID: <200204121937.22842.v13@it.teithe.gr> On Friday 12 April 2002 10:35, Elijah wrote: > How about a numbered akill list? Would just make it easier to remove > them. Handling similar to the channel access lists. NO! Please don't... It is very common for two opers to try to remove an akill at the same time, or for services to expire some akills while an oper is typing /os akill del .... <> From dan at viaraix.net Fri Apr 12 12:13:33 2002 From: dan at viaraix.net (Dan Jones) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Channel registration limit Message-ID: <3CB731DD.10101@viaraix.net> from the nickserv bit on http module for every nick there is a section... Channel registration limit: Default (20) does this mean it can be changed per specific nick ? problem i have atm is that i want to allow users to register up to 2 channels but i want services admins especially to be able to register more if there isnt a way to change it per specific nick can you make this ignored for services admins? From admin at nevernet.net Fri Apr 12 12:15:54 2002 From: admin at nevernet.net (Elijah) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Another question In-Reply-To: <200204121937.22842.v13@it.teithe.gr> Message-ID: <004701c1e256$77c15bb0$010210ac@noc4> How about an option to turn it off then? (My solution to everything...because I love updating language files):P ELIJAH(1) -----Original Message----- From: ircservices-coding-admin@ircservices.za.net [mailto:ircservices-coding-admin@ircservices.za.net] On Behalf Of V13 Sent: Friday, April 12, 2002 5:37 PM To: ircservices-coding@ircservices.za.net Subject: Re: [IRCServices Coding] Another question On Friday 12 April 2002 10:35, Elijah wrote: > How about a numbered akill list? Would just make it easier to remove > them. Handling similar to the channel access lists. NO! Please don't... It is very common for two opers to try to remove an akill at the same time, or for services to expire some akills while an oper is typing /os akill del .... <> ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From griever at t2n.org Fri Apr 12 13:20:47 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Another question In-Reply-To: <200204121937.22842.v13@it.teithe.gr> Message-ID: On Fri, 12 Apr 2002, V13 wrote: > On Friday 12 April 2002 10:35, Elijah wrote: > > How about a numbered akill list? Would just make it easier to remove > > them. Handling similar to the channel access lists. > > NO! Please don't... It is very common for two opers to try to remove an akill > at the same time, or for services to expire some akills while an oper is > typing /os akill del .... Do it the same way access lists are done: keep the same numbers until the next DB update. Also, I seem to remember andy saying he might allow masks in access lists again, as an option. > > <> > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From r-krisztian at softhome.net Fri Apr 12 13:27:15 2002 From: r-krisztian at softhome.net (=?iso-8859-1?Q?Romek_Kriszti=E1n?=) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Channel registration limit References: <3CB731DD.10101@viaraix.net> Message-ID: <004401c1e260$735877c0$0b00000a@rokusnet.hu> That sounds a good idea. It can be changed by the CSMaxReg option if i know well... But it's for every user, you cannot set a limit to one user with this. AngryWolf ----- Original Message ----- From: Dan Jones To: Sent: Friday, April 12, 2002 9:13 PM Subject: [IRCServices Coding] Channel registration limit > from the nickserv bit on http module for every nick there is a section... > > Channel registration limit: Default (20) > > does this mean it can be changed per specific nick ? > > problem i have atm is that i want to allow users to register up to 2 > channels but i want services admins especially to be able to register more > > if there isnt a way to change it per specific nick can you make this > ignored for services admins? > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From beng at nc.rr.com Fri Apr 12 21:52:32 2002 From: beng at nc.rr.com (Ben Goldstein) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various References: <3cb59f67.05204@achurch.org> Message-ID: <039f01c1e2a7$37b3f180$0300a8c0@asi200> > >[Apr 10 18:54:04 2002] mail/smtp: Connection to server broken for socket > >0x8151e80 > >smtp still doesn't work for FreeBSD. I guess. I havn't had time to dig into > >this one. > > I'll try and find time for this, but if you or someone else could take > a closer look it would help. > [Apr 12 20:24:27.627615 2002] debug: sockets: connect on fd 1 returned [Apr 12 20:24:27.627957 2002] debug: sockets: connect(1 -> 24.93.67.206:25): Socket is already connected [Apr 12 20:24:27.628241 2002] mail/smtp: Connection to server failed for socket 0x8151e80 Any thoughts? Socket is already connected (?!) 24.93.67.206 is my mail server. Will continue investigating. -- Ben Goldstein (beng@nc.rr.com) From achurch at achurch.org Sat Apr 13 16:51:40 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] Channel registration limit Message-ID: <3cb7e3a4.13143@achurch.org> I think I haven't gotten around to this yet but it's definitely planned to go in at some point. >from the nickserv bit on http module for every nick there is a section... > > Channel registration limit: Default (20) > >does this mean it can be changed per specific nick ? > >problem i have atm is that i want to allow users to register up to 2 >channels but i want services admins especially to be able to register more > >if there isnt a way to change it per specific nick can you make this >ignored for services admins? > >------------------------------------------------------------------ >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 Sun Apr 14 11:46:54 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various Message-ID: <3cb8ede0.13655@achurch.org> "Already connected" sounds like it's ignoring the fact that the socket is non-blocking (or maybe my logic is wrong). --Andrew Church achurch@achurch.org http://achurch.org/ >> >[Apr 10 18:54:04 2002] mail/smtp: Connection to server broken for socket >> >0x8151e80 >> >smtp still doesn't work for FreeBSD. I guess. I havn't had time to dig >into >> >this one. >> >> I'll try and find time for this, but if you or someone else could >take >> a closer look it would help. >> > >[Apr 12 20:24:27.627615 2002] debug: sockets: connect on fd 1 returned >[Apr 12 20:24:27.627957 2002] debug: sockets: connect(1 -> 24.93.67.206:25): >Socket is already connected >[Apr 12 20:24:27.628241 2002] mail/smtp: Connection to server failed for >socket 0x8151e80 > >Any thoughts? > >Socket is already connected (?!) 24.93.67.206 is my mail server. Will >continue investigating. > >-- Ben Goldstein (beng@nc.rr.com) > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From v13 at it.teithe.gr Sun Apr 14 05:22:01 2002 From: v13 at it.teithe.gr (V13) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various In-Reply-To: <3cb8ede0.13655@achurch.org> References: <3cb8ede0.13655@achurch.org> Message-ID: <200204141522.01473.v13@it.teithe.gr> On Sunday 14 April 2002 14:46, Andrew Church wrote: > "Already connected" sounds like it's ignoring the fact that the socket > is non-blocking (or maybe my logic is wrong). I'm not 100% sure about this.. anyway... In sockets.c:482: if ((i = connect(fd, (struct sockaddr *)&sa, sizeof(sa))) < 0 && errno != EINPROGRESS and after that: if (i == 0) { s->flags |= SF_CONNECTED; FD_SET(fd, &sock_fds); if (s->cb_connect) s->cb_connect(s, 0); } else { s->flags |= SF_CONNECTING; FD_SET(fd, &write_fds); } So a non blocking connect() returns EINPROGRESS and (s->flags & SF_CONNECTING) is true.. After that, when the connection is established, in sockets.c:296 in function check_sockets(): } else if (s->flags & SF_CONNECTING) { /* Connection established (or failed) */ if (debug >= 2) log("debug: sockets: connect on fd %d returned", i); res = connect(s->fd, (struct sockaddr *)&s->remote, sizeof(s->remote)); So you're calling connect() twice and the 2nd call is done when the socket *IS* connected, since writeability indicates the connection is established. > --Andrew Church <> From griever at t2n.org Sun Apr 14 08:41:24 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various In-Reply-To: <200204141522.01473.v13@it.teithe.gr> Message-ID: I believe the POSIX way to do this is to call connect(), ignore the return value, then select() it for except and write. If write, it opened successfully, if except, there's an error (use getsockopt()). From achurch at achurch.org Mon Apr 15 00:54:40 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various Message-ID: <3cb9a86f.14161@achurch.org> >I believe the POSIX way to do this is to call connect(), ignore the return >value, then select() it for except and write. If write, it opened >successfully, if except, there's an error (use getsockopt()). Do you know of anywhere this is documented? My connect(2) man page (Linux, dated 1998/10/3) says, for EINPROGRESS: The socket is non-blocking and the connection cannot be completed immediately. It is possible to select(2) or poll(2) for completion by selecting the socket for writing. After select indicates writability, use getsockopt(2) to read the SO_ERROR option at level SOL_SOCKET to determine whether connect completed successfully (SO_ERROR) is zero) or unsuccessfully (SO_ERROR is one of the usual error codes listed here, explaining the reason for the failure). which would seem to indicate that Linux, at least, returns writable even for unsuccessful connections (I haven't tested this). If anyone would be willing to try to figure out and test a reliable way to check for connectedness of non-blocking sockets on both Linux and FreeBSD, it would be much appreciated. Remember that it has to work for both successful and failed connections for both localhost (I'm not sure, but connect() may return success even if non-blocking for 127.0.0.1) and remote hosts with reasonably high (>100ms) ping times. --Andrew Church achurch@achurch.org http://achurch.org/ From v13 at it.teithe.gr Sun Apr 14 13:18:00 2002 From: v13 at it.teithe.gr (V13) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various In-Reply-To: <3cb9a86f.14161@achurch.org> References: <3cb9a86f.14161@achurch.org> Message-ID: <200204142318.00955.v13@it.teithe.gr> On Monday 15 April 2002 03:54, Andrew Church wrote: > If anyone would be willing to try to figure out and test a reliable > way to check for connectedness of non-blocking sockets on both Linux and > FreeBSD, it would be much appreciated. Remember that it has to work for > both successful and failed connections for both localhost (I'm not sure, > but connect() may return success even if non-blocking for 127.0.0.1) and > remote hosts with reasonably high (>100ms) ping times. You do a connect(). If connect returns 0 then the connection is established. If it returns -1 then you select() this fd for write. When select() indicates writeability then you use getsockopt(): int ret,n; ret=getsockopt(sockfd,SOL_SOCKET,SO_ERROR,&n,sizeof(n)); ret==0 && n==0 means the socket is succesfuly connected when failed n has the same error code that connect() whould return if it was a blocking socket. > --Andrew Church <> From v13 at it.teithe.gr Sun Apr 14 13:29:06 2002 From: v13 at it.teithe.gr (V13) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various Message-ID: <200204142329.06500.v13@it.teithe.gr> On Sunday 14 April 2002 23:18, V13 wrote: > If it returns -1 then you select() this fd for write. Correction: If it returns -1 and errno==EINPROGRESS then you select the fd for write. return==-1 and errno!=EINPROGRESS means that connect() failed. In that case select() should not be used for this fd (it will return error). <> From achurch at achurch.org Mon Apr 15 10:09:16 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:21 2004 Subject: [IRCServices Coding] ircservices5.0a28 various Message-ID: <3cba2895.14421@achurch.org> I can comprehend the manual page just fine without any assistance, thank you. I was asking for someone who would be willing to actually test this on both systems and see if it worked, not someone to explain it in newbie-speak. --Andrew Church achurch@achurch.org http://achurch.org/ >On Monday 15 April 2002 03:54, Andrew Church wrote: >> If anyone would be willing to try to figure out and test a reliabl >e >> way to check for connectedness of non-blocking sockets on both Linux an >d >> FreeBSD, it would be much appreciated. Remember that it has to work fo >r >> both successful and failed connections for both localhost (I'm not sure >, >> but connect() may return success even if non-blocking for 127.0.0.1) an >d >> remote hosts with reasonably high (>100ms) ping times. > >You do a connect(). >If connect returns 0 then the connection is established. >If it returns -1 then you select() this fd for write. >When select() indicates writeability then you use getsockopt(): > >int ret,n; >ret=getsockopt(sockfd,SOL_SOCKET,SO_ERROR,&n,sizeof(n)); > >ret==0 && n==0 means the socket is succesfuly connected >when failed n has the same error code that connect() whould return if it >was a >blocking socket. > >> --Andrew Church ><> >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From v13 at it.teithe.gr Mon Apr 15 00:43:10 2002 From: v13 at it.teithe.gr (Harhalakis Stefanos) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] ircservices5.0a28 various In-Reply-To: <3cba2895.14421@achurch.org> Message-ID: On Mon, 15 Apr 2002, Andrew Church wrote: > I can comprehend the manual page just fine without any assistance, > thank you. I was asking for someone who would be willing to actually test > this on both systems and see if it worked, not someone to explain it in > newbie-speak. This is not an explenation of the manual.. This is how I've implemented it and it is tested under linux and irix without any problem with heavy load regarding connections, without any problem... Anyway... sorry for trying to help... i'll try no to do it again... > --Andrew Church <> From achurch at achurch.org Wed Apr 17 17:21:33 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Services 5.0 alpha 29 released Message-ID: <3cbd3144.60322@achurch.org> Same old, same old. In response to the earlier question on when it will go beta: I'm hoping to get most of the remaining issues out of the way around the end of this month or the beginning of May (Golden Week in Japan, which is a one-and-a-half week period with no less than 4 holidays), so by June would be my best guess now. I know this is a lot later than I had originally said, but my job's gotten busy lately, so hey, what can you do... Version 5.0 alpha 29 -------------------- 2002/04/17 Fixed a warning in modules/nickserv/main.c. 2002/04/17 NickServ AUTH now keeps track of bad authorization codes, and kills users for multiple attempts as with passwords. 2002/04/17 SQlines are now checked after nickname changes. 2002/04/17 Fixed cosmetic bug with EXCEPTION LIST on an empty list. 2002/04/17 Fixed security hole with guest nicks allowing users to evade Services' notice. 2002/04/17 Added autokill exclusion support to xml-import. 2002/04/14 Fixed a cosmetic bug in the configure script. 2002/04/12 Newly-registered nicks no longer have kill protection set when not authorized (when the mail-auth module is in use). Reported by Ben Goldstein 2002/04/12 Fixed bug in NickServ AUTH replies. 2002/04/12 Fixed improper warning when loading channel database. Reported by Mark Hetherington 2002/04/10 Fixed bugs in trircd-services database conversion support. Reported by Yusuf Iskenderoglu --Andrew Church achurch@achurch.org http://achurch.org/ From ayottew at sympatico.ca Wed Apr 17 04:31:59 2002 From: ayottew at sympatico.ca (Wayne Ayotte) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Services 5.0 alpha 29 released References: <3cbd3144.60322@achurch.org> Message-ID: <001801c1e603$7cfcb0b0$0201a8c0@webdevint.com> sounds good to me Andrew, have a good one! Wayne A. ----- Original Message ----- From: "Andrew Church" To: Sent: Wednesday, April 17, 2002 4:21 AM Subject: [IRCServices Coding] Services 5.0 alpha 29 released > Same old, same old. In response to the earlier question on when it > will go beta: I'm hoping to get most of the remaining issues out of the way > around the end of this month or the beginning of May (Golden Week in Japan, > which is a one-and-a-half week period with no less than 4 holidays), so by > June would be my best guess now. I know this is a lot later than I had > originally said, but my job's gotten busy lately, so hey, what can you do... > > Version 5.0 alpha 29 > -------------------- > 2002/04/17 Fixed a warning in modules/nickserv/main.c. > 2002/04/17 NickServ AUTH now keeps track of bad authorization codes, > and kills users for multiple attempts as with passwords. > 2002/04/17 SQlines are now checked after nickname changes. > 2002/04/17 Fixed cosmetic bug with EXCEPTION LIST on an empty list. > 2002/04/17 Fixed security hole with guest nicks allowing users to > evade Services' notice. > 2002/04/17 Added autokill exclusion support to xml-import. > 2002/04/14 Fixed a cosmetic bug in the configure script. > 2002/04/12 Newly-registered nicks no longer have kill protection set > when not authorized (when the mail-auth module is in > use). Reported by Ben Goldstein > 2002/04/12 Fixed bug in NickServ AUTH replies. > 2002/04/12 Fixed improper warning when loading channel database. > Reported by Mark Hetherington > 2002/04/10 Fixed bugs in trircd-services database conversion support. > Reported by Yusuf Iskenderoglu > > --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 frostycoolslug at hotmail.com Wed Apr 17 04:41:28 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Services 5.0 alpha 29 released Message-ID: I (as i guess would the rest of this list..) would like to thank Andy for continuing to do a great job with services even though his job has been busy.. KEEP UP THE GOOD WORK!! :D >From: achurch@achurch.org (Andrew Church) >Reply-To: ircservices-coding@ircservices.za.net >To: ircservices-coding@ircservices.za.net >Subject: [IRCServices Coding] Services 5.0 alpha 29 released >Date: Wed, 17 Apr 2002 17:21:33 JST > > Same old, same old. In response to the earlier question on when it >will go beta: I'm hoping to get most of the remaining issues out of the way >around the end of this month or the beginning of May (Golden Week in Japan, >which is a one-and-a-half week period with no less than 4 holidays), so by >June would be my best guess now. I know this is a lot later than I had >originally said, but my job's gotten busy lately, so hey, what can you >do... > >Version 5.0 alpha 29 >-------------------- >2002/04/17 Fixed a warning in modules/nickserv/main.c. >2002/04/17 NickServ AUTH now keeps track of bad authorization codes, > and kills users for multiple attempts as with passwords. >2002/04/17 SQlines are now checked after nickname changes. >2002/04/17 Fixed cosmetic bug with EXCEPTION LIST on an empty list. >2002/04/17 Fixed security hole with guest nicks allowing users to > evade Services' notice. >2002/04/17 Added autokill exclusion support to xml-import. >2002/04/14 Fixed a cosmetic bug in the configure script. >2002/04/12 Newly-registered nicks no longer have kill protection set > when not authorized (when the mail-auth module is in > use). Reported by Ben Goldstein >2002/04/12 Fixed bug in NickServ AUTH replies. >2002/04/12 Fixed improper warning when loading channel database. > Reported by Mark Hetherington >2002/04/10 Fixed bugs in trircd-services database conversion support. > Reported by Yusuf Iskenderoglu > > --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 -- Craig McLure Craig@e-tidalwave.org WaveAdmin on the e-tidalwave IRC Network Network Administrator of the ChatSpike 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 gizm0 at mail.gr Fri Apr 19 00:49:31 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Possible bugs Message-ID: <101916657101@mailserver.mail.gr> This is a bug or i just don't do sth right. When i umode +a myself and then whois me there is no - Services Admin text after the IRC Operator. e.g » Gizm0 (zeus@fifth.element) » ircname: ... » server: no.spam » status: has identified for this nick » Gizm0 is an IRC Operator the - Services admin is missing.It used to be » Gizm0 (~zeus@fifth.element) » ircname: ... » server: no.spam » status: has identified for this nick » Gizm0 is an IRC Operator - Services admin when i umode +a Gizm0,services didn't accept it.Doing /mode gizm0 returned : +oiwscrkydegbfnmht ( "a" is missing ). I changed nick , i've su and del Gizm0 from the admins database.Then i add him again and it was the same.I did that to check if it is was database error or something.I've also registered a new nick and add it to the admins database but it didn't work either.When i tried to drop a nick as a services admin,services didn't permmit me.It just counted down one wrong password attempt and noticed me : -Nickserv- Password incorrect. The strange is that when i tried to list the access list of a channel i didn't have access , it worked fine.I saw the access list , as i should. This (- Services admin ) used to be on 4.5.x releases and it was quite usefull because you could know if someone is a services admin or not and choose if you want to ask him whatever you want. Another cosmetic bug.When the NICKCHANGE(sth like this,don't remember) instead of NICKKILL(don't remember either) and nick kill protection is on , this text is wrong : -NickServ- If you do not change within one minute, _you will be disconnected._ Should be sth different.Sth like : -NickServ- If you do not change within one minute, i will change your nick to something when protection is on and NICKCHANGE is defined instead of NICKKILL. When i turned off the kill protection it worked fine.Services didn't display the "you will be disconnected." text. That's all Andrew. Thank you, Gizm0 ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From richard at powell.co.za Thu Apr 18 23:37:06 2002 From: richard at powell.co.za (Richard Powell) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Possible bugs References: <101916657101@mailserver.mail.gr> Message-ID: <000901c1e76c$9fc02ae0$0300a8c0@md> uhm, that's because the UMODE +a is meant for services to use. If you are listed as a services admin in the ircservices database/configuration, as soon as you identify to nickserv and operserv recognises you as an operator ircservices will add the +a flag to your UMODE. Hope that makes sence.. Richard (netadmin, bubblenet.org) ----- Original Message ----- From: "Panagiotis Kefalidis ( Gizm0 )" To: Sent: Friday, April 19, 2002 1:49 AM Subject: [IRCServices Coding] Possible bugs > This is a bug or i just don't do sth right. > When i umode +a myself and then whois me there is no > - Services Admin text after the IRC Operator. > e.g > ? Gizm0 (zeus@fifth.element) > ? ircname: ... > ? server: no.spam > ? status: has identified for this nick > ? Gizm0 is an IRC Operator > the - Services admin is missing.It used to be > > ? Gizm0 (~zeus@fifth.element) > ? ircname: ... > ? server: no.spam > ? status: has identified for this nick > ? Gizm0 is an IRC Operator - Services admin > when i umode +a Gizm0,services didn't accept it.Doing /mode gizm0 > returned : +oiwscrkydegbfnmht ( "a" is missing ). > I changed nick , i've su and del Gizm0 from the admins database.Then i > add him again and it was the same.I did that to check if it is was > database error or something.I've also registered a new nick and add it to > the admins database but it didn't work either.When i tried to drop a nick > as a services admin,services didn't permmit me.It just counted down one > wrong password attempt and noticed me : > -Nickserv- Password incorrect. > The strange is that when i tried to list the access list of a channel i > didn't have access , it worked fine.I saw the access list , as i should. > This (- Services admin ) used to be on 4.5.x releases and it was quite > usefull because you could know if someone is a services admin or not and > choose if you want to ask him whatever you want. > > Another cosmetic bug.When the NICKCHANGE(sth like this,don't remember) > instead of NICKKILL(don't remember either) and nick kill protection is on > , this text is wrong : > -NickServ- If you do not change within one minute, _you will be > disconnected._ Should be sth different.Sth like : > -NickServ- If you do not change within one minute, i will change your > nick to something when protection is on and NICKCHANGE is defined instead > of NICKKILL. > When i turned off the kill protection it worked fine.Services didn't > display the "you will be disconnected." text. > That's all Andrew. > > Thank you, > Gizm0 > > ------------------------------------------------------------- > http://www.mail.gr/ - Get Your Private Free Email Address! > http://www.ringtone.gr/ - Ringtones & Logos for your mobile! > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From gizm0 at mail.gr Fri Apr 19 23:18:11 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Possible bugs Message-ID: <101924749101@mailserver.mail.gr> Richard, > uhm, that's because the UMODE +a is meant for services to use. If you are > listed as a services admin in the ircservices database/configuration, as > soon as you identify to nickserv and operserv recognises you as an > operator > ircservices will add the +a flag to your UMODE. Exactly.But services DONT UMODE +a me even if when i identify to nickserv,take operator status and have access to operserv.i'm added in services admin, but UMODE +a is still missing.Any ideas?And the thing that the drop on the nick doesn't work is wrong.i just forgot that the command is change to dropnick and not just drop as it used to be.Also when i raw to nickserv with /operserv raw :nickserv SVSMODE Gizm0 +a,then it works fine.in the whois there is the line "-Services Administrator".Don't know ... I'm quite confused and i can't understand on earth is going on.:/Am i doing sth wrong or just the services have a bug. Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From gizm0 at mail.gr Sun Apr 21 15:04:44 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Bug or sth? Message-ID: <101939068401@mailserver.mail.gr> [Apr 20 12:55:26 2002] PANIC! buffer = :Scouter PRIVMSG NickServ@services.ircn.gr :set [Apr 20 12:55:27 2002] Services terminating: Segmentation fault What's this?a bug or sth? Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From A_V at ptirc.com Sun Apr 21 05:42:05 2002 From: A_V at ptirc.com (A_V@ptirc.com) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Sugestion.... Message-ID: my sugestion: the command /chanserv set #channel secure on will do add +R (unreal mode) in the mlock channel, case Secure off the services del +R of mlock.... ;) Abel Vieira aka A_V Portugal From r-krisztian at softhome.net Sun Apr 21 08:44:57 2002 From: r-krisztian at softhome.net (Romek =?iso-8859-1?q?Kriszti=E9n?=) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Bug or sth? In-Reply-To: <101939068401@mailserver.mail.gr> References: <101939068401@mailserver.mail.gr> Message-ID: <02042117445700.21149@adsl52091> I don't know much about your services program. Please tell me what version you use! We cannot help you while you don't tell us enough about the problem! I think you use 5.0a26 because there were some problems with this version. Pls upgrade to the latest version! AngryWolf From squall157 at Hotmail.com Sun Apr 21 13:36:59 2002 From: squall157 at Hotmail.com (Tom Moyer) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Addition. References: <101939068401@mailserver.mail.gr> <02042117445700.21149@adsl52091> Message-ID: Here is a good addition. I donno if its already in IRC services. If it is then someone tell me why it dosent work when i installed IRC services. Op on Identify. IE: When a user identifys to their nickname.. Have Chanserv Op them in all the channels they hold ops in. From achurch at achurch.org Mon Apr 22 11:22:03 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Addition. Message-ID: <3cc373d7.70530@achurch.org> This is scheduled for 5.0. --Andrew Church achurch@achurch.org http://achurch.org/ >Here is a good addition. I donno if its already in IRC services. If it is >then someone tell me why it dosent work when i installed IRC services. Op >on Identify. >IE: When a user identifys to their nickname.. Have Chanserv Op them in all >the channels they hold ops in. >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From squall157 at Hotmail.com Sun Apr 21 20:30:33 2002 From: squall157 at Hotmail.com (Tom Moyer) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request References: <3cc373d7.70530@achurch.org> Message-ID: ok here is a Feature request. And forgive me if this isnt possible... 1. A serv or way in Operserv for IRCOPS to set ppls host. IE Unreal has a command that i can change peoples hosts with. Perhaps store this in the nickserv Databases. 2. Global Memos, Login News, and onjoin News 3. This is something alot of people hate, but is the only reason i use auspice ever... A botServ. To make bots only accessible by admins of course. 4. i think i read this in one of IRC Services features but ill request it because im not completely sure that it does it. The ability to Identify for multiple nicknames. IE if i dont want to link 2 nicks. And i wish to identify to bob and bill.. 5. I know you will shoot me for this one. Since we have an admin section in the HTML. MAybe make a User section where they can register nicks Retreive Memos. and posibly have it act as a java client for the users.... I have a few other ideas as well.. Ill give it a rest and wait on a responce to this one From griever at t2n.org Sun Apr 21 20:44:03 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request In-Reply-To: Message-ID: On Sun, 21 Apr 2002, Tom Moyer wrote: > ok here is a Feature request. > And forgive me if this isnt possible... > > 1. A serv or way in Operserv for IRCOPS to set ppls host. IE Unreal has a > command that i can change peoples hosts with. Perhaps store this in the > nickserv Databases. Nice try copying axenet > > 2. Global Memos, Login News, and onjoin News Already there > > 3. This is something alot of people hate, but is the only reason i use > auspice ever... A botServ. To make bots only accessible by admins of > course. > Must...control...fist of death... > 4. i think i read this in one of IRC Services features but ill request it > because im not completely sure that it does it. The ability to Identify for > multiple nicknames. IE if i dont want to link 2 nicks. And i wish to > identify to bob and bill.. > > 5. I know you will shoot me for this one. Since we have an admin section in > the HTML. MAybe make a User section where they can register nicks Retreive > Memos. and posibly have it act as a java client for the users.... Bang. Anyhow, since ircservices will have MySQL database support, you could just write all that in PHP. > > I have a few other ideas as well.. Ill give it a rest and wait on a responce > to this one > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From achurch at achurch.org Mon Apr 22 13:06:09 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request Message-ID: <3cc38ce2.70572@achurch.org> >1. A serv or way in Operserv for IRCOPS to set ppls host. IE Unreal has a >command that i can change peoples hosts with. So, um, just use that command. I may add Services support in a later version but it's a low priority. >2. Global Memos, Login News, and onjoin News Unneeded (login news does the same thing), already present, and already present. >3. This is something alot of people hate, but is the only reason i use >auspice ever... A botServ. To make bots only accessible by admins of >course. I won't even comment on this. >4. i think i read this in one of IRC Services features but ill request it >because im not completely sure that it does it. The ability to Identify for >multiple nicknames. IE if i dont want to link 2 nicks. And i wish to >identify to bob and bill.. You can't identify directly, but Services will remember all the nicks you have identified for as long as you're connected, which in effect does the same thing. >5. I know you will shoot me for this one. Since we have an admin section in >the HTML. MAybe make a User section where they can register nicks Retreive >Memos. and posibly have it act as a java client for the users.... *bang* --Andrew Church achurch@achurch.org http://achurch.org/ From r-krisztian at softhome.net Sun Apr 21 21:32:39 2002 From: r-krisztian at softhome.net (Romek Krisztián) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] ircservices-5.0a29 - Bug (?) References: <3cc373d7.70530@achurch.org> Message-ID: <001f01c1e9b6$be808d20$0b00000a@rokusnet.hu> I can't tell you more. *** Global -- from services.freechat.ods.org: PANIC! buffer = :Asmodeus PRIVMSG nickserv@services.freechat.ods.org :info PCWC *** LocOps -- Received SQUIT services.freechat.ods.org from services.freechat.ods.org[127.0.0.1] (Services terminating: Segmentation fault) AngryWolf From squall157 at Hotmail.com Sun Apr 21 21:38:41 2002 From: squall157 at Hotmail.com (Tom Moyer) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request References: <3cc38ce2.70572@achurch.org> Message-ID: > >5. I know you will shoot me for this one. Since we have an admin section in > >the HTML. MAybe make a User section where they can register nicks Retreive > >Memos. and posibly have it act as a java client for the users.... What is so bad about this? ----- Original Message ----- From: "Andrew Church" To: Sent: Sunday, April 21, 2002 9:06 PM Subject: Re: [IRCServices Coding] Feature Request > >1. A serv or way in Operserv for IRCOPS to set ppls host. IE Unreal has a > >command that i can change peoples hosts with. > > So, um, just use that command. I may add Services support in a later > version but it's a low priority. > > >2. Global Memos, Login News, and onjoin News > > Unneeded (login news does the same thing), already present, and > already present. > > >3. This is something alot of people hate, but is the only reason i use > >auspice ever... A botServ. To make bots only accessible by admins of > >course. > > I won't even comment on this. > > >4. i think i read this in one of IRC Services features but ill request it > >because im not completely sure that it does it. The ability to Identify for > >multiple nicknames. IE if i dont want to link 2 nicks. And i wish to > >identify to bob and bill.. > > You can't identify directly, but Services will remember all the nicks > you have identified for as long as you're connected, which in effect does > the same thing. > > >5. I know you will shoot me for this one. Since we have an admin section in > >the HTML. MAybe make a User section where they can register nicks Retreive > >Memos. and posibly have it act as a java client for the users.... > > *bang* > > --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 gizm0 at mail.gr Mon Apr 22 10:12:35 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] ircservices-5.0a29 - Bug (?) Message-ID: <101945955501@mailserver.mail.gr> > I can't tell you more. > > *** Global -- from services.freechat.ods.org: PANIC! buffer = :Asmodeus > PRIVMSG nickserv@services.freechat.ods.org :info PCWC > *** LocOps -- Received SQUIT services.freechat.ods.org from > services.freechat.ods.org[127.0.0.1] (Services terminating: Segmentation > fault) I go the same error too.I've mention it in one of my previous emails but i forgot to tell you what version i use.It's IRCServices-5.0a29. > > AngryWolf And btw is the global noticer working?I've tried several times to global notice using /operserv global Message and didn't work. Regards, Gizm0 ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From uhc0 at rz.uni-karlsruhe.de Mon Apr 22 01:32:18 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:22 2004 Subject: AW: [IRCServices Coding] ircservices-5.0a29 - Bug (?) In-Reply-To: <101945955501@mailserver.mail.gr> Message-ID: <000001c1e9d8$48a11ad0$02c8a8c0@nygmatech.local> Which ircd are you using ? I guess bahamut, due to a prior private email from you. Are you sure, you have correctly set the common domain name for your network when configuring services ? "ircn.gr" should be entered, and not ".ircn.gr" Test it via raw: /os raw :Global NOTICE $*.ircn.gr :Test message 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 Panagiotis Kefalidis ( Gizm0 ) > Gesendet: Montag, 22. April 2002 12:13 > An: ircservices-coding@ircservices.za.net > Betreff: Re: [IRCServices Coding] ircservices-5.0a29 - Bug (?) > > > > I can't tell you more. > > > > *** Global -- from services.freechat.ods.org: PANIC! buffer = > > :Asmodeus PRIVMSG nickserv@services.freechat.ods.org :info PCWC > > *** LocOps -- Received SQUIT services.freechat.ods.org from > > services.freechat.ods.org[127.0.0.1] (Services terminating: > > Segmentation > > fault) > I go the same error too.I've mention it in one of my previous > emails but i forgot to tell you what version i use.It's > IRCServices-5.0a29. > > > > AngryWolf > And btw is the global noticer working?I've tried several > times to global notice using /operserv global Message and > didn't work. Regards, Gizm0 > > ------------------------------------------------------------- > http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From gizm0 at mail.gr Mon Apr 22 14:54:01 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:22 2004 Subject: AW: [IRCServices Coding] ircservices-5.0a29 - Bug (?) Message-ID: <101947644101@mailserver.mail.gr> > Which ircd are you using ? > I guess bahamut, due to a prior private email from you. > > Are you sure, you have correctly set the common domain name for your > network when configuring services ? "ircn.gr" should be entered, and not > ".ircn.gr" yusuf where is this configured anyway?i didn't found any line on the modules.conf. > > Test it via raw: > > /os raw :Global NOTICE $*.ircn.gr :Test message didn't worked. > > Regards; > yusuf > Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From uhc0 at rz.uni-karlsruhe.de Mon Apr 22 05:27:32 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:22 2004 Subject: AW: AW: [IRCServices Coding] ircservices-5.0a29 - Bug (?) In-Reply-To: <101947644101@mailserver.mail.gr> Message-ID: <000001c1e9f9$2548c8a0$02c8a8c0@nygmatech.local> Hi, The directive NetworkDomain is required by protocol module configuration, in order to make global noticer work, seems that Andy has forgotten it to include in the example configuration file. Nobody is perfect ;-) Additionally, you have to set AllowRaw in operserv module configuration, to be able to use the RAW command. And it has to work :-) 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 Panagiotis Kefalidis ( Gizm0 ) > Gesendet: Montag, 22. April 2002 16:54 > An: ircservices-coding@ircservices.za.net > Betreff: Re: AW: [IRCServices Coding] ircservices-5.0a29 - Bug (?) > > > > Which ircd are you using ? > > I guess bahamut, due to a prior private email from you. > > > > Are you sure, you have correctly set the common domain name > for your > > network when configuring services ? "ircn.gr" should be > entered, and > > not ".ircn.gr" > yusuf where is this configured anyway?i didn't found any line > on the modules.conf. > > > > Test it via raw: > > > > /os raw :Global NOTICE $*.ircn.gr :Test message > didn't worked. > > > > Regards; > > yusuf > > > Gizm0.- > > ------------------------------------------------------------- > http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From gizm0 at mail.gr Mon Apr 22 15:21:27 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:22 2004 Subject: AW: AW: [IRCServices Coding] ircservices-5.0a29 - Bug (?) Message-ID: <101947808701@mailserver.mail.gr> > > Hi, > > The directive > NetworkDomain > is required by protocol module configuration, in order to make > global noticer work, seems that Andy has forgotten it to include > in the example configuration file. Nobody is perfect ;-) thanx for that ;) > > Additionally, you have to set AllowRaw in operserv module configuration, RAW is already allowed but it still doesn't work. > to be able to use the RAW command. > And it has to work :-) > > 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 Panagiotis Kefalidis ( Gizm0 ) > > Gesendet: Montag, 22. April 2002 16:54 > > An: ircservices-coding@ircservices.za.net > > Betreff: Re: AW: [IRCServices Coding] ircservices-5.0a29 - Bug (?) > > > > > > > Which ircd are you using ? > > > I guess bahamut, due to a prior private email from you. > > > > > > Are you sure, you have correctly set the common domain name > > for your > > > network when configuring services ? "ircn.gr" should be > > entered, and > > > not ".ircn.gr" > > yusuf where is this configured anyway?i didn't found any line > > on the modules.conf. > > > > > > Test it via raw: > > > > > > /os raw :Global NOTICE $*.ircn.gr :Test message > > didn't worked. > > > > > > Regards; > > > yusuf > > > > > Gizm0.- > > > > ------------------------------------------------------------- > > http://www.mail.gr/ - Get Your Private Free Email Address! > http://www.ringtone.gr/ - Ringtones & Logos for your mobile! > ------------------------------------------------------------------ > 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 "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From smkelly at zombie.org Mon Apr 22 19:43:17 2002 From: smkelly at zombie.org (Sean Kelly) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request In-Reply-To: References: <3cc38ce2.70572@achurch.org> Message-ID: <20020423024317.GA14948@edgemaster.zombie.org> On Sun, Apr 21, 2002 at 09:38:41PM -0700, Tom Moyer wrote: > > >5. I know you will shoot me for this one. Since we have an admin section > in > > >the HTML. MAybe make a User section where they can register nicks > Retreive > > >Memos. and posibly have it act as a java client for the users.... > > What is so bad about this? Well, I can't speak for anybody else here but I'll give you my opinion. See, Services are more of a program to serve on IRC. When you start tacking on crap like a java client, you are extending them beyond their designed purpose. for one, to have a useful java client you'd most likely want to get it signed. So now you're talking about having Services serve signed java out via a web server, which I presume you want to also be built into services? It is a waste. Go buy jIRC, javirc, or use eirc. That is their designed purpose. As for registering nicknames via a web interface, this will be possible if/when Services have MySQL support in them. My network, SlashNET, has already built a rather comprehensive website based on live IRC data and Services database data (http://www.slashnet.org/). It isn't really hard to do it *outside of services* if you know what you are doing and have the time to do it. -- Sean Kelly | PGP KeyID: 77042C7B smkelly@zombie.org | http://www.zombie.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20020422/88845b9f/attachment.pgp From squall157 at Hotmail.com Tue Apr 23 11:20:20 2002 From: squall157 at Hotmail.com (Tom Moyer) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request References: <3cc38ce2.70572@achurch.org> <20020423024317.GA14948@edgemaster.zombie.org> Message-ID: So not talking about the java Chat side, what about Registering Nicknames online, and possibly having a memo Retrival system online. So it can be accessed Via HTTP? ----- Original Message ----- From: "Sean Kelly" To: Sent: Monday, April 22, 2002 7:43 PM Subject: Re: [IRCServices Coding] Feature Request From rg at tcslon.com Tue Apr 23 12:42:14 2002 From: rg at tcslon.com (Russ Garrett) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request References: <3cc38ce2.70572@achurch.org> <20020423024317.GA14948@edgemaster.zombie.org> Message-ID: <3CC5B916.30800@tcslon.com> Tom Moyer wrote: >So not talking about the java Chat side, what about Registering Nicknames >online, and possibly having a memo Retrival system online. So it can be >accessed Via HTTP? > > I think it raises the same point - to be honest I don't like a web interface on the end of services at all - IMHO any external (non-IRC) access should be on another heavily-access-controlled end of the database. Although I have all faith in Andy's web server coding, I'd rather my web access was done by a web server, and my IRC services handled by services, both sharing a common database backend (any news on the MySql plugin? ;) - this is the whole point in unix in general - many specialist programs working together, to a better (faster, more secure) end than one large behemoth of a services/web server/microwave/kitchen sink. BTW, I haven't been around much because we've merged with some friends' net, who run Epona, so that spares you my endless XML nit-picking until I can convert them to IRCServices ("friends don't let friends use Epona" ;). Russ Garrett (russ@garrett.co.uk) Shameless Plug: http://www.faereal.net From gizm0 at mail.gr Tue Apr 23 23:53:17 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Bug for sure! Message-ID: <101959519701@mailserver.mail.gr> [00:02] -- *** Global -- from : PANIC! buffer = :Scouter PRIVMSG NickServ@services.ircn.gr :set [00:02] -- *** Routing -- from : Received SQUIT services.ircn.gr from services.ircn.gr[unknown@0.0.0.0] (Services terminating: Segmentation fault) Got this after trying to /chanserv set #channel enforce on or off Can reproduce this error.Running bahamut ircd and ircservices5a29. This MUST be fixed and i'm still try to track this bug down. "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From gizm0 at mail.gr Wed Apr 24 00:00:01 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] BUG-Another one in a few minutes. Message-ID: <101959560101@mailserver.mail.gr> [00:05] -- *** Global -- from : PANIC! buffer = :Scouter PRIVMSG NickServ@services.ircn.gr :set help - [00:05] -- *** Routing -- from : Received SQUIT services.ircn.gr from [unknown@0.0.0.0] (Services terminating: Segmentation fault) Got this when trying to /nickserv set help by mistake.Running bahamut,can reproduce the error.Running ircservices5a29. "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From gizm0 at mail.gr Wed Apr 24 00:03:36 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] BUG-Anotherone! Message-ID: <101959581701@mailserver.mail.gr> sorry for that but i found them one after the other a few minutes after sending the emails. [00:15] -chaos.us.ircn.gr- *** Global -- from services.ircn.gr: PANIC! buffer = :Gizm0 PRIVMSG NickServ@services.ircn.gr :set - [00:15] -chaos.us.ircn.gr- *** Routing -- from chaos.us.ircn.gr: Received SQUIT services.ircn.gr from services.ircn.gr[unknown@0.0.0.0] (Services terminating: Segmentation fault) - when trying to /ns set and /cs set without an option services got the down way.Bahamut again . ircservices5a29 "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From squall157 at Hotmail.com Tue Apr 23 18:10:45 2002 From: squall157 at Hotmail.com (Tom Moyer) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request References: <3cc38ce2.70572@achurch.org> <20020423024317.GA14948@edgemaster.zombie.org> <3CC5B916.30800@tcslon.com> Message-ID: here is another one... I know unreal has Proxy checking, but it dosent work half the time due to Operating system conflicts. Some shells it works with some it dosent. Can this be intergrated in to services? From eengin at talesoft.de Tue Apr 23 18:16:26 2002 From: eengin at talesoft.de (Ekim Engin) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request In-Reply-To: Message-ID: <0e8401c1eb2d$a80107a0$0155a8c0@talesoft.de> > -----Original Message----- > From: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net] On > Behalf Of Tom Moyer > Sent: Wednesday, April 24, 2002 3:11 AM > To: ircservices-coding@ircservices.za.net > Subject: [IRCServices Coding] Feature Request > > > here is another one... I know unreal has Proxy checking, but > it dosent work > half the time due to Operating system conflicts. Some shells > it works with > some it dosent. Can this be intergrated in to services? I would say: It can, but wont as it has nothig to do with services at all There are enought third Party tools which provide this feature Greets Ekim Engin +------------------------+------------------------+ | Talesin aka Ekim Engin | ircadmin@ttnet.net.tr | | IRC Administration | http://www.ttchat.net | | TTNet Network (Turkey) | irc://irc.ttnet.net.tr | |------------------------^------------------------| | < 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 squall157 at Hotmail.com Tue Apr 23 18:25:45 2002 From: squall157 at Hotmail.com (Tom Moyer) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request References: <0e8401c1eb2d$a80107a0$0155a8c0@talesoft.de> Message-ID: hmmm ok heh what tools can i install on a unix box that will link to my server and provide proxy checking. I know Epona Sux But epona does have proxy checking. And im sure irc services wants to open a market to users who have a need for things of this nature, why would irc services want to loose thease potential admins because this feature was unavalive.... ----- Original Message ----- From: "Ekim Engin" To: Sent: Tuesday, April 23, 2002 6:16 PM Subject: RE: [IRCServices Coding] Feature Request > > -----Original Message----- > > From: ircservices-coding-admin@ircservices.za.net > > [mailto:ircservices-coding-admin@ircservices.za.net] On > > Behalf Of Tom Moyer > > Sent: Wednesday, April 24, 2002 3:11 AM > > To: ircservices-coding@ircservices.za.net > > Subject: [IRCServices Coding] Feature Request > > > > > > here is another one... I know unreal has Proxy checking, but > > it dosent work > > half the time due to Operating system conflicts. Some shells > > it works with > > some it dosent. Can this be intergrated in to services? > > I would say: It can, but wont as it has nothig to do with services at > all > > There are enought third Party tools which provide this feature > > Greets > Ekim Engin > > +------------------------+------------------------+ > | Talesin aka Ekim Engin | ircadmin@ttnet.net.tr | > | IRC Administration | http://www.ttchat.net | > | TTNet Network (Turkey) | irc://irc.ttnet.net.tr | > |------------------------^------------------------| > | < Chat begins as it ends - without reason > | > +-------------------------------------------------+ > > > ------------------------------------------------------------------ > > 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 Wed Apr 24 10:36:51 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request Message-ID: <3cc60cd9.11027@achurch.org> I don't give a damn about "markets" or losing users. I'm writing Services because some people find it useful, and that's enough for me. If there are people who aren't happy with Services, then they're more than welcome to either use another program, or modify Services themselves (as, I might point out, the author of Epona has done). --Andrew Church achurch@achurch.org http://achurch.org/ >hmmm >ok heh what tools can i install on a unix box that will link to my server >and provide proxy checking. >I know Epona Sux But epona does have proxy checking. And im sure irc >services wants to open a market to users who have a need for things of this >nature, why would irc services want to loose thease potential admins because >this feature was unavalive.... >----- Original Message ----- >From: "Ekim Engin" >To: >Sent: Tuesday, April 23, 2002 6:16 PM >Subject: RE: [IRCServices Coding] Feature Request > > >> > -----Original Message----- >> > From: ircservices-coding-admin@ircservices.za.net >> > [mailto:ircservices-coding-admin@ircservices.za.net] On >> > Behalf Of Tom Moyer >> > Sent: Wednesday, April 24, 2002 3:11 AM >> > To: ircservices-coding@ircservices.za.net >> > Subject: [IRCServices Coding] Feature Request >> > >> > >> > here is another one... I know unreal has Proxy checking, but >> > it dosent work >> > half the time due to Operating system conflicts. Some shells >> > it works with >> > some it dosent. Can this be intergrated in to services? >> >> I would say: It can, but wont as it has nothig to do with services at >> all >> >> There are enought third Party tools which provide this feature >> >> Greets >> Ekim Engin >> >> +------------------------+------------------------+ >> | Talesin aka Ekim Engin | ircadmin@ttnet.net.tr | >> | IRC Administration | http://www.ttchat.net | >> | TTNet Network (Turkey) | irc://irc.ttnet.net.tr | >> |------------------------^------------------------| >> | < Chat begins as it ends - without reason > | >> +-------------------------------------------------+ >> >> > ------------------------------------------------------------------ >> > 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 Wed Apr 24 10:45:47 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Sugestion.... Message-ID: <3cc60e65.11060@achurch.org> >the command /chanserv set #channel secure on will >do add +R (unreal mode) in the mlock channel, case >Secure off the services del +R of mlock.... This isn't what the SECURE option does. If you want +R, set +R. --Andrew Church achurch@achurch.org http://achurch.org/ From squall157 at Hotmail.com Tue Apr 23 19:10:36 2002 From: squall157 at Hotmail.com (Tom Moyer) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request References: <3cc60cd9.11027@achurch.org> Message-ID: lmao I understand and i agree. But i figured this was a forum for bringing up new features i would like to see in your services not to have ppl tell me there is no use for that. or why do that you can use another program to do it.... Some of us are using shell accounts. i can only use 2 backgrounds. at any rate the things i bring up to yall are things that i find verry useful. The admins on my network Find them verry useful and i was hopeing to see them in services. Now the webserver thing was an awesome idea, but if it takes up to much space i understand. Also im not trying to copy other networks. I mentioned the hostname service or hostname feature in nickserv because im using auspices(gag) and it has that feature. I dont necisarily like auspices, but it has the features i want =\. Except Proxy checking. Proxy checking may not be the Best of suggestions, but if one person thinks it is usefull maybe some of your other loyal users may aswell. I have used your services in the past andy. And i have enjoyed them. I remember when i had a net A few years ago and your services were called Esper. I guess after the network they were primarily used on. My point is this i had hoped i could bring up a few features that i wanted to see. And maybe see them. =\ But i didnt want to bring up ideas and be told that my ideas sucked LMAO. =) ----- Original Message ----- From: "Andrew Church" To: Sent: Tuesday, April 23, 2002 6:36 PM Subject: Re: [IRCServices Coding] Feature Request > I don't give a damn about "markets" or losing users. I'm writing > Services because some people find it useful, and that's enough for me. > If there are people who aren't happy with Services, then they're more > than welcome to either use another program, or modify Services themselves > (as, I might point out, the author of Epona has done). > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > > >hmmm > >ok heh what tools can i install on a unix box that will link to my server > >and provide proxy checking. > >I know Epona Sux But epona does have proxy checking. And im sure irc > >services wants to open a market to users who have a need for things of this > >nature, why would irc services want to loose thease potential admins because > >this feature was unavalive.... > >----- Original Message ----- > >From: "Ekim Engin" > >To: > >Sent: Tuesday, April 23, 2002 6:16 PM > >Subject: RE: [IRCServices Coding] Feature Request > > > > > >> > -----Original Message----- > >> > From: ircservices-coding-admin@ircservices.za.net > >> > [mailto:ircservices-coding-admin@ircservices.za.net] On > >> > Behalf Of Tom Moyer > >> > Sent: Wednesday, April 24, 2002 3:11 AM > >> > To: ircservices-coding@ircservices.za.net > >> > Subject: [IRCServices Coding] Feature Request > >> > > >> > > >> > here is another one... I know unreal has Proxy checking, but > >> > it dosent work > >> > half the time due to Operating system conflicts. Some shells > >> > it works with > >> > some it dosent. Can this be intergrated in to services? > >> > >> I would say: It can, but wont as it has nothig to do with services at > >> all > >> > >> There are enought third Party tools which provide this feature > >> > >> Greets > >> Ekim Engin > >> > >> +------------------------+------------------------+ > >> | Talesin aka Ekim Engin | ircadmin@ttnet.net.tr | > >> | IRC Administration | http://www.ttchat.net | > >> | TTNet Network (Turkey) | irc://irc.ttnet.net.tr | > >> |------------------------^------------------------| > >> | < Chat begins as it ends - without reason > | > >> +-------------------------------------------------+ > >> > >> > ------------------------------------------------------------------ > >> > 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 achurch at achurch.org Wed Apr 24 10:53:56 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:22 2004 Subject: AW: AW: [IRCServices Coding] ircservices-5.0a29 - Bug (?) Message-ID: <3cc61590.11760@achurch.org> >The directive >NetworkDomain >is required by protocol module configuration, in order to make >global noticer work, seems that Andy has forgotten it to include >in the example configuration file. Nobody is perfect ;-) Well, I'll be damned... I wonder where that went. Fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Wed Apr 24 11:17:56 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request Message-ID: <3cc61732.12002@achurch.org> You're always welcome to submit feature requests, but when you start making arguments about markets and losing users that's overdoing it. You might also find FAQs Z.5 and Z.6 edifying. --Andrew Church achurch@achurch.org http://achurch.org/ >lmao >I understand and i agree. >But i figured this was a forum for bringing up new features i would like to >see in your services not to have ppl tell me there is no use for that. or >why do that you can use another program to do it.... Some of us are using >shell accounts. i can only use 2 backgrounds. at any rate the things i >bring up to yall are things that i find verry useful. The admins on my >network Find them verry useful and i was hopeing to see them in services. >Now the webserver thing was an awesome idea, but if it takes up to much >space i understand. Also im not trying to copy other networks. I mentioned >the hostname service or hostname feature in nickserv because im using >auspices(gag) and it has that feature. I dont necisarily like auspices, but >it has the features i want =\. Except Proxy checking. Proxy checking may >not be the Best of suggestions, but if one person thinks it is usefull maybe >some of your other loyal users may aswell. I have used your services in the >past andy. And i have enjoyed them. I remember when i had a net A few >years ago and your services were called Esper. I guess after the network >they were primarily used on. > >My point is this i had hoped i could bring up a few features that i wanted >to see. And maybe see them. =\ But i didnt want to bring up ideas and be >told that my ideas sucked LMAO. =) >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Wed Apr 24 11:27:53 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Bug for sure! Message-ID: <3cc61843.12022@achurch.org> >[00:02] -- *** Global -- from : PANIC! buffer = :Scouter PRIVMSG >NickServ@services.ircn.gr :set >[00:02] -- *** Routing -- from : Received SQUIT services.ircn.gr from >services.ircn.gr[unknown@0.0.0.0] (Services terminating: Segmentation fault) Fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Wed Apr 24 12:16:25 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] ircservices-5.0a29 - Bug (?) Message-ID: <3cc62461.12677@achurch.org> >*** Global -- from services.freechat.ods.org: PANIC! buffer = :Asmodeus >PRIVMSG nickserv@services.freechat.ods.org :info PCWC >*** LocOps -- Received SQUIT services.freechat.ods.org from >services.freechat.ods.org[127.0.0.1] (Services terminating: Segmentation >fault) I can't see an obvious cause for this. Can you consistently reproduce the problem? If so, please send me (privately) your database files. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Wed Apr 24 13:15:53 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Possible bugs Message-ID: <3cc63353.23433@achurch.org> >This is a bug or i just don't do sth right. >When i umode +a myself and then whois me there is no >- Services Admin text after the IRC Operator. >e.g >? Gizm0 (zeus@fifth.element) >? ircname: ... >? server: no.spam >? status: has identified for this nick >? Gizm0 is an IRC Operator >the - Services admin is missing.It used to be You're using Bahamut, right? Found and fixed, thanks. >When i tried to drop a nick >as a services admin,services didn't permmit me.It just counted down one >wrong password attempt and noticed me : >-Nickserv- Password incorrect. The command for a Services admin to drop a nick has been changed to DROPNICK. >Another cosmetic bug.When the NICKCHANGE(sth like this,don't remember) >instead of NICKKILL(don't remember either) and nick kill protection is on >, this text is wrong : >-NickServ- If you do not change within one minute, _you will be >disconnected._ Should be sth different.Sth like : >-NickServ- If you do not change within one minute, i will change your >nick to something when protection is on and NICKCHANGE is defined instead >of NICKKILL. Thanks for the report, I'll look into this. --Andrew Church achurch@achurch.org http://achurch.org/ From uhc0 at rz.uni-karlsruhe.de Wed Apr 24 03:29:45 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:22 2004 Subject: AW: [IRCServices Coding] Feature Request In-Reply-To: Message-ID: <003e01c1eb7b$05d56360$02c8a8c0@nygmatech.local> Since proxy checking is really not a job for services, you can install BOPM, available at http://www.blitzed.org/bopm/ 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 Tom Moyer > Gesendet: Mittwoch, 24. April 2002 03:26 > An: ircservices-coding@ircservices.za.net > Betreff: Re: [IRCServices Coding] Feature Request > > > hmmm > ok heh what tools can i install on a unix box that will link > to my server and provide proxy checking. I know Epona Sux But > epona does have proxy checking. And im sure irc services > wants to open a market to users who have a need for things of > this nature, why would irc services want to loose thease > potential admins because this feature was unavalive.... > ----- Original Message ----- > From: "Ekim Engin" > To: > Sent: Tuesday, April 23, 2002 6:16 PM > Subject: RE: [IRCServices Coding] Feature Request > > > > > -----Original Message----- > > > From: ircservices-coding-admin@ircservices.za.net > > > [mailto:ircservices-coding-admin@ircservices.za.net] On Behalf Of > > > Tom Moyer > > > Sent: Wednesday, April 24, 2002 3:11 AM > > > To: ircservices-coding@ircservices.za.net > > > Subject: [IRCServices Coding] Feature Request > > > > > > > > > here is another one... I know unreal has Proxy checking, but it > > > dosent work half the time due to Operating system conflicts. Some > > > shells it works with > > > some it dosent. Can this be intergrated in to services? > > > > I would say: It can, but wont as it has nothig to do with > services at > > all > > > > There are enought third Party tools which provide this feature > > > > Greets > > Ekim Engin > > > > +------------------------+------------------------+ > > | Talesin aka Ekim Engin | ircadmin@ttnet.net.tr | > > | IRC Administration | http://www.ttchat.net | > > | TTNet Network (Turkey) | irc://irc.ttnet.net.tr | > > |------------------------^------------------------| > > | < Chat begins as it ends - without reason > | > > +-------------------------------------------------+ > > > > > ------------------------------------------------------------------ > > > 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 r-krisztian at softhome.net Wed Apr 24 05:40:33 2002 From: r-krisztian at softhome.net (Romek Krisztián) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] ircservices-5.0a29 - Bug (?) References: <3cc62461.12677@achurch.org> Message-ID: <006301c1eb8d$3d0d9160$0b00000a@rokusnet.hu> > I can't see an obvious cause for this. Can you consistently reproduce >the problem? If so, please send me (privately) your database files. Unfortunately, my database files were a lot changed while the problem was. After this, I know there was an error that nick.db was damaged and I had to overwrite my backup dbs... and I had some .lock file existing problems. Thx for helping me, I think it was another problem than services.... AngryWolf ----- Original Message ----- From: Andrew Church To: Sent: Wednesday, April 24, 2002 5:16 AM Subject: Re: [IRCServices Coding] ircservices-5.0a29 - Bug (?) > >*** Global -- from services.freechat.ods.org: PANIC! buffer = :Asmodeus > >PRIVMSG nickserv@services.freechat.ods.org :info PCWC > >*** LocOps -- Received SQUIT services.freechat.ods.org from > >services.freechat.ods.org[127.0.0.1] (Services terminating: Segmentation > >fault) > > I can't see an obvious cause for this. Can you consistently reproduce > the problem? If so, please send me (privately) your database files. > > --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 r-krisztian at softhome.net Wed Apr 24 05:49:35 2002 From: r-krisztian at softhome.net (=?ISO-8859-1?Q?Romek_Kriszti=E1n?=) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request References: <003e01c1eb7b$05d56360$02c8a8c0@nygmatech.local> Message-ID: <007101c1eb8e$80149340$0b00000a@rokusnet.hu> Hello! >Since proxy checking is really not a job for services, I absolutely agree. Do you like ICQ? A lot of people hates that ICQ has too much features. I use it only to send some messages.. not more. This was an example, sorry for advertising. >you can install BOPM, available at >http://www.blitzed.org/bopm/ It's a good program but the big problem is that I use Unreal and the latest patch is only for beta6... AngryWolf From Georges at Berscheid.lu Wed Apr 24 07:13:28 2002 From: Georges at Berscheid.lu (Georges Berscheid) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request References: <003e01c1eb7b$05d56360$02c8a8c0@nygmatech.local> <007101c1eb8e$80149340$0b00000a@rokusnet.hu> Message-ID: <3CC6BD88.9EB521CF@Berscheid.lu> Romek Kriszti?n wrote: > Hello! > > >Since proxy checking is really not a job for services, > > I absolutely agree. Do you like ICQ? A lot of people hates that ICQ has too > much features. I use it only to send some messages.. not more. This was an > example, sorry for advertising. > > >you can install BOPM, available at > >http://www.blitzed.org/bopm/ > > It's a good program but the big problem is that I use Unreal and the latest > patch is only for beta6... The patch only changes one line. It might work for later versions as well. If not, do it manually :) Georges > > > AngryWolf > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From squall157 at Hotmail.com Wed Apr 24 07:25:00 2002 From: squall157 at Hotmail.com (Tom Moyer) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request References: <003e01c1eb7b$05d56360$02c8a8c0@nygmatech.local> <007101c1eb8e$80149340$0b00000a@rokusnet.hu> <3CC6BD88.9EB521CF@Berscheid.lu> Message-ID: hmmm well IMHO proxy checking should be a function of services. here is my delima. i have 2 servers. on my hub proxy checking works. on the leaf server it dosent. So no matter how much i try to keep proxies off. They just dont stay off. IE i have a round robin dns irc.darklitany.com... So its a 50 50 chance they will get on the server that has proxy checking. ----- Original Message ----- From: "Georges Berscheid" To: Sent: Wednesday, April 24, 2002 7:13 AM Subject: Re: [IRCServices Coding] Feature Request > Romek Kriszti?n wrote: > > > Hello! > > > > >Since proxy checking is really not a job for services, > > > > I absolutely agree. Do you like ICQ? A lot of people hates that ICQ has too > > much features. I use it only to send some messages.. not more. This was an > > example, sorry for advertising. > > > > >you can install BOPM, available at > > >http://www.blitzed.org/bopm/ > > > > It's a good program but the big problem is that I use Unreal and the latest > > patch is only for beta6... > > The patch only changes one line. It might work for later versions as well. If > not, do it manually :) > > Georges > > > > > > > AngryWolf > > > > ------------------------------------------------------------------ > > 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 uhc0 at rz.uni-karlsruhe.de Wed Apr 24 07:45:11 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:22 2004 Subject: AW: [IRCServices Coding] Feature Request - End of thread. In-Reply-To: Message-ID: <000801c1eb9e$b4af9310$02c8a8c0@nygmatech.local> Please do stop this thread. It is of no use. It only raises the amount of emails to download and nothing more. Services will not do proxy checking. Services is a set of IRC Services and not connection monitor. There are other software which are designed for that purpose. Do use them. Use bots. Use mIRCScript with SOCKEVENTs. Use your illusion. It is completely unimportant that you suffer from a dilemma, or the admin of your secondary server is unable to run BOPM. That problem is network specific, and it is not a task services should handle either. Why and how about a proxy checker are also off topic discussions about services. Please try to keep egocentrism out of this mailing list. End of thread. 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 Tom Moyer > Gesendet: Mittwoch, 24. April 2002 16:25 > An: ircservices-coding@ircservices.za.net > Betreff: Re: [IRCServices Coding] Feature Request > > > hmmm > well IMHO proxy checking should be a function of services. > here is my delima. i have 2 servers. on my hub proxy > checking works. on the leaf server it dosent. So no matter > how much i try to keep proxies off. They just dont stay off. > IE i have a round robin dns irc.darklitany.com... So its a > 50 50 chance they will get on the server that has proxy checking. From r-krisztian at softhome.net Wed Apr 24 11:25:39 2002 From: r-krisztian at softhome.net (=?iso-8859-1?Q?Romek_Kriszti=E1n?=) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request - End of thread. References: <000801c1eb9e$b4af9310$02c8a8c0@nygmatech.local> Message-ID: <001101c1ebbd$708e3a00$0b00000a@rokusnet.hu> LOL >Please do stop this thread. It is of no use. It only raises >the amount of emails to download and nothing more. I prefer reading some mail from this mailing list instead of nothing. Also if you have a lot of mails and don't have time to read and reply to all. >Services will not do proxy checking. Services is a set of IRC Services and not connection monitor. Agree > There are other software which are designed for that purpose. Do use them. Use bots. Use mIRCScript with SOCKEVENTs. Use your illusion. Other softwares are OK, but bots?! mIRCScript, LOL.... mIRC for linux in bot mode :)))) >It is completely unimportant that you suffer from a dilemma, >or the admin of your secondary server is unable to run BOPM. If I have a problem, it's unimportant? For you is okey but me :)))))) >That problem is network specific, and it is not a task services should handle either. Agree. >Why and how about a proxy checker are also off topic discussions about services. Are you a moderator? What's then if something is off topic? Somebody can start the topic again if you doesn't deny it. >Please try to keep egocentrism out of this mailing list. Yes, Sir! >End of thread. LOL Sorry but I didn't like your speak. AngryWolf From squall157 at Hotmail.com Wed Apr 24 13:52:26 2002 From: squall157 at Hotmail.com (Tom Moyer) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Feature Request - End of thread. References: <000801c1eb9e$b4af9310$02c8a8c0@nygmatech.local> <001101c1ebbd$708e3a00$0b00000a@rokusnet.hu> Message-ID: LMAO... ok ill drop it. But ill also add one last thing. As an admin WHY should i have to have 30 things to accomplish something if one thing can do it. WHy should i have to connect 3 servers for 1 server of chat to occur. i mean hey 1 server for services 1 server for Proxy checking/other stuff yall are telling me you dont want to add and 1 server for the daemon. Simply put if i can get the functionality in 1 product why not go for it. IRC Services is AWESOME, andy you have a great set of services and i am sure the next few versions will be just as great. We all know you have a set path for it, and you dont really want to veer off that path and i respect that =) im just trying to make suggestions along the way, that imho you set this Discussion forum up for. Suggestions on what Real Admins want. i have 2 Network admins, and myself. We all want proxy checking one of my admins loves the idea of botserv where i dont like it. The other one loves the idea of having the online thing where users can check their memos, IE a more user friendly way of doing things for java users. I make the suggestions to yall because its what is wanted. Now its up to andy what he wishes to do with them, Yes i know its good to have feedback, but there is an extent, I mean im new here just trying to help out and get a feature i have wanted for a long time so i make a suggestion and get reemed here... I gotta say yall are kinda blind to what some ppl want. Just because 5 people dont wish to have a feature in services dosent mean 500 other admins arnt looking for services that has this feature. I dont believe i can support another process on my shell, so if someone would like to help me code a module i would be verry happy =) Now ill end it where i found it i wont mention proxy checking agian, unless someone else responds to this thread and yells about it agian... Shesh.. Thanks ----- Original Message ----- From: "Romek Kriszti?n" To: Sent: Wednesday, April 24, 2002 11:25 AM Subject: Re: [IRCServices Coding] Feature Request - End of thread. > LOL > > > >Please do stop this thread. It is of no use. It only raises > >the amount of emails to download and nothing more. > > I prefer reading some mail from this mailing list instead of nothing. Also > if you have a lot of mails and don't have time to read and reply to all. > > >Services will not do proxy checking. Services is a set of IRC Services and > not connection monitor. > > Agree > > > There are other software which are designed for that purpose. Do use them. > Use bots. Use mIRCScript with SOCKEVENTs. Use your illusion. > > Other softwares are OK, but bots?! mIRCScript, LOL.... mIRC for linux in bot > mode :)))) > > >It is completely unimportant that you suffer from a dilemma, > >or the admin of your secondary server is unable to run BOPM. > > If I have a problem, it's unimportant? For you is okey but me :)))))) > > >That problem is network specific, and it is not a task services should > handle either. > > Agree. > > >Why and how about a proxy checker are also off topic discussions about > services. > > Are you a moderator? What's then if something is off topic? Somebody can > start the topic again if you doesn't deny it. > > >Please try to keep egocentrism out of this mailing list. > > Yes, Sir! > > >End of thread. > > LOL > > Sorry but I didn't like your speak. > > AngryWolf > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From Georges at Berscheid.lu Wed Apr 24 14:06:56 2002 From: Georges at Berscheid.lu (Georges Berscheid) Date: Sat Oct 23 23:09:22 2004 Subject: AW: [IRCServices Coding] Feature Request - End of thread. In-Reply-To: Message-ID: Argh, Services 5 have module support. Those who think they need a proxy checker in services can code one, those who don't need it, just leave it out. That's what open source is for. End of thread ? Georges -----Urspr?ngliche Nachricht----- Von: ircservices-coding-admin@ircservices.za.net [mailto:ircservices-coding-admin@ircservices.za.net]Im Auftrag von Tom Moyer Gesendet: Mittwoch, 24. April 2002 22:52 An: ircservices-coding@ircservices.za.net Betreff: Re: [IRCServices Coding] Feature Request - End of thread. LMAO... ok ill drop it. But ill also add one last thing. As an admin WHY should i have to have 30 things to accomplish something if one thing can do it. WHy should i have to connect 3 servers for 1 server of chat to occur. i mean hey 1 server for services 1 server for Proxy checking/other stuff yall are telling me you dont want to add and 1 server for the daemon. Simply put if i can get the functionality in 1 product why not go for it. IRC Services is AWESOME, andy you have a great set of services and i am sure the next few versions will be just as great. We all know you have a set path for it, and you dont really want to veer off that path and i respect that =) im just trying to make suggestions along the way, that imho you set this Discussion forum up for. Suggestions on what Real Admins want. i have 2 Network admins, and myself. We all want proxy checking one of my admins loves the idea of botserv where i dont like it. The other one loves the idea of having the online thing where users can check their memos, IE a more user friendly way of doing things for java users. I make the suggestions to yall because its what is wanted. Now its up to andy what he wishes to do with them, Yes i know its good to have feedback, but there is an extent, I mean im new here just trying to help out and get a feature i have wanted for a long time so i make a suggestion and get reemed here... I gotta say yall are kinda blind to what some ppl want. Just because 5 people dont wish to have a feature in services dosent mean 500 other admins arnt looking for services that has this feature. I dont believe i can support another process on my shell, so if someone would like to help me code a module i would be verry happy =) Now ill end it where i found it i wont mention proxy checking agian, unless someone else responds to this thread and yells about it agian... Shesh.. Thanks ----- Original Message ----- From: "Romek Kriszti?n" To: Sent: Wednesday, April 24, 2002 11:25 AM Subject: Re: [IRCServices Coding] Feature Request - End of thread. > LOL > > > >Please do stop this thread. It is of no use. It only raises > >the amount of emails to download and nothing more. > > I prefer reading some mail from this mailing list instead of nothing. Also > if you have a lot of mails and don't have time to read and reply to all. > > >Services will not do proxy checking. Services is a set of IRC Services and > not connection monitor. > > Agree > > > There are other software which are designed for that purpose. Do use them. > Use bots. Use mIRCScript with SOCKEVENTs. Use your illusion. > > Other softwares are OK, but bots?! mIRCScript, LOL.... mIRC for linux in bot > mode :)))) > > >It is completely unimportant that you suffer from a dilemma, > >or the admin of your secondary server is unable to run BOPM. > > If I have a problem, it's unimportant? For you is okey but me :)))))) > > >That problem is network specific, and it is not a task services should > handle either. > > Agree. > > >Why and how about a proxy checker are also off topic discussions about > services. > > Are you a moderator? What's then if something is off topic? Somebody can > start the topic again if you doesn't deny it. > > >Please try to keep egocentrism out of this mailing list. > > Yes, Sir! > > >End of thread. > > LOL > > Sorry but I didn't like your speak. > > AngryWolf > > ------------------------------------------------------------------ > 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 Thu Apr 25 09:07:07 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:22 2004 Subject: END OF THREAD (was Re: [IRCServices Coding] Feature Request - End of thread.) Message-ID: <3cc74906.27374@achurch.org> Drop this thread now. I will have anyone who responds removed from this mailing list. --Andrew Church achurch@achurch.org http://achurch.org/ >LMAO... ok ill drop it. But ill also add one last thing. > >As an admin WHY should i have to have 30 things to accomplish something if >one thing can do it. >WHy should i have to connect 3 servers for 1 server of chat to occur. i >mean hey 1 server for services 1 server for Proxy checking/other stuff yall >are telling me you dont want to add and 1 server for the daemon. Simply put >if i can get the functionality in 1 product why not go for it. IRC Services >is AWESOME, andy you have a great set of services and i am sure the next few >versions will be just as great. We all know you have a set path for it, and >you dont really want to veer off that path and i respect that =) im just >trying to make suggestions along the way, that imho you set this Discussion >forum up for. Suggestions on what Real Admins want. i have 2 Network >admins, and myself. We all want proxy checking one of my admins loves the >idea of botserv where i dont like it. The other one loves the idea of having >the online thing where users can check their memos, IE a more user friendly >way of doing things for java users. I make the suggestions to yall because >its what is wanted. Now its up to andy what he wishes to do with them, Yes i >know its good to have feedback, but there is an extent, I mean im new here >just trying to help out and get a feature i have wanted for a long time so i >make a suggestion and get reemed here... I gotta say yall are kinda blind to >what some ppl want. Just because 5 people dont wish to have a feature in >services dosent mean 500 other admins arnt looking for services that has >this feature. >I dont believe i can support another process on my shell, so if someone >would like to help me code a module i would be verry happy =) > >Now ill end it where i found it i wont mention proxy checking agian, unless >someone else responds to this thread and yells about it agian... Shesh.. > > >Thanks > >----- Original Message ----- >From: "Romek Kriszti?n" >To: >Sent: Wednesday, April 24, 2002 11:25 AM >Subject: Re: [IRCServices Coding] Feature Request - End of thread. > > >> LOL >> >> >> >Please do stop this thread. It is of no use. It only raises >> >the amount of emails to download and nothing more. >> >> I prefer reading some mail from this mailing list instead of nothing. Also >> if you have a lot of mails and don't have time to read and reply to all. >> >> >Services will not do proxy checking. Services is a set of IRC Services >and >> not connection monitor. >> >> Agree >> >> > There are other software which are designed for that purpose. Do use >them. >> Use bots. Use mIRCScript with SOCKEVENTs. Use your illusion. >> >> Other softwares are OK, but bots?! mIRCScript, LOL.... mIRC for linux in >bot >> mode :)))) >> >> >It is completely unimportant that you suffer from a dilemma, >> >or the admin of your secondary server is unable to run BOPM. >> >> If I have a problem, it's unimportant? For you is okey but me :)))))) >> >> >That problem is network specific, and it is not a task services should >> handle either. >> >> Agree. >> >> >Why and how about a proxy checker are also off topic discussions about >> services. >> >> Are you a moderator? What's then if something is off topic? Somebody can >> start the topic again if you doesn't deny it. >> >> >Please try to keep egocentrism out of this mailing list. >> >> Yes, Sir! >> >> >End of thread. >> >> LOL >> >> Sorry but I didn't like your speak. >> >> AngryWolf >> >> ------------------------------------------------------------------ >> 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 nothing at psychopat.org Thu Apr 25 16:33:03 2002 From: nothing at psychopat.org (Marc-Andre A. Fuentes) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] MySQL In-Reply-To: <200204141522.01473.v13@it.teithe.gr> Message-ID: I just want to know when MySQL-module will be ready? :) From achurch at achurch.org Fri Apr 26 11:57:34 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] MySQL Message-ID: <3cc8c228.30771@achurch.org> >I just want to know when MySQL-module will be ready? :) Not for a while; certainly not for version 5.0. --Andrew Church achurch@achurch.org http://achurch.org/ From rg at tcslon.com Fri Apr 26 09:30:55 2002 From: rg at tcslon.com (Russ Garrett) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] MySQL References: <3cc8c228.30771@achurch.org> Message-ID: <3CC980BF.4000307@tcslon.com> Andrew Church wrote: >>I just want to know when MySQL-module will be ready? :) >> >> > > Not for a while; certainly not for version 5.0. > > If you're lucky I may have a go at coding a module after my exams (in a month or two). Don't hold your breath ;). Russ Garrett (russ@garrett.co.uk) http://www.faereal.net From achurch at achurch.org Sat Apr 27 00:39:38 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] MySQL Message-ID: <3cc975d3.33321@achurch.org> >>>I just want to know when MySQL-module will be ready? :) >> >> Not for a while; certainly not for version 5.0. >> >If you're lucky I may have a go at coding a module after my exams (in a >month or two). Don't hold your breath ;). Just so you know, this has nothing (well, some, but not directly) to do with me not having enough time, and is primarily because I didn't get around to redesigning the database stuff the way it should be to use SQL properly; to be honest, the database code is still very tied to the current (meaning 4.x) database format. I'm hoping to remedy that in 5.1 or a later version, but if I try to do it now, 5.0 will never get finished, so I put it aside for now. --Andrew Church achurch@achurch.org http://achurch.org/ From gizm0 at mail.gr Fri Apr 26 20:01:49 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Thinking this is a bug Message-ID: <101984050901@mailserver.mail.gr> Try setting mlock +mnpstrOM on a channel.Leave it empty and then join it again.The services will set +mnpstrOM BUT the +p(private) won't appear if you list the modes of the channel although the services HAD set it.This doesn't happen when a channel is set mlock without the +O mode.If you set mode +p on the channel,part and join it again,it doesn't work either.This happens in two of my Operators Only channels #admins and #services.If i join #darkness the +p mode works perfectly as the #darkness doesn't have +O mode.I believe the reason causing this to occur, is the +O mode. Regards, Gizm0 ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From rg at tcslon.com Fri Apr 26 11:40:22 2002 From: rg at tcslon.com (Russ Garrett) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Thinking this is a bug References: <101984050901@mailserver.mail.gr> Message-ID: <3CC99F16.5010408@tcslon.com> Panagiotis Kefalidis ( Gizm0 ) wrote: >Try setting mlock +mnpstrOM on a channel.Leave it empty and then join it >again.The services will set +mnpstrOM BUT the +p(private) won't appear if >you list the modes of the channel although the services HAD set it.This >doesn't happen when a channel is set mlock without the +O mode.If you set >mode +p on the channel,part and join it again,it doesn't work either.This >happens in two of my Operators Only channels #admins and #services.If i >join #darkness the +p mode works perfectly as the #darkness doesn't have >+O mode.I believe the reason causing this to occur, is the +O mode. > > Hi :) Are you sure it's not the +s mode causing the problem, as +p and +s are mutually exclusive - you can't have a channel with +ps set, the ircd will always get rid of the +p. God knows why +s includes the functions of +p.... +p = doesn't show to non-opers +s = +p AND doesn't show in users' whois - overrides +p Russ Garrett (russ@garrett.co.uk) http://www.faereal.net From uhc0 at rz.uni-karlsruhe.de Fri Apr 26 10:48:21 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:22 2004 Subject: AW: [IRCServices Coding] Thinking this is a bug In-Reply-To: <3CC99F16.5010408@tcslon.com> Message-ID: <001501c1ed4a$a0378340$02c8a8c0@nygmatech.local> With bahamut, a channel can be set +ps. That bahamut includes problems with +O is a case bahamut coders have to solve. http://bahamut.dal.net, join the dalnet-src@ mailing list, and point them out to the bug. PS: I gave up talking to DALnet coders, because they NEVER EVER reply. 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 Russ Garrett > Gesendet: Freitag, 26. April 2002 20:40 > An: ircservices-coding@ircservices.za.net > Betreff: Re: [IRCServices Coding] Thinking this is a bug > > > Panagiotis Kefalidis ( Gizm0 ) wrote: > > >Try setting mlock +mnpstrOM on a channel.Leave it empty and > then join > >it again.The services will set +mnpstrOM BUT the +p(private) won't > >appear if you list the modes of the channel although the > services HAD > >set it.This doesn't happen when a channel is set mlock > without the +O > >mode.If you set mode +p on the channel,part and join it again,it > >doesn't work either.This happens in two of my Operators Only > channels > >#admins and #services.If i join #darkness the +p mode works > perfectly > >as the #darkness doesn't have > >+O mode.I believe the reason causing this to occur, is the +O mode. > > > > > Hi :) > > Are you sure it's not the +s mode causing the problem, as +p > and +s are > mutually exclusive - you can't have a channel with +ps set, the ircd > will always get rid of the +p. God knows why +s includes the > functions > of +p.... > > +p = doesn't show to non-opers > +s = +p AND doesn't show in users' whois - overrides +p > > > Russ Garrett (russ@garrett.co.uk) > http://www.faereal.net > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo> /ircservices-coding > From gizm0 at mail.gr Fri Apr 26 20:39:11 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:22 2004 Subject: AW: [IRCServices Coding] Thinking this is a bug Message-ID: <101984275101@mailserver.mail.gr> Óôßò Fri, 26 Apr 2002 19:48:21 +0200 "Yusuf Iskenderoglu" Ýãñáøå: > > With bahamut, a channel can be set +ps. > That bahamut includes problems with +O is a case bahamut coders > have to solve. http://bahamut.dal.net, join the dalnet-src@ mailing > list, and point them out to the bug. I'm already but i have to see an e-mail for the last 3 weeks. > > PS: I gave up talking to DALnet coders, because they NEVER EVER > reply. heh :)I won't mail them either.The version of bahamut i'm using is patched for this by our coders.This is caused i suppose by the services(not sure). > > Regards; > yusuf Russ, Yes i'm sure that +O is causing this and not the +s,because the #darkness is also +s as the #admins.But,the #admins has +O mode, #darkness hasn't.That's all.:) "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From rg at tcslon.com Fri Apr 26 12:17:46 2002 From: rg at tcslon.com (Russ Garrett) Date: Sat Oct 23 23:09:22 2004 Subject: AW: [IRCServices Coding] Thinking this is a bug References: <101984275101@mailserver.mail.gr> Message-ID: <3CC9A7DA.1050502@tcslon.com> > > >Russ, >Yes i'm sure that +O is causing this and not the +s,because the #darkness >is also +s as the #admins.But,the #admins has +O mode, #darkness >hasn't.That's all.:) > > Yeh didn't read the message properly... Friday night and all that :P Russ Garrett (russ@garrett.co.uk) http://www.faereal.net From achurch at achurch.org Wed May 1 03:37:17 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Services 5.0 alpha 30 released Message-ID: <3ccee602.77134@achurch.org> Well, I managed to make some progress, if not quite as much as I had hoped; still, my local bug list is down to about 10 items now, some of which are documentation and related stuff that can be done later, so with any luck a beta should see the light of day soon. (Knock on wood...) Changes in version 5.0 alpha 30 ------------------------------- 2002/05/01 Renamed nick-authorization checking macros (nickserv.h, nick_* -> user_*). 2002/05/01 Unified %d/%u/%ld/%lu usage in *printf() calls. 2002/04/30 Fixed spurious WALLOPS messages when server socket is closed. 2002/04/30 Merged common code for akills/etc in httpd/dbaccess module. 2002/04/30 Fixed incorrect nick-kill warning messages with forced nick changing. Reported by Panagiotis Kefalidis 2002/04/24 Fixed failure to set user mode +a for Services admins on Bahamut and trircd. Reported by Panagiotis Kefalidis 2002/04/24 Added back missing NetworkDomain directive to modules.conf. Reported by Yusuf Iskenderoglu 2002/04/24 Removed EsperNet protocol module as development on that server has stopped. 2002/04/24 Fixed bug causing crashes on NickServ SET with no parameters. Reported by Panagiotis Kefalidis --Andrew Church achurch@achurch.org http://achurch.org/ From frostycoolslug at hotmail.com Thu May 2 07:51:21 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Error during make Message-ID: ./confiure works fine.. comes to make thou.. --- [ SNIP ] --- make[1]: Entering directory `/home/devon/chatspike/ircservices-5.0a30/modules' make[2]: Entering directory `/home/devon/chatspike/ircservices-5.0a30/modules/chanserv' make[2]: *** No rule to make target `main.so', needed by `all-dynamic'. Stop. make[2]: Leaving directory `/home/devon/chatspike/ircservices-5.0a30/modules/chanserv' make[1]: *** [all-dynamic] Error 2 make[1]: Leaving directory `/home/devon/chatspike/ircservices-5.0a30/modules' make: *** [modules] Error 2 --- [ SNIP ] --- Ne help appreciated :) cheers -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From squall157 at Hotmail.com Thu May 2 09:55:05 2002 From: squall157 at Hotmail.com (Tom Moyer) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Error during make References: Message-ID: this is off the wall but try gmake instead... ----- Original Message ----- From: "Craig McLure" To: Sent: Thursday, May 02, 2002 7:51 AM Subject: [IRCServices Coding] Error during make > ./confiure works fine.. > comes to make thou.. > > --- [ SNIP ] --- > make[1]: Entering directory > `/home/devon/chatspike/ircservices-5.0a30/modules' > make[2]: Entering directory > `/home/devon/chatspike/ircservices-5.0a30/modules/chanserv' > make[2]: *** No rule to make target `main.so', needed by `all-dynamic'. > Stop. > make[2]: Leaving directory > `/home/devon/chatspike/ircservices-5.0a30/modules/chanserv' > make[1]: *** [all-dynamic] Error 2 > make[1]: Leaving directory > `/home/devon/chatspike/ircservices-5.0a30/modules' > make: *** [modules] Error 2 > --- [ SNIP ] --- > > Ne help appreciated :) > cheers > > > > -- > Craig McLure > Craig@chatspike.net > Network Administrator of the ChatSpike IRC Network. > ChatSpike, the users network! www.chatspike.net > > > _________________________________________________________________ > 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 gizm0 at mail.gr Thu May 2 18:04:19 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Error during make Message-ID: <102035185901@mailserver.mail.gr> My a30 compile worked fine.Probably an problem with your C(gcc probably)compiler or an old version of gcc. Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From rg at tcslon.com Thu May 2 09:59:11 2002 From: rg at tcslon.com (Russ Garrett) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Error during make References: <102035185901@mailserver.mail.gr> Message-ID: <3CD1705F.4020908@tcslon.com> Panagiotis Kefalidis ( Gizm0 ) wrote: >My a30 compile worked fine.Probably an problem with your C(gcc >probably)compiler or an old version of gcc. > > > My money's on the fact it's the infamous BSD Make problem - the 'make' command in BSD doesn't support many GNU AutoMake scripts, so you have to use gnu make ('gmake') in BSD (conspiracy? probably ;) Russ Garrett (russ@garrett.co.uk) From achurch at achurch.org Fri May 3 01:09:01 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Error during make Message-ID: <3cd164e9.34303@achurch.org> >Panagiotis Kefalidis ( Gizm0 ) wrote: > >>My a30 compile worked fine.Probably an problem with your C(gcc >>probably)compiler or an old version of gcc. >> >> >> >My money's on the fact it's the infamous BSD Make problem - the 'make' >command in BSD doesn't support many GNU AutoMake scripts, so you have to >use gnu make ('gmake') in BSD (conspiracy? probably ;) Just for the record, I don't use automake (way too messy), but I do take advantage of GNU make features which don't work in BSD make. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Fri May 3 01:10:32 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Services 5.0 alpha 31 released Message-ID: <3cd16582.34316@achurch.org> Getting closer, getting closer... hopefully I should be able to get a beta out after a couple more alpha cycles. But don't let that stop you from reporting bugs! Incidentally, I'll be out of town from tomorrow through next Tuesday, so replies will be delayed until I get back. Changes in version 5.0 alpha 31 ------------------------------- 2002/05/03 Channel user modes are now rechecked when a user identifies for their nickname. 2002/05/02 Added appropriate error messages for temporary sendmail() failures. 2002/05/02 Fixed minor bug causing ChanServ to try to enter the same channel twice on autokicks. 2002/05/01 Fixed a race condition allowing the first user on a channel to give themselves +v before Services deopped them. 2002/05/01 Added httpd/top-page module. 2002/05/01 Added Chunky Monkey IRCD protocol module (protocol/monkey), courtesy of Chris Plant 2002/05/01 Channel mode changes are now sent by the server rather than ChanServ for Bahamut, to avoid a problem with setting +r. --Andrew Church achurch@achurch.org http://achurch.org/ From frostycoolslug at hotmail.com Thu May 2 10:39:25 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Error during make Message-ID: i tried gmake.. no difference :/ >From: "Tom Moyer" >Reply-To: ircservices-coding@ircservices.za.net >To: >Subject: Re: [IRCServices Coding] Error during make >Date: Thu, 2 May 2002 09:55:05 -0700 >MIME-Version: 1.0 >X-Originating-IP: [67.203.71.74] >Received: from [196.7.148.5] by hotmail.com (3.2) with ESMTP id >MHotMailBE9A9EC90018400431DFC4079405DD870; Thu, 02 May 2002 07:57:32 -0700 >Received: from snow.fingers.co.za (localhost.fingers.co.za [127.0.0.1])by >snow.fingers.co.za (Postfix) with ESMTPid 3EC011742A; Thu, 2 May 2002 >16:57:07 +0200 (SAST) >Received: from hotmail.com (oe23.law3.hotmail.com [209.185.240.16])by >snow.fingers.co.za (Postfix) with ESMTP id 312E617420for >; Thu, 2 May 2002 16:56:38 +0200 >(SAST) >Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; >Thu, 2 May 2002 07:56:33 -0700 >From ircservices-coding-admin@ircservices.za.net Thu, 02 May 2002 07:57:57 >-0700 >Delivered-To: ircservices-coding@snow.fingers.co.za >References: >X-Priority: 3 >X-MSMail-Priority: Normal >X-Mailer: Microsoft Outlook Express 6.00.2600.0000 >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 >Message-ID: >X-OriginalArrivalTime: 02 May 2002 14:56:33.0554 (UTC) >FILETIME=[8CD52F20:01C1F1E9] >Sender: ircservices-coding-admin@ircservices.za.net >Errors-To: ircservices-coding-admin@ircservices.za.net >X-BeenThere: ircservices-coding@ircservices.za.net >X-Mailman-Version: 2.0.8 >Precedence: bulk >List-Help: > >List-Post: >List-Subscribe: >, >List-Id: IRC Services Coding Mailing List > >List-Unsubscribe: >, >List-Archive: > >this is off the wall but try gmake instead... >----- Original Message ----- >From: "Craig McLure" >To: >Sent: Thursday, May 02, 2002 7:51 AM >Subject: [IRCServices Coding] Error during make > > > > ./confiure works fine.. > > comes to make thou.. > > > > --- [ SNIP ] --- > > make[1]: Entering directory > > `/home/devon/chatspike/ircservices-5.0a30/modules' > > make[2]: Entering directory > > `/home/devon/chatspike/ircservices-5.0a30/modules/chanserv' > > make[2]: *** No rule to make target `main.so', needed by `all-dynamic'. > > Stop. > > make[2]: Leaving directory > > `/home/devon/chatspike/ircservices-5.0a30/modules/chanserv' > > make[1]: *** [all-dynamic] Error 2 > > make[1]: Leaving directory > > `/home/devon/chatspike/ircservices-5.0a30/modules' > > make: *** [modules] Error 2 > > --- [ SNIP ] --- > > > > Ne help appreciated :) > > cheers > > > > > > > > -- > > Craig McLure > > Craig@chatspike.net > > Network Administrator of the ChatSpike IRC Network. > > ChatSpike, the users network! www.chatspike.net > > > > > > _________________________________________________________________ > > 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@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From achurch at achurch.org Fri May 3 03:25:08 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:22 2004 Subject: [IRCServices Coding] Error during make Message-ID: <3cd1848e.35676@achurch.org> >i tried gmake.. no difference :/ Is your gmake up to date? (v3.79.1) > >>From: "Tom Moyer" >>Reply-To: ircservices-coding@ircservices.za.net >>To: >>Subject: Re: [IRCServices Coding] Error during make >>Date: Thu, 2 May 2002 09:55:05 -0700 >>MIME-Version: 1.0 >>X-Originating-IP: [67.203.71.74] >>Received: from [196.7.148.5] by hotmail.com (3.2) with ESMTP id >>MHotMailBE9A9EC90018400431DFC4079405DD870; Thu, 02 May 2002 07:57:32 -0700 >>Received: from snow.fingers.co.za (localhost.fingers.co.za [127.0.0.1])by >>snow.fingers.co.za (Postfix) with ESMTPid 3EC011742A; Thu, 2 May 2002 >>16:57:07 +0200 (SAST) >>Received: from hotmail.com (oe23.law3.hotmail.com [209.185.240.16])by >>snow.fingers.co.za (Postfix) with ESMTP id 312E617420for >>; Thu, 2 May 2002 16:56:38 +0200 >>(SAST) >>Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; >>Thu, 2 May 2002 07:56:33 -0700 >>From ircservices-coding-admin@ircservices.za.net Thu, 02 May 2002 07:57:57 >>-0700 >>Delivered-To: ircservices-coding@snow.fingers.co.za >>References: >>X-Priority: 3 >>X-MSMail-Priority: Normal >>X-Mailer: Microsoft Outlook Express 6.00.2600.0000 >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 >>Message-ID: >>X-OriginalArrivalTime: 02 May 2002 14:56:33.0554 (UTC) >>FILETIME=[8CD52F20:01C1F1E9] >>Sender: ircservices-coding-admin@ircservices.za.net >>Errors-To: ircservices-coding-admin@ircservices.za.net >>X-BeenThere: ircservices-coding@ircservices.za.net >>X-Mailman-Version: 2.0.8 >>Precedence: bulk >>List-Help: >> >>List-Post: >>List-Subscribe: >>, >>List-Id: IRC Services Coding Mailing List >> >>List-Unsubscribe: >>, >>List-Archive: >> >>this is off the wall but try gmake instead... >>----- Original Message ----- >>From: "Craig McLure" >>To: >>Sent: Thursday, May 02, 2002 7:51 AM >>Subject: [IRCServices Coding] Error during make >> >> >> > ./confiure works fine.. >> > comes to make thou.. >> > >> > --- [ SNIP ] --- >> > make[1]: Entering directory >> > `/home/devon/chatspike/ircservices-5.0a30/modules' >> > make[2]: Entering directory >> > `/home/devon/chatspike/ircservices-5.0a30/modules/chanserv' >> > make[2]: *** No rule to make target `main.so', needed by `all-dynamic'. >> > Stop. >> > make[2]: Leaving directory >> > `/home/devon/chatspike/ircservices-5.0a30/modules/chanserv' >> > make[1]: *** [all-dynamic] Error 2 >> > make[1]: Leaving directory >> > `/home/devon/chatspike/ircservices-5.0a30/modules' >> > make: *** [modules] Error 2 >> > --- [ SNIP ] --- >> > >> > Ne help appreciated :) >> > cheers >> > >> > >> > >> > -- >> > Craig McLure >> > Craig@chatspike.net >> > Network Administrator of the ChatSpike IRC Network. >> > ChatSpike, the users network! www.chatspike.net >> > >> > >> > _________________________________________________________________ >> > 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@chatspike.net >Network Administrator of the ChatSpike IRC Network. >ChatSpike, the users network! www.chatspike.net > > >_________________________________________________________________ >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 --Andrew Church achurch@achurch.org http://achurch.org/ From frostycoolslug at hotmail.com Thu May 2 11:42:06 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Error during make Message-ID: its 3.78.1 will mail shell provider :) cheers :) >From: achurch@achurch.org (Andrew Church) >Reply-To: ircservices-coding@ircservices.za.net >To: ircservices-coding@ircservices.za.net >Subject: Re: [IRCServices Coding] Error during make >Date: Fri, 03 May 2002 03:25:08 JST >Received: from [196.7.148.5] by hotmail.com (3.2) with ESMTP id >MHotMailBE9ACFC4000A4004324BC4079405EF4C0; Thu, 02 May 2002 11:26:21 -0700 >Received: from snow.fingers.co.za (localhost.fingers.co.za [127.0.0.1])by >snow.fingers.co.za (Postfix) with ESMTPid 4116F17428; Thu, 2 May 2002 >20:26:07 +0200 (SAST) >Received: from achurch.org (unknown [210.145.195.3])by snow.fingers.co.za >(Postfix) with SMTP id 0BA6F17420for >; Thu, 2 May 2002 20:25:22 +0200 >(SAST) >Received: by achurch.org (wmail 0.9.16) id 3cd1848e.35676; Fri, 03 May 2002 >03:25:18 JST >From ircservices-coding-admin@ircservices.za.net Thu, 02 May 2002 11:27:53 >-0700 >Delivered-To: ircservices-coding@snow.fingers.co.za >X-Mailer: MMail v5.01 >Message-ID: <3cd1848e.35676@achurch.org> >Sender: ircservices-coding-admin@ircservices.za.net >Errors-To: ircservices-coding-admin@ircservices.za.net >X-BeenThere: ircservices-coding@ircservices.za.net >X-Mailman-Version: 2.0.8 >Precedence: bulk >List-Help: > >List-Post: >List-Subscribe: >, >List-Id: IRC Services Coding Mailing List > >List-Unsubscribe: >, >List-Archive: > > >i tried gmake.. no difference :/ > > Is your gmake up to date? (v3.79.1) > > > > >>From: "Tom Moyer" > >>Reply-To: ircservices-coding@ircservices.za.net > >>To: > >>Subject: Re: [IRCServices Coding] Error during make > >>Date: Thu, 2 May 2002 09:55:05 -0700 > >>MIME-Version: 1.0 > >>X-Originating-IP: [67.203.71.74] > >>Received: from [196.7.148.5] by hotmail.com (3.2) with ESMTP id > >>MHotMailBE9A9EC90018400431DFC4079405DD870; Thu, 02 May 2002 07:57:32 >-0700 > >>Received: from snow.fingers.co.za (localhost.fingers.co.za >[127.0.0.1])by > >>snow.fingers.co.za (Postfix) with ESMTPid 3EC011742A; Thu, 2 May 2002 > >>16:57:07 +0200 (SAST) > >>Received: from hotmail.com (oe23.law3.hotmail.com [209.185.240.16])by > >>snow.fingers.co.za (Postfix) with ESMTP id 312E617420for > >>; Thu, 2 May 2002 16:56:38 +0200 > >>(SAST) > >>Received: from mail pickup service by hotmail.com with Microsoft >SMTPSVC; > >>Thu, 2 May 2002 07:56:33 -0700 > >>From ircservices-coding-admin@ircservices.za.net Thu, 02 May 2002 >07:57:57 > >>-0700 > >>Delivered-To: ircservices-coding@snow.fingers.co.za > >>References: > >>X-Priority: 3 > >>X-MSMail-Priority: Normal > >>X-Mailer: Microsoft Outlook Express 6.00.2600.0000 > >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > >>Message-ID: > >>X-OriginalArrivalTime: 02 May 2002 14:56:33.0554 (UTC) > >>FILETIME=[8CD52F20:01C1F1E9] > >>Sender: ircservices-coding-admin@ircservices.za.net > >>Errors-To: ircservices-coding-admin@ircservices.za.net > >>X-BeenThere: ircservices-coding@ircservices.za.net > >>X-Mailman-Version: 2.0.8 > >>Precedence: bulk > >>List-Help: > >> > >>List-Post: > >>List-Subscribe: > >>, > >>List-Id: IRC Services Coding Mailing List > >> > >>List-Unsubscribe: > >>, > >>List-Archive: > > >> > >>this is off the wall but try gmake instead... > >>----- Original Message ----- > >>From: "Craig McLure" > >>To: > >>Sent: Thursday, May 02, 2002 7:51 AM > >>Subject: [IRCServices Coding] Error during make > >> > >> > >> > ./confiure works fine.. > >> > comes to make thou.. > >> > > >> > --- [ SNIP ] --- > >> > make[1]: Entering directory > >> > `/home/devon/chatspike/ircservices-5.0a30/modules' > >> > make[2]: Entering directory > >> > `/home/devon/chatspike/ircservices-5.0a30/modules/chanserv' > >> > make[2]: *** No rule to make target `main.so', needed by >`all-dynamic'. > >> > Stop. > >> > make[2]: Leaving directory > >> > `/home/devon/chatspike/ircservices-5.0a30/modules/chanserv' > >> > make[1]: *** [all-dynamic] Error 2 > >> > make[1]: Leaving directory > >> > `/home/devon/chatspike/ircservices-5.0a30/modules' > >> > make: *** [modules] Error 2 > >> > --- [ SNIP ] --- > >> > > >> > Ne help appreciated :) > >> > cheers > >> > > >> > > >> > > >> > -- > >> > Craig McLure > >> > Craig@chatspike.net > >> > Network Administrator of the ChatSpike IRC Network. > >> > ChatSpike, the users network! www.chatspike.net > >> > > >> > > >> > _________________________________________________________________ > >> > 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@chatspike.net > >Network Administrator of the ChatSpike IRC Network. > >ChatSpike, the users network! www.chatspike.net > > > > > >_________________________________________________________________ > >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 > > --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 -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From rg at tcslon.com Thu May 2 13:07:38 2002 From: rg at tcslon.com (Russ Garrett) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Services 5.0 alpha 31 released References: <3cd16582.34316@achurch.org> Message-ID: <3CD19C8A.9020500@tcslon.com> Andrew Church wrote: >2002/05/03 Channel user modes are now rechecked when a user identifies > for their nickname. > > Excellent :) Now to start the slow process of persuading the netadmin to change to ircservices... you never he might give in by the time it's released ;) Russ Garrett (russ@garrett.co.uk) From achurch at achurch.org Fri May 3 04:16:14 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Error during make Message-ID: <3cd190e6.36424@achurch.org> >its 3.78.1 >will mail shell provider :) Then you'll need to upgrade it (presumably this means installing the new version on your shell). Services won't work with anything earlier than 3.79. I could mention that this is clearly stated in section 2 of the manual. >cheers :) > > >>From: achurch@achurch.org (Andrew Church) >>Reply-To: ircservices-coding@ircservices.za.net >>To: ircservices-coding@ircservices.za.net >>Subject: Re: [IRCServices Coding] Error during make >>Date: Fri, 03 May 2002 03:25:08 JST >>Received: from [196.7.148.5] by hotmail.com (3.2) with ESMTP id >>MHotMailBE9ACFC4000A4004324BC4079405EF4C0; Thu, 02 May 2002 11:26:21 -0700 >>Received: from snow.fingers.co.za (localhost.fingers.co.za [127.0.0.1])by >>snow.fingers.co.za (Postfix) with ESMTPid 4116F17428; Thu, 2 May 2002 >>20:26:07 +0200 (SAST) >>Received: from achurch.org (unknown [210.145.195.3])by snow.fingers.co.za >>(Postfix) with SMTP id 0BA6F17420for >>; Thu, 2 May 2002 20:25:22 +0200 >>(SAST) >>Received: by achurch.org (wmail 0.9.16) id 3cd1848e.35676; Fri, 03 May 2002 >>03:25:18 JST >>From ircservices-coding-admin@ircservices.za.net Thu, 02 May 2002 11:27:53 >>-0700 >>Delivered-To: ircservices-coding@snow.fingers.co.za >>X-Mailer: MMail v5.01 >>Message-ID: <3cd1848e.35676@achurch.org> >>Sender: ircservices-coding-admin@ircservices.za.net >>Errors-To: ircservices-coding-admin@ircservices.za.net >>X-BeenThere: ircservices-coding@ircservices.za.net >>X-Mailman-Version: 2.0.8 >>Precedence: bulk >>List-Help: >> >>List-Post: >>List-Subscribe: >>, >>List-Id: IRC Services Coding Mailing List >> >>List-Unsubscribe: >>, >>List-Archive: >> >> >i tried gmake.. no difference :/ >> >> Is your gmake up to date? (v3.79.1) >> >> > >> >>From: "Tom Moyer" >> >>Reply-To: ircservices-coding@ircservices.za.net >> >>To: >> >>Subject: Re: [IRCServices Coding] Error during make >> >>Date: Thu, 2 May 2002 09:55:05 -0700 >> >>MIME-Version: 1.0 >> >>X-Originating-IP: [67.203.71.74] >> >>Received: from [196.7.148.5] by hotmail.com (3.2) with ESMTP id >> >>MHotMailBE9A9EC90018400431DFC4079405DD870; Thu, 02 May 2002 07:57:32 >>-0700 >> >>Received: from snow.fingers.co.za (localhost.fingers.co.za >>[127.0.0.1])by >> >>snow.fingers.co.za (Postfix) with ESMTPid 3EC011742A; Thu, 2 May 2002 >> >>16:57:07 +0200 (SAST) >> >>Received: from hotmail.com (oe23.law3.hotmail.com [209.185.240.16])by >> >>snow.fingers.co.za (Postfix) with ESMTP id 312E617420for >> >>; Thu, 2 May 2002 16:56:38 +0200 >> >>(SAST) >> >>Received: from mail pickup service by hotmail.com with Microsoft >>SMTPSVC; >> >>Thu, 2 May 2002 07:56:33 -0700 >> >>From ircservices-coding-admin@ircservices.za.net Thu, 02 May 2002 >>07:57:57 >> >>-0700 >> >>Delivered-To: ircservices-coding@snow.fingers.co.za >> >>References: >> >>X-Priority: 3 >> >>X-MSMail-Priority: Normal >> >>X-Mailer: Microsoft Outlook Express 6.00.2600.0000 >> >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 >> >>Message-ID: >> >>X-OriginalArrivalTime: 02 May 2002 14:56:33.0554 (UTC) >> >>FILETIME=[8CD52F20:01C1F1E9] >> >>Sender: ircservices-coding-admin@ircservices.za.net >> >>Errors-To: ircservices-coding-admin@ircservices.za.net >> >>X-BeenThere: ircservices-coding@ircservices.za.net >> >>X-Mailman-Version: 2.0.8 >> >>Precedence: bulk >> >>List-Help: >> >> >> >>List-Post: >> >>List-Subscribe: >> >>, >> >>List-Id: IRC Services Coding Mailing List >> >> >> >>List-Unsubscribe: >> >>, >> >>List-Archive: >> >> >> >> >>this is off the wall but try gmake instead... >> >>----- Original Message ----- >> >>From: "Craig McLure" >> >>To: >> >>Sent: Thursday, May 02, 2002 7:51 AM >> >>Subject: [IRCServices Coding] Error during make >> >> >> >> >> >> > ./confiure works fine.. >> >> > comes to make thou.. >> >> > >> >> > --- [ SNIP ] --- >> >> > make[1]: Entering directory >> >> > `/home/devon/chatspike/ircservices-5.0a30/modules' >> >> > make[2]: Entering directory >> >> > `/home/devon/chatspike/ircservices-5.0a30/modules/chanserv' >> >> > make[2]: *** No rule to make target `main.so', needed by >>`all-dynamic'. >> >> > Stop. >> >> > make[2]: Leaving directory >> >> > `/home/devon/chatspike/ircservices-5.0a30/modules/chanserv' >> >> > make[1]: *** [all-dynamic] Error 2 >> >> > make[1]: Leaving directory >> >> > `/home/devon/chatspike/ircservices-5.0a30/modules' >> >> > make: *** [modules] Error 2 >> >> > --- [ SNIP ] --- >> >> > >> >> > Ne help appreciated :) >> >> > cheers >> >> > >> >> > >> >> > >> >> > -- >> >> > Craig McLure >> >> > Craig@chatspike.net >> >> > Network Administrator of the ChatSpike IRC Network. >> >> > ChatSpike, the users network! www.chatspike.net >> >> > >> >> > >> >> > _________________________________________________________________ >> >> > 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@chatspike.net >> >Network Administrator of the ChatSpike IRC Network. >> >ChatSpike, the users network! www.chatspike.net >> > >> > >> >_________________________________________________________________ >> >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 >> >> --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 > > > > >-- >Craig McLure >Craig@chatspike.net >Network Administrator of the ChatSpike IRC Network. >ChatSpike, the users network! www.chatspike.net > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > >------------------------------------------------------------------ >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 frostycoolslug at hotmail.com Fri May 3 03:25:32 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Error during make Message-ID: Note to self: RTFM :) i got in contact with the box owner, should be installed by tonite ;) thanks agn, and once again, keep up the good work!! :))) >From: achurch@achurch.org (Andrew Church) >Reply-To: ircservices-coding@ircservices.za.net >To: ircservices-coding@ircservices.za.net >Subject: Re: [IRCServices Coding] Error during make > > >its 3.78.1 > >will mail shell provider :) > > Then you'll need to upgrade it (presumably this means installing the >new version on your shell). Services won't work with anything earlier than >3.79. I could mention that this is clearly stated in section 2 of the >manual. > > >cheers :) > > > > > >>From: achurch@achurch.org (Andrew Church) > >>Reply-To: ircservices-coding@ircservices.za.net > >>To: ircservices-coding@ircservices.za.net > >>Subject: Re: [IRCServices Coding] Error during make > >>Date: Fri, 03 May 2002 03:25:08 JST > >>Received: from [196.7.148.5] by hotmail.com (3.2) with ESMTP id > >>MHotMailBE9ACFC4000A4004324BC4079405EF4C0; Thu, 02 May 2002 11:26:21 >-0700 > >>Received: from snow.fingers.co.za (localhost.fingers.co.za >[127.0.0.1])by > >>snow.fingers.co.za (Postfix) with ESMTPid 4116F17428; Thu, 2 May 2002 > >>20:26:07 +0200 (SAST) > >>Received: from achurch.org (unknown [210.145.195.3])by >snow.fingers.co.za > >>(Postfix) with SMTP id 0BA6F17420for > >>; Thu, 2 May 2002 20:25:22 +0200 > >>(SAST) > >>Received: by achurch.org (wmail 0.9.16) id 3cd1848e.35676; Fri, 03 May >2002 > >>03:25:18 JST > >>From ircservices-coding-admin@ircservices.za.net Thu, 02 May 2002 >11:27:53 > >>-0700 > >>Delivered-To: ircservices-coding@snow.fingers.co.za > >>X-Mailer: MMail v5.01 > >>Message-ID: <3cd1848e.35676@achurch.org> > >>Sender: ircservices-coding-admin@ircservices.za.net > >>Errors-To: ircservices-coding-admin@ircservices.za.net > >>X-BeenThere: ircservices-coding@ircservices.za.net > >>X-Mailman-Version: 2.0.8 > >>Precedence: bulk > >>List-Help: > >> > >>List-Post: > >>List-Subscribe: > >>, > >>List-Id: IRC Services Coding Mailing List > >> > >>List-Unsubscribe: > >>, > >>List-Archive: > > >> > >> >i tried gmake.. no difference :/ > >> > >> Is your gmake up to date? (v3.79.1) > >> > >> > > >> >>From: "Tom Moyer" > >> >>Reply-To: ircservices-coding@ircservices.za.net > >> >>To: > >> >>Subject: Re: [IRCServices Coding] Error during make > >> >>Date: Thu, 2 May 2002 09:55:05 -0700 > >> >>MIME-Version: 1.0 > >> >>X-Originating-IP: [67.203.71.74] > >> >>Received: from [196.7.148.5] by hotmail.com (3.2) with ESMTP id > >> >>MHotMailBE9A9EC90018400431DFC4079405DD870; Thu, 02 May 2002 07:57:32 > >>-0700 > >> >>Received: from snow.fingers.co.za (localhost.fingers.co.za > >>[127.0.0.1])by > >> >>snow.fingers.co.za (Postfix) with ESMTPid 3EC011742A; Thu, 2 May >2002 > >> >>16:57:07 +0200 (SAST) > >> >>Received: from hotmail.com (oe23.law3.hotmail.com [209.185.240.16])by > >> >>snow.fingers.co.za (Postfix) with ESMTP id 312E617420for > >> >>; Thu, 2 May 2002 16:56:38 >+0200 > >> >>(SAST) > >> >>Received: from mail pickup service by hotmail.com with Microsoft > >>SMTPSVC; > >> >>Thu, 2 May 2002 07:56:33 -0700 > >> >>From ircservices-coding-admin@ircservices.za.net Thu, 02 May 2002 > >>07:57:57 > >> >>-0700 > >> >>Delivered-To: ircservices-coding@snow.fingers.co.za > >> >>References: > >> >>X-Priority: 3 > >> >>X-MSMail-Priority: Normal > >> >>X-Mailer: Microsoft Outlook Express 6.00.2600.0000 > >> >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > >> >>Message-ID: > >> >>X-OriginalArrivalTime: 02 May 2002 14:56:33.0554 (UTC) > >> >>FILETIME=[8CD52F20:01C1F1E9] > >> >>Sender: ircservices-coding-admin@ircservices.za.net > >> >>Errors-To: ircservices-coding-admin@ircservices.za.net > >> >>X-BeenThere: ircservices-coding@ircservices.za.net > >> >>X-Mailman-Version: 2.0.8 > >> >>Precedence: bulk > >> >>List-Help: > >> >> > >> >>List-Post: > >> >>List-Subscribe: > >> > >>, > >> >>List-Id: IRC Services Coding Mailing List > >> >> > >> >>List-Unsubscribe: > >> > >>, > >> >>List-Archive: > >> > >> >> > >> >>this is off the wall but try gmake instead... > >> >>----- Original Message ----- > >> >>From: "Craig McLure" > >> >>To: > >> >>Sent: Thursday, May 02, 2002 7:51 AM > >> >>Subject: [IRCServices Coding] Error during make > >> >> > >> >> > >> >> > ./confiure works fine.. > >> >> > comes to make thou.. > >> >> > > >> >> > --- [ SNIP ] --- > >> >> > make[1]: Entering directory > >> >> > `/home/devon/chatspike/ircservices-5.0a30/modules' > >> >> > make[2]: Entering directory > >> >> > `/home/devon/chatspike/ircservices-5.0a30/modules/chanserv' > >> >> > make[2]: *** No rule to make target `main.so', needed by > >>`all-dynamic'. > >> >> > Stop. > >> >> > make[2]: Leaving directory > >> >> > `/home/devon/chatspike/ircservices-5.0a30/modules/chanserv' > >> >> > make[1]: *** [all-dynamic] Error 2 > >> >> > make[1]: Leaving directory > >> >> > `/home/devon/chatspike/ircservices-5.0a30/modules' > >> >> > make: *** [modules] Error 2 > >> >> > --- [ SNIP ] --- > >> >> > > >> >> > Ne help appreciated :) > >> >> > cheers > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > Craig McLure > >> >> > Craig@chatspike.net > >> >> > Network Administrator of the ChatSpike IRC Network. > >> >> > ChatSpike, the users network! www.chatspike.net > >> >> > > >> >> > > >> >> > _________________________________________________________________ > >> >> > 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@chatspike.net > >> >Network Administrator of the ChatSpike IRC Network. > >> >ChatSpike, the users network! www.chatspike.net > >> > > >> > > >> >_________________________________________________________________ > >> >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 > >> > >> --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 > > > > > > > > > >-- > >Craig McLure > >Craig@chatspike.net > >Network Administrator of the ChatSpike IRC Network. > >ChatSpike, the users network! www.chatspike.net > > > >_________________________________________________________________ > >Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp. > > > >------------------------------------------------------------------ > >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/ >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From gizm0 at mail.gr Fri May 3 18:10:07 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Services 5.0 alpha 31 released Message-ID: <102043860701@mailserver.mail.gr> found a cosmetic bug in StatServ. when i tried /ss servers delete server.name it returned the wrong Syntax thing and not Permission Denied(because i wasn't services root at the moment.)Check it out.Good work at a31. Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From frostycoolslug at hotmail.com Fri May 3 10:42:54 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Fwd: "libsafe violation for Authorization code for Craig, pid=26787; The authorization code for your nickname (Craig) is: 158035136 Message-ID: y0, when i try to register a nickname, services dies :p i then recive this mail: --- [ SNIP ] --- >From: devon@chex.usnuk.net >To: Craig@chatspike.met >Subject: "libsafe violation for Authorization code for Craig, pid=26787; >The authorization code for your nickname (Craig) is: 158035136 >Date: Fri, 03 May 2002 13:23:10 -0400 > >Please submit this code to NickServ with the command: > /msg NickServ AUTH 158035136 > >This message was sent by NickServ in response to registration by >Craig@modem-991.charizard.dialup.pol.co.uk." > --- [ SNIP ] --- ne ideas whats wrong, or how to get more info on the prob? cheers :) -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From dwd at buli.net Fri May 3 16:13:59 2002 From: dwd at buli.net (dwd@buli.net) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] G LINE Message-ID: /gline *@*proxy* 0 :Proxy banned [00:12:26] (SNotice) *** Permanent G:Line added for *@*proxy* on Fri May 3 21:11:19 2002 GMT (from dwd!admin@datachat.net: Proxy banned) [00:12:26] (SNotice) services.datachat.net removed G:Line *@*proxy* (set at Fri May 3 21:11:19 2002 - reason: Proxy banned) why? -- dwd ICQ#108548590 http://datachat.net info@datachat.net From rg at tcslon.com Sat May 4 02:44:00 2002 From: rg at tcslon.com (Russ Garrett) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] G LINE References: Message-ID: <3CD3AD60.6090107@tcslon.com> dwd@buli.net wrote: >/gline *@*proxy* 0 :Proxy banned > >[00:12:26] (SNotice) *** Permanent G:Line added for *@*proxy* on Fri May 3 21:11:19 2002 GMT (from dwd!admin@datachat.net: Proxy banned) >[00:12:26] (SNotice) services.datachat.net removed G:Line *@*proxy* (set at Fri May 3 21:11:19 2002 - reason: Proxy banned) > >why? > > For security reasons, services unset all G:lines, forcing you to use AKills in operserv which have better security controls on them. Russ Garrett (russ@garrett.co.uk) From gizm0 at mail.gr Sat May 4 14:29:05 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] G LINE Message-ID: <102051174501@mailserver.mail.gr> > >/gline *@*proxy* 0 :Proxy banned > > > >[00:12:26] (SNotice) *** Permanent G:Line added for *@*proxy* on Fri > May 3 21:11:19 2002 GMT (from dwd!admin@datachat.net: Proxy banned) > >[00:12:26] (SNotice) services.datachat.net removed G:Line *@*proxy* > (set at Fri May 3 21:11:19 2002 - reason: Proxy banned) > > > >why? > > > > > For security reasons, services unset all G:lines, forcing you to use > AKills in operserv which have better security controls on them. Russ,i think you are wrong pal.Mine doesn't do anything like that for securtiy reason.Check your expiration on Glines in the config file.it could be your expiration time .. Gizm0 ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From rg at tcslon.com Sat May 4 05:57:21 2002 From: rg at tcslon.com (Russ Garrett) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] G LINE References: <102051174501@mailserver.mail.gr> Message-ID: <3CD3DAB1.8070009@tcslon.com> Panagiotis Kefalidis ( Gizm0 ) wrote: >>>/gline *@*proxy* 0 :Proxy banned >>> >>>[00:12:26] (SNotice) *** Permanent G:Line added for *@*proxy* on Fri >>> >>> >>May 3 21:11:19 2002 GMT (from dwd!admin@datachat.net: Proxy banned) >> >> >>>[00:12:26] (SNotice) services.datachat.net removed G:Line *@*proxy* >>> >>> >>(set at Fri May 3 21:11:19 2002 - reason: Proxy banned) >> >> >>>why? >>> >>> >>> >>> >>For security reasons, services unset all G:lines, forcing you to use >>AKills in operserv which have better security controls on them. >> >> >Russ,i think you are wrong pal.Mine doesn't do anything like that for >securtiy reason.Check your expiration on Glines in the config file.it >could be your expiration time .. > > > *AHEM* FAQ says: C.9. I'm using Unreal, and Services keeps removing any G-lines placed with /gline. How can I make it stop? You can't. Use the OperServ AKILL command to set network-wide user bans. RTFM :P Russ Garrett (russ@garrett.co.uk) From uhc0 at rz.uni-karlsruhe.de Sat May 4 05:06:11 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:23 2004 Subject: AW: [IRCServices Coding] G LINE In-Reply-To: <102051174501@mailserver.mail.gr> Message-ID: <000e01c1f364$26f19410$02c8a8c0@nygmatech.local> You also do not use Unreal, do you ? On bahamut there is no /gline anyway, and you cannot /akill, but only /os akill; and services will not remove anything. On Unreal, services will remove glines, aka TKL + G's issued by operators and will only allow placement of them via OperServ. 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 Panagiotis Kefalidis ( Gizm0 ) > Gesendet: Samstag, 4. Mai 2002 16:29 > An: ircservices-coding@ircservices.za.net > Betreff: Re: [IRCServices Coding] G LINE > > > > >/gline *@*proxy* 0 :Proxy banned > > > > > >[00:12:26] (SNotice) *** Permanent G:Line added for > *@*proxy* on Fri > > May 3 21:11:19 2002 GMT (from dwd!admin@datachat.net: Proxy banned) > > >[00:12:26] (SNotice) services.datachat.net removed G:Line *@*proxy* > > (set at Fri May 3 21:11:19 2002 - reason: Proxy banned) > > > > > >why? > > > > > > > > For security reasons, services unset all G:lines, forcing you to use > > AKills in operserv which have better security controls on them. > Russ,i think you are wrong pal.Mine doesn't do anything like > that for securtiy reason.Check your expiration on Glines in > the config file.it could be your expiration time .. > > > > > Gizm0 > > ------------------------------------------------------------- > http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From r-krisztian at softhome.net Sat May 4 06:03:34 2002 From: r-krisztian at softhome.net (=?iso-8859-1?Q?Romek_Kriszti=E1n?=) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Op, deop, etc... References: <000e01c1f364$26f19410$02c8a8c0@nygmatech.local> Message-ID: <000e01c1f36c$19551b30$0a00000a@krisz> My problem is that if an IRC Operator wants to have a +q channel flag in a registered Channel, then ChanServ changes mode -q. It does also the same if I want /mode +a or +o nick. ircservices5.0alpha30 didn't do that. Can I turn off that somehow? AngryWolf From dwd at buli.net Sat May 4 07:05:50 2002 From: dwd at buli.net (dwd@buli.net) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Re: G LINE Message-ID: thx to all :) -- dwd ICQ#108548590 http://datachat.net info@datachat.net From r-krisztian at softhome.net Sat May 4 23:25:23 2002 From: r-krisztian at softhome.net (=?iso-8859-2?Q?Romek_Kriszti=E1n?=) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] ajoin bug in 5.0alpha31 Message-ID: <01c1f3fd$a3d671a0$0b00000a@gep11.rokusnet.hu> -NickServ- Sorry, you can only have 0 autojoin entries for a nickname. AngryWolf From chris at monkeyircd.org Sun May 5 04:15:42 2002 From: chris at monkeyircd.org (Chris Plant) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Dynamic Modules on OpenBSD Message-ID: <1020597348.2082.11.camel@hermes> Hello Peeps On OpenBSD the flags to dlopen should be DL_LAZY, which is for future compatibility (according to its manpage), also, it needs an underscore prefixed onto any symbol you try and get from the modules (i believe this is due to the a.out binary format, and it isn't handled in BSD's dl* routines). I just tried a compile on OpenBSD 3.0, and ircservices doesn't handle either of these quirks, it should be a relatively simple makefile/configure change to get ircservices to account for them. Chris From mark at ctcp.net Sun May 5 15:07:06 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] IRCServices and Cygwin Message-ID: <1623.193.237.130.98.1020636426.squirrel@secure.uksolutions.co.uk> I have used Cygwin for various tasks over the last few years on Wintel boxes and today was playing around with a build of IRCServices under Cygwin. It compiles without problems with the exception of the tools. It also runs to a degree. At this time I have not investigated why tools do not compile nor why certain parts of services fail unexpectedly. (e.g. forcenickchange gets disabled at runtime despite connecting with an appropriate protocol module, I suspect an issue with static modules since configure caused static modules to be selected - what does services do for protocol in the event of a static module compilation?). The FAQ mentions that a Windows version does not currently exist and would likely be implemented through the submission of patches enabling it to run. Since services is almost fully functional under Cygwin, as an interim measure, would patches for running under Cygwin be welcomed? I will probably look at a native Windows port later this year when I have more time available and version 5 has gone "gold". BTW, on the subject of the FAQ, Questions C9 and F9 are the same (Unreal /gline info). -- Mark. From achurch at achurch.org Tue May 7 21:01:23 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Services 5.0 alpha 31 released Message-ID: <3cd7c2e6.41074@achurch.org> This is intentional behavior (people without access to those commands have no business knowing that they even exist), but since the commands do show up in help messages for operators, I'll change it to say "permission denied" for operators instead of giving the syntax message. --Andrew Church achurch@achurch.org http://achurch.org/ >found a cosmetic bug in StatServ. >when i tried /ss servers delete server.name it returned the >wrong Syntax thing and not Permission Denied(because i wasn't services >root at the moment.)Check it out.Good work at a31. > >Gizm0.- > >------------------------------------------------------------- >http://www.mail.gr/ - Get Your Private Free Email Address! >http://www.ringtone.gr/ - Ringtones & Logos for your mobile! >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Tue May 7 21:07:15 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Dynamic Modules on OpenBSD Message-ID: <3cd7c3f3.41124@achurch.org> DL_LAZY shouldn't be needed, and in fact goes contrary to what I want (which is to resolve all symbols on load and fail if some are missing). Did you read the manual page correctly? As far as the underscores, I'll see about putting in a check for those in the configure script. --Andrew Church achurch@achurch.org http://achurch.org/ > >Hello Peeps > >On OpenBSD the flags to dlopen should be DL_LAZY, which is for future >compatibility (according to its manpage), also, it needs an underscore >prefixed onto any symbol you try and get from the modules (i believe >this is due to the a.out binary format, and it isn't handled in BSD's >dl* routines). >I just tried a compile on OpenBSD 3.0, and ircservices doesn't handle >either of these quirks, it should be a relatively simple >makefile/configure change to get ircservices to account for them. > >Chris > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Tue May 7 21:11:27 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] IRCServices and Cygwin Message-ID: <3cd7c772.41150@achurch.org> >I have used Cygwin for various tasks over the last few years on Wintel >boxes and today was playing around with a build of IRCServices under >Cygwin. > >It compiles without problems with the exception of the tools. It also runs >to a degree. At this time I have not investigated why tools do not compile >nor why certain parts of services fail unexpectedly. (e.g. forcenickchange >gets disabled at runtime despite connecting with an appropriate protocol >module, I suspect an issue with static modules since configure caused >static modules to be selected - what does services do for protocol in the >event of a static module compilation?). See send.c for the details, but the protocol_xxx variables are defined in send.c, which has a load-module handler that copies the values from whatever protocol module is loaded. Come to think of it, that could be the problem--I'll take a look. >The FAQ mentions that a Windows version does not currently exist and would >likely be implemented through the submission of patches enabling it to run. >Since services is almost fully functional under Cygwin, as an interim >measure, would patches for running under Cygwin be welcomed? I will >probably look at a native Windows port later this year when I have more >time available and version 5 has gone "gold". > >BTW, on the subject of the FAQ, Questions C9 and F9 are the same >(Unreal /gline info). Sounds like you're looking at an old copy of the FAQ. As far as a Windows port goes, I'd rather limit it to Cygwin support, because it seems like a whole bunch of patches and conditional compilation would be needed for native Windows support. (You're welcome to try, of course, and let me know how it comes out; I'll think about it if it doesn't require too many changes to the code.) --Andrew Church achurch@achurch.org http://achurch.org/ From chris at monkeyircd.org Tue May 7 09:24:13 2002 From: chris at monkeyircd.org (Chris Plant) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Dynamic Modules on OpenBSD In-Reply-To: <3cd7c3f3.41124@achurch.org> References: <3cd7c3f3.41124@achurch.org> Message-ID: <1020788655.1448.2.camel@hermes.111balmoral.co.uk> DL_LAZY is only needed for future compatibility, as stated in the OpenBSD 3.0 man page. man dlopen reports: "The path argument can either be an absolute pathname or it can be of the form ``lib.so[.xx[.yy]]'' in which case the same library search rules apply that are used for ``intrinsic'' shared library searches. The second argument currently has no effect, but should be set to DL_LAZY for future compatibility." On Tue, 2002-05-07 at 22:07, Andrew Church wrote: > DL_LAZY shouldn't be needed, and in fact goes contrary to what I want > (which is to resolve all symbols on load and fail if some are missing). > Did you read the manual page correctly? As far as the underscores, I'll > see about putting in a check for those in the configure script. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > > > > >Hello Peeps > > > >On OpenBSD the flags to dlopen should be DL_LAZY, which is for future > >compatibility (according to its manpage), also, it needs an underscore > >prefixed onto any symbol you try and get from the modules (i believe > >this is due to the a.out binary format, and it isn't handled in BSD's > >dl* routines). > >I just tried a compile on OpenBSD 3.0, and ircservices doesn't handle > >either of these quirks, it should be a relatively simple > >makefile/configure change to get ircservices to account for them. > > > >Chris > > > >------------------------------------------------------------------ > >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 Wed May 8 01:44:31 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Dynamic Modules on OpenBSD Message-ID: <3cd804e4.41707@achurch.org> >DL_LAZY is only needed for future compatibility, as stated in the >OpenBSD 3.0 man page. >man dlopen reports: >"The path argument can either be an absolute pathname or it can be of >the form ``lib.so[.xx[.yy]]'' in which case the same library >search rules apply that are used for ``intrinsic'' shared library >searches. The second argument currently has no effect, but should be >set to DL_LAZY for future compatibility." Then it sounds like OpenBSD is already doing things the wrong way, so I'll probably just disable dynamic modules entirely for it. --Andrew Church achurch@achurch.org http://achurch.org/ >On Tue, 2002-05-07 at 22:07, Andrew Church wrote: >> DL_LAZY shouldn't be needed, and in fact goes contrary to what I want >> (which is to resolve all symbols on load and fail if some are missing). >> Did you read the manual page correctly? As far as the underscores, I'll >> see about putting in a check for those in the configure script. >> >> --Andrew Church >> achurch@achurch.org >> http://achurch.org/ >> >> > >> >Hello Peeps >> > >> >On OpenBSD the flags to dlopen should be DL_LAZY, which is for future >> >compatibility (according to its manpage), also, it needs an underscore >> >prefixed onto any symbol you try and get from the modules (i believe >> >this is due to the a.out binary format, and it isn't handled in BSD's >> >dl* routines). >> >I just tried a compile on OpenBSD 3.0, and ircservices doesn't handle >> >either of these quirks, it should be a relatively simple >> >makefile/configure change to get ircservices to account for them. >> > >> >Chris >> > >> >------------------------------------------------------------------ >> >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 chris at monkeyircd.org Tue May 7 09:49:18 2002 From: chris at monkeyircd.org (Chris Plant) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Dynamic Modules on OpenBSD In-Reply-To: <3cd804e4.41707@achurch.org> References: <3cd804e4.41707@achurch.org> Message-ID: <1020790158.2652.3.camel@hermes.111balmoral.co.uk> On Wed, 2002-05-08 at 02:44, Andrew Church wrote: Hehe, came to that conclusion myself :). > >DL_LAZY is only needed for future compatibility, as stated in the > >OpenBSD 3.0 man page. > >man dlopen reports: > >"The path argument can either be an absolute pathname or it can be of > >the form ``lib.so[.xx[.yy]]'' in which case the same library > >search rules apply that are used for ``intrinsic'' shared library > >searches. The second argument currently has no effect, but should be > >set to DL_LAZY for future compatibility." > > Then it sounds like OpenBSD is already doing things the wrong way, > so I'll probably just disable dynamic modules entirely for it. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > > >On Tue, 2002-05-07 at 22:07, Andrew Church wrote: > >> DL_LAZY shouldn't be needed, and in fact goes contrary to what I want > >> (which is to resolve all symbols on load and fail if some are missing). > >> Did you read the manual page correctly? As far as the underscores, I'll > >> see about putting in a check for those in the configure script. > >> > >> --Andrew Church > >> achurch@achurch.org > >> http://achurch.org/ > >> > >> > > >> >Hello Peeps > >> > > >> >On OpenBSD the flags to dlopen should be DL_LAZY, which is for future > >> >compatibility (according to its manpage), also, it needs an underscore > >> >prefixed onto any symbol you try and get from the modules (i believe > >> >this is due to the a.out binary format, and it isn't handled in BSD's > >> >dl* routines). > >> >I just tried a compile on OpenBSD 3.0, and ircservices doesn't handle > >> >either of these quirks, it should be a relatively simple > >> >makefile/configure change to get ircservices to account for them. > >> > > >> >Chris > >> > > >> >------------------------------------------------------------------ > >> >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 frostycoolslug at hotmail.com Tue May 7 11:14:07 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Just in case.. Message-ID: Just in case ne1 cares.. gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -c init.c -o init.o init.c:497:23: warning: multi-line string literals are deprecated :p -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From griever at t2n.org Tue May 7 11:50:34 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Just in case.. In-Reply-To: Message-ID: On Tue, 7 May 2002, Craig McLure wrote: > Just in case ne1 cares.. > > gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -c init.c -o init.o > init.c:497:23: warning: multi-line string literals are deprecated This really should be fixed. From frostycoolslug at hotmail.com Tue May 7 11:54:18 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Mail-Auth = br0ked :/ Message-ID: i've tried this under different compilers, but e-mail authentication doesnt seem to work on my box, Red-hat 6.2, GCC 3.0.4 i've tried both SendMail and SMTP, also 2 different Versions of services (alpha30 & 31) i sometimes get an e-mail titled "libsafe violation..." Just before services dies :/ can ne1 help? :) -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From achurch at achurch.org Wed May 8 09:35:29 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Just in case.. Message-ID: <3cd87317.42551@achurch.org> >Just in case ne1 cares.. > >gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -c init.c -o init.o >init.c:497:23: warning: multi-line string literals are deprecated Well, I personally think gcc3's warnings are deprecated :P but fixed. --Andrew Church achurch@achurch.org http://achurch.org/ From frostycoolslug at hotmail.com Tue May 7 17:41:30 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Just in case.. Message-ID: *adds to list of famous quotes ;) Andrew, u had a chance to look over my mail-auth probs yet, i think i sent 2 mails about it.. >From: achurch@achurch.org (Andrew Church) >Reply-To: ircservices-coding@ircservices.za.net >To: ircservices-coding@ircservices.za.net >Subject: Re: [IRCServices Coding] Just in case.. >Date: Wed, 08 May 2002 09:35:29 JST > > >Just in case ne1 cares.. > > > >gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -c init.c -o init.o > >init.c:497:23: warning: multi-line string literals are deprecated > > Well, I personally think gcc3's warnings are deprecated :P but fixed. > > --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 -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From achurch at achurch.org Wed May 8 09:54:00 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Just in case.. Message-ID: <3cd87750.42635@achurch.org> >Andrew, u had a chance to look over my mail-auth probs yet, i think i sent 2 >mails about it.. I've never seen anything like it (and I don't use libsafe), so all I can say is have fun debugging. --Andrew Church achurch@achurch.org http://achurch.org/ From frostycoolslug at hotmail.com Tue May 7 18:34:21 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Just in case.. Message-ID: ok, i'm not the debugging type! if i give u access to the shell, and the server.. wanna have a look? :) >From: achurch@achurch.org (Andrew Church) >Reply-To: ircservices-coding@ircservices.za.net >To: ircservices-coding@ircservices.za.net >Subject: Re: [IRCServices Coding] Just in case.. > > >Andrew, u had a chance to look over my mail-auth probs yet, i think i >sent 2 > >mails about it.. > > I've never seen anything like it (and I don't use libsafe), so all I >can say is have fun debugging. > > --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 -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From chris at monkeyircd.org Wed May 8 08:15:00 2002 From: chris at monkeyircd.org (Chris Plant) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Just in case.. In-Reply-To: <3cd87317.42551@achurch.org> References: <3cd87317.42551@achurch.org> Message-ID: <1020870905.1443.1.camel@hermes.111balmoral.co.uk> On Wed, 2002-05-08 at 10:35, Andrew Church wrote: > >Just in case ne1 cares.. > > > >gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -c init.c -o init.o > >init.c:497:23: warning: multi-line string literals are deprecated > > Well, I personally think gcc3's warnings are deprecated :P but fixed. > > --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 gcc 3.0 was always fine for me, except for a problem with multiple heritance. Thats probably a five second fix. Chris From r-krisztian at softhome.net Thu May 9 08:40:31 2002 From: r-krisztian at softhome.net (Romek =?iso-8859-1?q?Kriszti=E9n?=) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] ChanServ In-Reply-To: <1020870905.1443.1.camel@hermes.111balmoral.co.uk> References: <3cd87317.42551@achurch.org> <1020870905.1443.1.camel@hermes.111balmoral.co.uk> Message-ID: <02050917403100.13155@adsl52089> Hello! I have a channel which has only one setting: topic retention. All the others are turned off. If some IRC operator gives op himself, then ChanServ deops him. Why? This problem wasn't in alpha 30 and don't know whether it's a bug or not. And there's another one, but it's maybe not a bug: if nobody is on a registerd channel, then ChanServ joins, and leaves when somebody joins. Can you help me? AngryWolf From VisionOfHell at aol.com Thu May 9 11:00:50 2002 From: VisionOfHell at aol.com (VisionOfHell@aol.com) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] PID file becomes stale immediately Message-ID: <80.1b6f2c30.2a0c1352@aol.com> Any reason why when services is booted the PID is created, then when the crontab kicks in it keeps telling me the PID is stale? Happened on .28 and now on .31 From achurch at achurch.org Fri May 10 11:52:23 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] PID file becomes stale immediately Message-ID: <3cdb35fb.53540@achurch.org> >Any reason why when services is booted the PID is created, then when the >crontab kicks in it keeps telling me the PID is stale? At a guess, because your crontab script is broken? --Andrew Church achurch@achurch.org http://achurch.org/ From VisionOfHell at aol.com Fri May 10 08:35:28 2002 From: VisionOfHell at aol.com (VisionOfHell@aol.com) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Re: IRCServices-Coding digest, Vol 1 #125 - 3 msgs Message-ID: <94.261f3daf.2a0d42c0@aol.com> At a guess id say more specifically: 1) It has worked with non v5 2) The pid is created and then once it becomes stale disappears 3) I see nothing wrong with below #!/bin/sh servicesdir="/home/chris/servers/services/bin" piddir="/home/chris/servers/services/lib" name="ircservices" ########## you probably don't need to change anything below here ########## cd $piddir if test -r $name.pid; then # there is a pid file -- is it current? mypid=`cat $name.pid` if `kill -CHLD $mypid >/dev/null 2>&1`; then # it's still going # back out quietly exit 0 fi echo "" echo "Stale $name.pid file (erasing it)" rm -f $name.pid fi echo "" echo "Couldn't find the daemon running. Reloading it..." echo "" cd $servicesdir ./$name exit 0 From gizm0 at mail.gr Sat May 11 12:28:28 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Found a bug in NickServ Message-ID: <102110930801@mailserver.mail.gr> Think i found a little bug in nickserv. I've suspend a nick several days ago.I've unsuspend the last week (i think so).One of my friends registered and it worked fine.My friend logged on the network identified for his nick.By mistake he tried to register the same nick again (I've added to the nickserv to wallop if someone tried to register a suspended or forbided nick) the services returned to my friend the notice_lang this nick is already registered by someone else and walloped that my friend tried to register a suspended nick.As i said i've unsuspended the nick and my friend has already registered and identified for it without any probs.Any ideas why is this happening? Regards, Gizm0 ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From gizm0 at mail.gr Sun May 12 11:09:11 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] To bug or not to bug? Message-ID: <102119095201@mailserver.mail.gr> [May 11 20:47:20 2002] Services terminating: Segmentation fault [May 11 21:12:48 2002] IRC Services 5.0a29 starting up [May 11 21:12:49 2002] FATAL: database/version4: Invalid format in nick.db [May 11 21:12:49 2002] sockets: [v]sockprintf() with NULL socket! What's this? "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From achurch at achurch.org Sun May 12 21:44:37 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] To bug or not to bug? Message-ID: <3cde642d.02635@achurch.org> >[May 11 20:47:20 2002] Services terminating: Segmentation fault >[May 11 21:12:48 2002] IRC Services 5.0a29 starting up >[May 11 21:12:49 2002] FATAL: database/version4: Invalid format in nick.db >[May 11 21:12:49 2002] sockets: [v]sockprintf() with NULL socket! > >What's this? It's someone using an old version of Services to report bugs. >"I can see the darkness in your eyes." > Gizm0.- > >------------------------------------------------------------- >http://www.mail.gr/ - Get Your Private Free Email Address! >http://www.ringtone.gr/ - Ringtones & Logos for your mobile! >------------------------------------------------------------------ >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 Mon May 13 00:20:49 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Op, deop, etc... Message-ID: <3cde88ab.12002@achurch.org> >My problem is that if an IRC Operator wants to have a +q channel flag in a >registered Channel, then ChanServ changes mode -q. It does also the same if >I want /mode +a or +o nick. ircservices5.0alpha30 didn't do that. Can I turn >off that somehow? This is due to a check that prevents -o users from changing channel modes. I've modified it so it allows IRC operators to change modes even if -o. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Mon May 13 00:28:01 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Found a bug in NickServ Message-ID: <3cde8a22.12070@achurch.org> >Think i found a little bug in nickserv. >I've suspend a nick several days ago.I've unsuspend the last week (i >think so).One of my friends registered and it worked fine.My friend >logged on the network identified for his nick.By mistake he tried to >register the same nick again (I've added to the nickserv to wallop if >someone tried to register a suspended or forbided nick) the services >returned to my friend the notice_lang this nick is already registered by >someone else and walloped that my friend tried to register a suspended >nick.As i said i've unsuspended the nick and my friend has already >registered and identified for it without any probs.Any ideas why is this >happening? At a guess, because you wrote the wallops code incorrectly? --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Mon May 13 00:49:00 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Services 5.0 alpha 32 released Message-ID: <3cde909b.27225@achurch.org> Okay, so I've finally worked my way through my local bug list and taken care of everything there. I still need to give the code one last run-over, and see what things in the TODO list deserve to go into 5.0, but this alpha can be considered the equivalent of a "release candidate" for the first beta version. As usual, please let me know of any problems you encounter--the less problems left in the beta version, the fewer questions I have to field from all the people who try the beta out and find it crashing all over the place. (: Actually, it just occurred to me I still need to resolve that FreeBSD socket issue... so I guess there'll be at least one more alpha coming out after all. Changes in version 5.0 alpha 32 ------------------------------- 2002/05/13 ChanServ no longer removes chanops from IRC operators who give themselves or others +o via an ircd feature. Reported by Romek Krisztian 2002/05/13 Added StatServ support to httpd/dbaccess module. 2002/05/12 Changed the default required access level for the ChanServ CLEAR command from founder-only to 100 (SOP). 2002/05/12 The ChanServ LEVELS help no longer mentions the SOP/AOP/etc. commands if the access-xop module is not loaded. 2002/05/12 Fixed a bug causing ChanServ LEVELS DESC help to be displayed for all LEVELS help queries _except_ LEVELS DESC. 2002/05/10 Fixed failure to recognize protocol features when using static modules, and added extra checks to ensure variables are set up correctly. 2002/05/09 Improved dynamic module usability check in configure script to handle OpenBSD correctly. Suggested by Chris Plant (chris@monkeyircd.org) 2002/05/08 Changed init.c to avoid a compilation warning under GCC 3. Reported by Craig McLure 2002/05/07 StatServ SERVERS DELETE and other root-only commands now say "permission denied" instead of "syntax error" when used by a non-root IRC operator. 2002/05/07 Fixed cosmetic bug in AJOIN list-full error message. Reported by Romek Krisztian --Andrew Church achurch@achurch.org http://achurch.org/ From gizm0 at mail.gr Sun May 12 20:14:30 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] To bug or not to bug? Message-ID: <102122367001@mailserver.mail.gr> yeah right.it's someone using an old version of services.I don't.I just modify and update through the releases without updating the version.h thing.that's why you see the old version number. this is in version a31 and not in a29. thanx :) regards, Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From gizm0 at mail.gr Sun May 12 20:15:35 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Found a bug in NickServ Message-ID: <102122373501@mailserver.mail.gr> > At a guess, because you wrote the wallops code incorrectly? no i didn't.i checked it twice. > > --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 "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From manual3000 at hotmail.com Sun May 12 16:49:18 2002 From: manual3000 at hotmail.com (manual 3000) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] suggestion : crontab - services check script Message-ID: Hi. I am new to services and i would like to make 2 suggestions. A. I think you should add a script tha checks if services are up (stale pid) an if not to load them. I know there are many out there but an official one would be nice. My suggestion considers the following: 1. a file (i.e. autoservchck )that if ran should add a crontab entry running the file servchk every XX mins. 2. a script (i.e. servchk ) tha should check for a stale pid and reload the services if they are dead. The script should be made as not to send email (via sendmail) on every failed services run attempt and if possible to write a file instead (with failed attempts) Thats all about the crontab thing. B. The services.log file is getting bigger and bigger every day and specially in big networks. I am thinking that it would be better if there was a directory (i.e logs) that every day's log would be kept there. I mean that the log file should be changed by day in a format like this : s06132002.log or something. So it would be easier to see the logs or erase the old ones. That was my suggestions and sorry for my poor english. Keep up the good work guys. Thanks, MaNUaL IRCN net _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From projectdead at UTChat.com Sun May 12 18:41:58 2002 From: projectdead at UTChat.com (projectdead@UTChat.com) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] (no subject) Message-ID: <200205130036.TAA01153@dragonraq.utchat.com> Hi, IRC.MAPOP.COM Is Using these services and is reasonable happy with them, Although there are a few LITTLE problems/queries and suggestions we have, ok, I was wondering, if there was a way to make it so chanserv operserv nickserv and memoserv were seperate services, such as the IrCore Services, used on OtherNet (Such as CS, NS, UW, CS and NS).... also, in the future, we are hoping that you will include a BotServ in the package, as our users have been asking for this service. and, finally, one more thing.... when Service Operators or service Admins Op them selve's in a USER channel ChanServ Automatically de-op's them, I dont htink it should if they are /oper on the server.. I think it should detect that and leave them.. this is even with the option secureops enabled OR Disabled... and it takes admins too long to change the options then finally op.... is there anyway around this or anything that can be done to resolve this problem?... Thanx for all your help.... If u would like to check out the irc your services are being used on plz come to irc.mapop.com .... the person to talk to there is Ghozer.... HWF or MrBOFH.... ty for your help and plz get back to me on this.... -ProjectDEAD From r-krisztian at softhome.net Sun May 12 22:57:57 2002 From: r-krisztian at softhome.net (Romek Krisztian) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] (no subject) References: <200205130036.TAA01153@dragonraq.utchat.com> Message-ID: <3CDF55E5.4070203@softhome.net> Hello! > ok, I was wondering, if there was a way to make it so chanserv operserv > nickserv and memoserv were seperate services, such as the IrCore > Services, used on OtherNet (Such as CS, NS, UW, CS and NS).... IRCServices 5.0 has modules support. > also, in the future, we are hoping that you will include a BotServ in > the package, as our users have been asking for this service. This is already off topic. More info: http://www.ircservices.za.net/pipermail/ircservices-coding/2002/000568.html > and, finally, one more thing.... when Service Operators or service > Admins Op them selve's in a USER channel ChanServ Automatically de-op's > them, I dont htink it should if they are /oper on the server.. I think > it should detect that and leave them.. this is even with the option > secureops enabled OR Disabled... and it takes admins too long to change > the options then finally op.... is there anyway around this or anything > that can be done to resolve this problem?... This problem has already been solved. Try the newest version! More info: http://www.ircservices.za.net/pipermail/ircservices-coding/2002/000658.html Krisztian Romek From alisor at softhome.net Mon May 13 04:44:16 2002 From: alisor at softhome.net (Ali Sor) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] suggestion : crontab - services check script References: Message-ID: <004501c1fa73$9f859780$70d7afc3@mshome.net> ----- Original Message ----- From: "manual 3000" To: Sent: Monday, May 13, 2002 2:49 AM Subject: [IRCServices Coding] suggestion : crontab - services check script .................... > B. The services.log file is getting bigger and bigger every day and > specially in big networks. > I am thinking that it would be better if there was a directory (i.e logs) > that every day's log would be kept there. I mean that the log file should be > changed by day in a format like this : s06132002.log or something. So it > would be easier to see the logs or erase the old ones. ......................... > Thanks, MaNUaL IRCN net i think it is a good suggestion...But maybe not for all days...10 days period can be good....Or month period For example : 10-20may.log may2002.log From gizm0 at mail.gr Mon May 13 15:52:16 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] suggestion : crontab - services check script Message-ID: <102129433601@mailserver.mail.gr> Manual, both suggestions are reasonable and good but there are some restrictions making the first one (about the crontab),not to work. The reason is that, to have access to modify the crontab,in most UNIX based operating systems,if not all, requires Root(super-user) access to modify the crontab.As known most of ircd's and IRCServices are running on shell providers who,as reasonable,don't provide Super-User access to their customers for security reasons.The second suggestion is extremely usefull and quite easy to be coded.See ya online pal ;](I'm going to add the second suggestion-feature in our services):P "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From achurch at achurch.org Tue May 14 00:17:13 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Services 5.0 alpha 33 released Message-ID: <3cdfdc1c.71446@achurch.org> Okay, I think I've pretty much got everything wrapped up now, including that socket problem (whoever was having problems before, please try again now). If no problems crop up in this version in the next few days, I'm going to go ahead and release it as the first beta, so test away and let me know if anything breaks. Changes in version 5.0 alpha 33 ------------------------------- 2002/05/14 Log filename may now contain %y, %m, or %d (replaced by the current year, month, or day) for automatic log rotation. 2002/05/14 Renamed default log, PID, and MOTD files to "ircservices.*" instead of "services.*". 2002/05/13 Added crontab script (ircservices-chk) to restart Services as needed. Suggested by 2002/05/13 Added NickServ LISTEMAIL command. Suggested by Finny Merrill 2002/05/13 Services admins can now exceed nickname and channel registration limits. 2002/05/13 Added NSRegEmailMax configuration directive for limiting the number of nicknames registered per address. Suggested by Finny Merrill 2002/05/13 Fixed a bug causing failed connections to not be detected when Services is not running in debug mode. 2002/05/13 Failed connections are now logged normally instead of as debug messages. 2002/05/13 Socket connections should now work properly on FreeBSD instead of failing most of the time. Reported by Ben Goldstein 2002/05/13 SMTP mail module now checks for " in From: names to avoid malformed headers. --Andrew Church achurch@achurch.org http://achurch.org/ From ayottew at sympatico.ca Mon May 13 08:50:15 2002 From: ayottew at sympatico.ca (Wayne Ayotte) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Services 5.0 alpha 33 released References: <3cdfdc1c.71446@achurch.org> Message-ID: <014301c1fa95$e0473a40$0201a8c0@webdevint.com> How are you doing on the manual for services? ----- Original Message ----- From: "Andrew Church" To: Sent: Monday, May 13, 2002 11:17 AM Subject: [IRCServices Coding] Services 5.0 alpha 33 released > Okay, I think I've pretty much got everything wrapped up now, > including that socket problem (whoever was having problems before, please > try again now). If no problems crop up in this version in the next few > days, I'm going to go ahead and release it as the first beta, so test away > and let me know if anything breaks. > > Changes in version 5.0 alpha 33 > ------------------------------- > 2002/05/14 Log filename may now contain %y, %m, or %d (replaced by the > current year, month, or day) for automatic log rotation. > 2002/05/14 Renamed default log, PID, and MOTD files to "ircservices.*" > instead of "services.*". > 2002/05/13 Added crontab script (ircservices-chk) to restart Services > as needed. Suggested by > 2002/05/13 Added NickServ LISTEMAIL command. Suggested by Finny > Merrill > 2002/05/13 Services admins can now exceed nickname and channel > registration limits. > 2002/05/13 Added NSRegEmailMax configuration directive for limiting > the number of nicknames registered per address. > Suggested by Finny Merrill > 2002/05/13 Fixed a bug causing failed connections to not be detected > when Services is not running in debug mode. > 2002/05/13 Failed connections are now logged normally instead of as > debug messages. > 2002/05/13 Socket connections should now work properly on FreeBSD > instead of failing most of the time. Reported by Ben > Goldstein > 2002/05/13 SMTP mail module now checks for " in From: names to avoid > malformed headers. > > --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 May 14 01:00:26 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Services 5.0 alpha 33 released Message-ID: <3cdfe336.71520@achurch.org> >How are you doing on the manual for services? It's more or less done, except for the last part of section 3, which I plan to finish up over the beta period. --Andrew Church achurch@achurch.org http://achurch.org/ From r-krisztian at softhome.net Mon May 13 11:00:47 2002 From: r-krisztian at softhome.net (Romek Krisztian) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] access list References: <3cdfe336.71520@achurch.org> Message-ID: <000a01c1faa8$1c335360$0a00000a@krisz> Hello! My friend would like to ask a question: i think services admin in earlier version could change channel access list and other options like founder without identifing into it, but now it can't do that. is it a bug, or this ability has been removed? Romek Krisztian From r-krisztian at softhome.net Mon May 13 11:11:19 2002 From: r-krisztian at softhome.net (Romek Krisztian) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] dunnowhat :) References: <3cdfe336.71520@achurch.org> Message-ID: <000e01c1faa9$94bd8570$0a00000a@krisz> *** ChanServ sets mode: +oaoa C_REATIVE_ C_REATIVE_ C_REATIVE_ C_REATIVE_ Romek Krisztian From achurch at achurch.org Tue May 14 12:19:36 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] access list Message-ID: <3ce08277.71775@achurch.org> >Hello! > >My friend would like to ask a question: > > i think services admin in earlier version could change channel >access list and other options like founder without identifing into it, but >now it can't do that. is it a bug, or this ability has been removed? No, you can still change channel options as a Services admin; the one thing that has changed is that you now have to be both opered and identified to be considered a Services admin (in previous versions, being identified was enough). --Andrew Church achurch@achurch.org http://achurch.org/ From gizm0 at mail.gr Tue May 14 12:37:19 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] access list Message-ID: <102136903901@mailserver.mail.gr> > No, you can still change channel options as a Services admin; the one yes to change the channel options, not to modify the access list without having the required access level for ACC-CHANGE. [12:56] -ChanServ- Permission denied. <-- This is the notice ChanServ returned to me when i tried to add someone to the access list without having access to the channel i tried to add him.Can you add this? "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From achurch at achurch.org Tue May 14 20:18:24 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] access list Message-ID: <3ce0f287.02573@achurch.org> >yes to change the channel options, not to modify the access list without >having the required access level for ACC-CHANGE. >[12:56] -ChanServ- Permission denied. <-- This is the notice ChanServ >returned to me when i tried to add someone to the access list without >having access to the channel i tried to add him.Can you add this? Added. --Andrew Church achurch@achurch.org http://achurch.org/ From r-krisztian at softhome.net Tue May 14 09:32:14 2002 From: r-krisztian at softhome.net (Romek Krisztian) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] LIST and LISTEMAIL References: <3cdfe336.71520@achurch.org> Message-ID: <000901c1fb64$e82429b0$0a00000a@krisz> It seems that /NS LIST and /NS LISTEMAIL has been reversed. LISTEMAIL does what LIST should do. Romek Krisztian From r-krisztian at softhome.net Tue May 14 09:44:11 2002 From: r-krisztian at softhome.net (Romek Krisztian) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] LIST and LISTEMAIL References: <3cdfe336.71520@achurch.org> <000901c1fb64$e82429b0$0a00000a@krisz> Message-ID: <000501c1fb66$9327a750$0a00000a@krisz> Sorry, I was too fast. The problem is only with /NS LIST *: -NickServ- List of entries matching *: -NickServ- End of list; 0/0 matches shown. Sorry. Romek Krisztian From projectdead at UTChat.com Tue May 14 18:29:18 2002 From: projectdead at UTChat.com (projectdead@UTChat.com) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Remote Commands Message-ID: <200205150023.TAA13923@dragonraq.utchat.com> Hi, this is IRC.MAPOP.COM ppl again, we were wondering if it is possible, or is going to be possible in the future to add remote commands such as !halfdeop, !op (said in the channel) and so fourth in instead of /ms /cs /os or using /msg ***serv blah blah blah..., if so it would be a big help when someone needs help fast and also much easier for the users to use.. and less typing..... Also, we have another question... could you incorperate Un-limited Channel registration capabilities for Service ADMINS and Service OPERATORS.. with the ability of specifying the USERNICK Of the owner (NICK Must be reg'd) and the password etc.. WITHOUT anyone being opped in the channel to be registered (This is only if you are an operator or admin.) Well thats it! ty for all the help.... -ProjectDEAD From achurch at achurch.org Wed May 15 09:31:23 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Remote Commands Message-ID: <3ce1ac68.07276@achurch.org> No and no. --Andrew Church achurch@achurch.org http://achurch.org/ >Hi, this is IRC.MAPOP.COM ppl again, we were wondering if it is >possible, or is going to be possible in the future to add remote >commands such as !halfdeop, !op (said in the channel) and so fourth in >instead of /ms /cs /os or using /msg ***serv blah blah blah..., if so it >would be a big help when someone needs help fast and also much easier >for the users to use.. and less typing..... > >Also, we have another question... could you incorperate Un-limited >Channel registration capabilities for Service ADMINS and Service >OPERATORS.. with the ability of specifying the USERNICK Of the owner >(NICK Must be reg'd) and the password etc.. WITHOUT anyone being opped >in the channel to be registered (This is only if you are an operator or >admin.) > >Well thats it! >ty for all the help.... > >-ProjectDEAD > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Wed May 15 13:11:56 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] LIST and LISTEMAIL Message-ID: <3ce1e014.10202@achurch.org> >Sorry, I was too fast. The problem is only with /NS LIST *: > >-NickServ- List of entries matching *: >-NickServ- End of list; 0/0 matches shown. Fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ From v13 at it.teithe.gr Wed May 15 03:57:18 2002 From: v13 at it.teithe.gr (V13) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Request. Message-ID: <200205151357.18294.v13@it.teithe.gr> Is it possible to add 'rename' command for nickserv (and maybe chanserv)? Just to be able to change the nickname of a user without loosing all channels he is founder to, or the access he has, or his memos etc etc... I don't know if something like that should be limited to services admins or not. <> From achurch at achurch.org Wed May 15 20:06:16 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Request. Message-ID: <3ce24139.13715@achurch.org> > Is it possible to add 'rename' command for nickserv (and maybe chanserv) >? >Just to be able to change the nickname of a user without loosing all chan >nels >he is founder to, or the access he has, or his memos etc etc... /ns link NewNick /nick NewNick /ns unlink OldNick --Andrew Church achurch@achurch.org http://achurch.org/ From frostycoolslug at hotmail.com Wed May 15 04:42:08 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Remote Commands Message-ID: lol, amazing answers there from Andrew.. accurate, and to the point! but, me and a few of my opers are working on a "BotServ" Module, which will allow commands like this... will keep you all informed! :) >From: achurch@achurch.org (Andrew Church) >Reply-To: ircservices-coding@ircservices.za.net >To: ircservices-coding@ircservices.za.net >Subject: Re: [IRCServices Coding] Remote Commands >Date: Wed, 15 May 2002 09:31:23 JST > > No and no. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > > >Hi, this is IRC.MAPOP.COM ppl again, we were wondering if it is > >possible, or is going to be possible in the future to add remote > >commands such as !halfdeop, !op (said in the channel) and so fourth in > >instead of /ms /cs /os or using /msg ***serv blah blah blah..., if so it > >would be a big help when someone needs help fast and also much easier > >for the users to use.. and less typing..... > > > >Also, we have another question... could you incorperate Un-limited > >Channel registration capabilities for Service ADMINS and Service > >OPERATORS.. with the ability of specifying the USERNICK Of the owner > >(NICK Must be reg'd) and the password etc.. WITHOUT anyone being opped > >in the channel to be registered (This is only if you are an operator or > >admin.) > > > >Well thats it! > >ty for all the help.... > > > >-ProjectDEAD > > > >------------------------------------------------------------------ > >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@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From ghozer at mapop.com Wed May 15 10:30:57 2002 From: ghozer at mapop.com (Colin Thorpe) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Channel Registration Message-ID: <20020515173240.1366517420@snow.fingers.co.za> Hi, Will you be including "network" Channel registration capabilities, or Un-Limited OPER / ADMIN Registration capabilities, instead of a max of 10 that stand's for users and ADMINS.. as we have a network that requires a large number of network channels (at-least 30) - But the channel limit is set to 10... so it will not let me regsiter anymore under the netowkr name... this would be a really useful feature to allow admins and opers to register as-many channels as needed and also to beable to modify the sop, aop and vop list's for any channel.. Also.. is there any wou of adding a hop (Half Op) command for auto % on join, as SOP and VOP does woth @ and + ?? Thanx Ghozer From gizm0 at mail.gr Wed May 15 20:30:46 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Channel Registration Message-ID: <102148384601@mailserver.mail.gr> Óôßò Wed, 15 May 2002 13:30:57 -0400 "Colin Thorpe" Ýãñáøå: > Hi, Will you be including "network" Channel registration capabilities, or > Un-Limited OPER / ADMIN Registration capabilities, instead of a max of 10 > that stand's for users and ADMINS.. as we have a network that requires a > large number of network channels (at-least 30) - But the channel limit is > set to 10... so it will not let me regsiter anymore under the netowkr > name... this would be a really useful feature to allow admins and opers > to register as-many channels as needed and also to beable to modify the > sop, aop and vop list's for any channel.. > > Also.. is there any wou of adding a hop (Half Op) command for auto % on > join, as SOP and VOP does woth @ and + ?? > > Thanx > > Ghozer this already exists in services.The new release is going to have this feature of unlimited channel/nick registration for Services Admins and Access list modifying without having access to the channel.Half op is enabled if you use Unreal Protocol. regards, Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From manual3000 at hotmail.com Wed May 15 13:28:10 2002 From: manual3000 at hotmail.com (MaNUaL 3000) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Remote Commands Message-ID: Well i dont think a botserv will be good. Epona services have one but consider the following..: 1. why to have this feature when it is easier to make and run an eggdrop? (no help files for the services etc etc) 2. The services in large networks with thousands of users and channels will become heavy. just consider the cpu cycles ,the ram and the hard disc space that a botserv would assign for itself. 3. if a botserv exists there should be a feature that would prevent flooding for this commands (so more cpu cycles to check for flooding in every channel). Thats only my opinion.. Thanks, MaNUaL Greece >lol, amazing answers there from Andrew.. accurate, and to the point! > >but, me and a few of my opers are working on a "BotServ" Module, which > >will allow commands like this... will keep you all informed! :) _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From VisionOfHell at aol.com Thu May 16 09:37:23 2002 From: VisionOfHell at aol.com (VisionOfHell@aol.com) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Re: Chanserv problem with .33? Message-ID: <116.11523a3b.2a153a43@aol.com> *** IceWindFire (ice@ice-inferno.network-administrator) has joined #opers *** ChanServ sets mode: +oqoq IceWindFire IceWindFire IceWindFire IceWindFire From achurch at achurch.org Fri May 17 14:41:40 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Re: Chanserv problem with .33? Message-ID: <3ce49820.32070@achurch.org> >*** IceWindFire (ice@ice-inferno.network-administrator) has joined #opers >*** ChanServ sets mode: +oqoq IceWindFire IceWindFire IceWindFire IceWindFire Does this happen with MergeChannelModes disabled? --Andrew Church achurch@achurch.org http://achurch.org/ From ghozer at mapop.com Fri May 17 04:19:49 2002 From: ghozer at mapop.com (Colin Thorpe) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] General Module Questions Message-ID: <20020517112127.B4CCA174B2@snow.fingers.co.za> Hi, I Have a few Queries about this module feature How much can be controlled from modules? EXAMPLE: If I write a module, that would allow remote commands, Such as the commnd said in the channel "!op" and it op's that user who typed it (If they are on AOP or SOP list for that channel) and !deop, for de- opping, !voice/!evoice if they are on the VOP list etc... Will this sort of control over the sevices be available from the modules? Also, we ahve the halfop capability on our IRCD, but we do not have an AHOP (like AOP, SOP and VOP) for the channels... How do we enable this? it is RaptorIRCD.1.0.4 (Latest patch) the DCC Patch Thank You. Colin ---------------------------------------------------- Ghozer AKA {SCF}|Ghozer| Clan{SCF} - #Clan{SCF} on irc.utchat.com www.scfclan.com Also irc.mapop.com - #staff #mapop #admin and #help HEad Operator IRC.MAPOP.COM Interested in linking with us? Come see me. --------------------------------------------------- From frostycoolslug at hotmail.com Fri May 17 04:40:38 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] General Module Questions Message-ID: you can get full services control from the modules... and i think u need HOP :p althought RaptorIRCD.1.0.4 isnt Supported by ircservices (from what i know..) if that feature isnt avaliable, re-conpile with Unreal support, but.. that probably wouldnt work :) >From: "Colin Thorpe" >Reply-To: ircservices-coding@ircservices.za.net >To: ircservices-coding@ircservices.za.net >Subject: [IRCServices Coding] General Module Questions >Date: Fri, 17 May 2002 07:19:49 -0400 > >Hi, I Have a few Queries about this module feature > > How much can be controlled from modules? > EXAMPLE: If I write a module, that would allow remote commands, Such as > the commnd said in the channel "!op" and it op's that user who typed it > (If they are on AOP or SOP list for that channel) and !deop, for de- > opping, !voice/!evoice if they are on the VOP list etc... > > Will this sort of control over the sevices be available from the modules? > > Also, we ahve the halfop capability on our IRCD, but we do not have an > AHOP (like AOP, SOP and VOP) for the channels... How do we enable this? > > it is RaptorIRCD.1.0.4 (Latest patch) the DCC Patch > > Thank You. > Colin > >---------------------------------------------------- >Ghozer AKA {SCF}|Ghozer| >Clan{SCF} - #Clan{SCF} on irc.utchat.com >www.scfclan.com >Also irc.mapop.com - #staff #mapop #admin and #help >HEad Operator IRC.MAPOP.COM >Interested in linking with us? Come see me. >--------------------------------------------------- > > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ 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 Thu May 16 13:22:15 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:23 2004 Subject: AW: [IRCServices Coding] Re: Chanserv problem with .33? In-Reply-To: <116.11523a3b.2a153a43@aol.com> Message-ID: <000001c1fd17$708cb7f0$02c8a8c0@nygmatech.local> Could it actually be this way ?: *** IceWindFire (ice@ice-inferno.network-administrator) has joined #opers *** IceWindFire (ice@ice-inferno.network-administrator) has left #opers *** IceWindFire (ice@ice-inferno.network-administrator) has joined #opers *** ChanServ sets mode: +oqoq IceWindFire IceWindFire IceWindFire IceWindFire And then MergeChannelModes has been set in ircservices.conf ? If this is the case, services might send the modes for both JOINs in a combined MODE line. 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 VisionOfHell@aol.com > Gesendet: Donnerstag, 16. Mai 2002 18:37 > An: ircservices-coding@ircservices.za.net > Betreff: [IRCServices Coding] Re: Chanserv problem with .33? > > > *** IceWindFire (ice@ice-inferno.network-administrator) has > joined #opers > *** ChanServ sets mode: +oqoq IceWindFire IceWindFire > IceWindFire IceWindFire > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo> /ircservices-coding > From uhc0 at rz.uni-karlsruhe.de Fri May 17 00:08:37 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:23 2004 Subject: AW: [IRCServices Coding] Re: Chanserv problem with .33? In-Reply-To: <116.11523a3b.2a153a43@aol.com> Message-ID: <000301c1fd71$bc46c190$02c8a8c0@nygmatech.local> Could it actually be this way ?: *** IceWindFire (ice@ice-inferno.network-administrator) has joined #opers *** IceWindFire (ice@ice-inferno.network-administrator) has left #opers *** IceWindFire (ice@ice-inferno.network-administrator) has joined #opers *** ChanServ sets mode: +oqoq IceWindFire IceWindFire IceWindFire IceWindFire And then MergeChannelModes has been set in ircservices.conf ? If this is the case, services might send the modes for both JOINs in a combined MODE line. Regards; yusuf PS: Sorry, if this email reaches you twice. The university mail server has problems currently. ------------------------------------------------------------------ | 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 VisionOfHell@aol.com > Gesendet: Donnerstag, 16. Mai 2002 18:37 > An: ircservices-coding@ircservices.za.net > Betreff: [IRCServices Coding] Re: Chanserv problem with .33? > > > *** IceWindFire (ice@ice-inferno.network-administrator) has > joined #opers > *** ChanServ sets mode: +oqoq IceWindFire IceWindFire > IceWindFire IceWindFire > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo> /ircservices-coding > From VisionOfHell at aol.com Fri May 17 05:44:47 2002 From: VisionOfHell at aol.com (VisionOfHell@aol.com) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Re: IRCServices-Coding digest, Vol 1 #132 - 2 msgs Message-ID: <11e.10c220e4.2a16553f@aol.com> I have no merge channels if that helps. From gizm0 at mail.gr Fri May 17 19:12:50 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Re: IRCServices-Coding digest, Vol 1 #132 - 2 msgs Message-ID: <102165197001@mailserver.mail.gr> Óôßò Fri, 17 May 2002 08:44:47 EDT VisionOfHell@aol.com Ýãñáøå: > I have no merge channels if that helps. heh.MergeChannelModes and not MergeChannel.Imagine mergening channels.heh great feature :P "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From eengin at talesoft.de Fri May 17 10:11:19 2002 From: eengin at talesoft.de (Ekim Engin) Date: Sat Oct 23 23:09:23 2004 Subject: [IRCServices Coding] Two Suggestions In-Reply-To: <000301c1fd71$bc46c190$02c8a8c0@nygmatech.local> Message-ID: <008901c1fdc5$dff14440$092a14ac@talesoft.de> Hello, Just wondering if it is (or could be) planned to add some features: 1.- cs info showing maximum (and maybe avarage) user count on the channel This feature could be used to determine the ovberall situation of a channel allowing networks with e.g. Bot policies to respond to the requests faster. Also users could compare their channels with others. 2.- ns info showing the total online time of an user. This feature is mainly used by channel foudners on our Network on decissons on adding or removing channel operators. Also it can be used to decide if a nick is used or just "hold" a nick (illegaly compare nickserv help ;-) Greets Ekim +------------------------+------------------------+ | Talesin aka Ekim Engin | ircadmin@ttnet.net.tr | | IRC Administration | http://www.ttchat.net | | TTNet Network (Turkey) | irc://irc.ttnet.net.tr | |------------------------^------------------------| | < Chat begins as it ends - without reason > | +-------------------------------------------------+ From dan at viaraix.net Fri May 17 13:50:32 2002 From: dan at viaraix.net (Dan Jones) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] nick.db - Invalid Format Message-ID: <3CE56D18.6040008@viaraix.net> [May 17 19:37:46 2002] unknown message from server (:irc.last-horizon.co.uk SETHOST Recon 1654620b.1de2983b.in-addr.btopenworld.com) [May 17 19:38:06 2002] Services terminating: Segmentation fault [May 17 20:59:28 2002] IRC Services 5.0a33 starting up [May 17 20:59:29 2002] FATAL: database/version4: Invalid format in nick.db -==== Start nick.db =====- ^RaK^c0larakwhogivesafkinshit@hotmail.comRaK@ACB5A2E6.ipt.aol.comDan2Leaving: To know the light, you must see the dark i couldn't wank in ANY class this <--- | (@Blanko) NoS Erection =============) | (@p0ma) Perhaps even --*--) this (--*-- huhu hi <+Curufinwe^tv> radon <+TV|Freak> mh??? <+TV|Freak> hab ich was mit den Augen??? [02:40] birne: wechsel deinen nick mal wieder <+TV|Freak> anscheinend bin ich voll Banane Having just upgraded to the latest alpha, it seems that the immediately send options for akill and sline no longer operate and the akills/slines are not propogated to servers allowing the users to remain connected. -- Mark. From nothing at psychopat.org Fri May 17 19:23:56 2002 From: nothing at psychopat.org (Marc-Andre A. Fuentes) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Services 5.0a33 Bug?! In-Reply-To: <21024.193.237.130.98.1021677069.squirrel@secure.uksolutions.co.uk> Message-ID: >From services.log: [May 17 22:10:50 2002] IRC Services 5.0a33 starting up [May 17 22:15:45 2002] protocol/bahamut: sjoin: SJOIN to channel #chile for non-existent nick PsYcHoPaT (1021688148 #chile +) [May 17 22:19:58 2002] nickserv/main: user record for PsYcHoPaT not found [May 17 22:20:03 2002] nickserv/main: user record for PsYcHoPaT not found [May 17 22:20:40 2002] nickserv/main: user record for wert5 not found [May 17 22:20:48 2002] nickserv/main: user record for wert5 not found >From IRC: -irc.psychopat.org- *** Routing -- from irc.psychopat.org: Link with services.psychopat.org[(+)nothing@0.0.0.0] established: ULined TS link -irc.psychopat.org- *** Notice -- Nick Collision on OperServ(services.psychopat.org(NOUSER) <- OperServ!services@psychopat.org)(TS:services.psychopat.org) -irc.psychopat.org- *** Notice -- Nick Collision on Global(services.psychopat.org(NOUSER) <- Global!services@psychopat.org)(TS:services.psychopat.org) Version: bahamut(pelennor)-1.4(08). irc.psychopat.org CHiI TS3ow-r[RELEASE] parameters wrongs ?! From beng at nc.rr.com Fri May 17 21:57:05 2002 From: beng at nc.rr.com (Ben Goldstein) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Cosmetic in modules.conf Message-ID: <009b01c1fe28$7c5cd490$0300000a@asi200> # EnableExclude [OPTIONAL] # Causes autokill exclusions to be usable. If not given, the # EXCLUDE command will be unavailable, and any autokill # exclusions previously added will be ignored. # # NOTICE: On IRC servers without autokill exclusion functionality # (such as that in trircd version 5), this will cause ... as you were saying? -- Ben Goldstein (beng@nc.rr.com) From beng at nc.rr.com Fri May 17 22:23:15 2002 From: beng at nc.rr.com (Ben Goldstein) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] 5.0a33 Message-ID: <00ab01c1fe2c$b8ff9be0$0300000a@asi200> 0) The FreeBSD smtp socket issue.. [May 18 01:26:28.858924 2002] mail/smtp: SMTP(0x8163a00) received: 220-mail4.nc.rr.com Microsoft SMTP MAIL ready at Sat, 18 May 2002 01:17:14 -0400 Version: 5.5.1877.757.75 [May 18 01:26:28.859473 2002] mail/smtp: SMTP(0x8163a00) received: 220 ESMTP spoken here [May 18 01:26:28.860008 2002] debug: Top of main loop And thats where it sits. Progress, yes! But not quite done. 1) Upon registering a nickname that has not been completly AUTH'd, your email address shows up in a /ns INFO report. At this point, you cannot set HIDE email on. Possibly a privacy issue. 2) I would have a "NSIsOp", "CSIsOp" etc. to say whether or not you want services' pseudo-clients to have the +o flag after registration. Maybe I'm just nitpicking, i'd rather not see robots in /who 0 o. -- Ben Goldstein (beng@nc.rr.com) From manual3000 at hotmail.com Sat May 18 02:36:55 2002 From: manual3000 at hotmail.com (MaNUaL 3000) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Two Suggestions Message-ID: 1. dont know about that. what if 100 bot clones attack the channel? that would be a fake result then. 2. not a good idea. what if they leave a screen 24h a day but not online? that would be a fake result too. So not a good idea. Also big channels use bots for this.. they keep statistics to count users and online time for users.. MaNUaL. >Hello, > >Just wondering if it is (or could be) planned to add some features: > >1.- cs info showing maximum (and maybe avarage) user count on the >channel > >This feature could be used to determine the ovberall situation of a >channel allowing networks with e.g. Bot policies to respond to the >requests faster. Also users could compare their channels with others. > >2.- ns info showing the total online time of an user. > >This feature is mainly used by channel foudners on our Network on >decissons on adding or removing channel operators. Also it can be used >to decide if a nick is used or just "hold" a nick (illegaly compare >nickserv help ;-) > >Greets Ekim > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From uhc0 at rz.uni-karlsruhe.de Sat May 18 02:38:33 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:24 2004 Subject: AW: [IRCServices Coding] Services 5.0a33 Bug?! In-Reply-To: Message-ID: <000101c1fe4f$d8e6f250$02c8a8c0@nygmatech.local> Please try to use actual irc servers. Bahamut 1.4.08 is ANCIENT. And it is well documented, that only Bahamut 1.4.25 and above will be supported. The version you are using does not have NICKIP capability. Services requires NICKIP capability. Additionally, Bahamut 1.4.33 is already released, so please upgrade your software. 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 Marc-Andre A. Fuentes > Gesendet: Samstag, 18. Mai 2002 04:24 > An: ircservices-coding@ircservices.za.net > Betreff: Re: [IRCServices Coding] Services 5.0a33 Bug?! > > > From services.log: > > [May 17 22:10:50 2002] IRC Services 5.0a33 starting up > [May 17 22:15:45 2002] protocol/bahamut: sjoin: SJOIN to > channel #chile for non-existent nick PsYcHoPaT (1021688148 #chile +) > [May 17 22:19:58 2002] nickserv/main: user record for > PsYcHoPaT not found > [May 17 22:20:03 2002] nickserv/main: user record for > PsYcHoPaT not found > [May 17 22:20:40 2002] nickserv/main: user record for wert5 not found > [May 17 22:20:48 2002] nickserv/main: user record for wert5 not found > > > From IRC: > -irc.psychopat.org- *** Routing -- from irc.psychopat.org: Link > with services.psychopat.org[(+)nothing@0.0.0.0] established: ULined TS > link > -irc.psychopat.org- *** Notice -- Nick Collision on > OperServ(services.psychopat.org(NOUSER) <- > OperServ!services@psychopat.org)(TS:services.psychopat.org) > -irc.psychopat.org- *** Notice -- Nick Collision on > Global(services.psychopat.org(NOUSER) <- > Global!services@psychopat.org)(TS:services.psychopat.org) > > > Version: > bahamut(pelennor)-1.4(08). irc.psychopat.org CHiI TS3ow-r[RELEASE] > > > parameters wrongs ?! > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From manual3000 at hotmail.com Sat May 18 03:23:49 2002 From: manual3000 at hotmail.com (MaNUaL 3000) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Services 5.0a33 Immediately send akill/sline fails Message-ID: As i remeber when you add an akill or slines in new services, users remain connected. That's for security reasons.. ie. if you add an akill to *@* ,which is lame, then imagine all the users to get killed. So the akill or sline works if the user tries to reconnect. So all you have after you aply the akill is to kill kill the user and he cant get in again. (correct me if i am worng) > >Having just upgraded to the latest alpha, it seems that the immediately >send options for akill and sline no longer operate and the akills/slines >are not propogated to servers allowing the users to remain connected. > >-- >Mark. > > > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From gizm0 at mail.gr Sat May 18 14:39:50 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Two Suggestions Message-ID: <102172199001@mailserver.mail.gr> Óôßò Fri, 17 May 2002 19:11:19 +0200 "Ekim Engin" Ýãñáøå: > Hello, > > Just wondering if it is (or could be) planned to add some features: > > 1.- cs info showing maximum (and maybe avarage) user count on the > channel > this already exists with /chanserv access #channel count. "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From chris at monkeyircd.org Sat May 18 04:08:50 2002 From: chris at monkeyircd.org (Chris Plant) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] General Module Questions In-Reply-To: <20020517112127.B4CCA174B2@snow.fingers.co.za> References: <20020517112127.B4CCA174B2@snow.fingers.co.za> Message-ID: <1021720131.11362.0.camel@fry.111balmoral.co.uk> On Fri, 2002-05-17 at 12:19, Colin Thorpe wrote: > Hi, I Have a few Queries about this module feature > > How much can be controlled from modules? > EXAMPLE: If I write a module, that would allow remote commands, Such as > the commnd said in the channel "!op" and it op's that user who typed it > (If they are on AOP or SOP list for that channel) and !deop, for de- > opping, !voice/!evoice if they are on the VOP list etc... > > Will this sort of control over the sevices be available from the modules? > > Also, we ahve the halfop capability on our IRCD, but we do not have an > AHOP (like AOP, SOP and VOP) for the channels... How do we enable this?I had the same with MonkeyIRCD, I just wrote a new protocol module [based heavily on Bahamut] for monkeyircd > > it is RaptorIRCD.1.0.4 (Latest patch) the DCC Patch > > Thank You. > Colin > > ---------------------------------------------------- > Ghozer AKA {SCF}|Ghozer| > Clan{SCF} - #Clan{SCF} on irc.utchat.com > www.scfclan.com > Also irc.mapop.com - #staff #mapop #admin and #help > HEad Operator IRC.MAPOP.COM > Interested in linking with us? Come see me. > --------------------------------------------------- > > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From mort at icenet.org.za Sat May 18 05:11:33 2002 From: mort at icenet.org.za (Mortalica) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Two Suggestions References: <102172199001@mailserver.mail.gr> Message-ID: <000b01c1fe65$274f3960$86160ec4@poseidon> > this already exists with /chanserv access #channel count. But that just tells you how many people there are on the access list, not the max user count for the channel, afaik. m. ----- Original Message ----- From: "Panagiotis Kefalidis ( Gizm0 )" To: Sent: Saturday, May 18, 2002 4:39 PM Subject: Re: [IRCServices Coding] Two Suggestions > ???? Fri, 17 May 2002 19:11:19 +0200 "Ekim Engin" ??????: > > > Hello, > > > > Just wondering if it is (or could be) planned to add some features: > > > > 1.- cs info showing maximum (and maybe avarage) user count on the > > channel > > > this already exists with /chanserv access #channel count. > > "I can see the darkness in your eyes." > Gizm0.- > > ------------------------------------------------------------- > http://www.mail.gr/ - Get Your Private Free Email Address! > http://www.ringtone.gr/ - Ringtones & Logos for your mobile! > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > > From gizm0 at mail.gr Sat May 18 14:52:36 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Services 5.0a33 Bug?! Message-ID: <102172275602@mailserver.mail.gr> Óôßò Fri, 17 May 2002 22:23:56 -0400 (EDT) "Marc-Andre A. Fuentes" Ýãñáøå: > From services.log: > > [May 17 22:10:50 2002] IRC Services 5.0a33 starting up > [May 17 22:15:45 2002] protocol/bahamut: sjoin: SJOIN to channel > #chile for non-existent nick PsYcHoPaT (1021688148 #chile +) > [May 17 22:19:58 2002] nickserv/main: user record for PsYcHoPaT not found > [May 17 22:20:03 2002] nickserv/main: user record for PsYcHoPaT not found > [May 17 22:20:40 2002] nickserv/main: user record for wert5 not found > [May 17 22:20:48 2002] nickserv/main: user record for wert5 not found > > > From IRC: > -irc.psychopat.org- *** Routing -- from irc.psychopat.org: Link > with services.psychopat.org[(+)nothing@0.0.0.0] established: ULined TS > link > -irc.psychopat.org- *** Notice -- Nick Collision on > OperServ(services.psychopat.org(NOUSER) <- > OperServ!services@psychopat.org)(TS:services.psychopat.org) > -irc.psychopat.org- *** Notice -- Nick Collision on > Global(services.psychopat.org(NOUSER) <- > Global!services@psychopat.org)(TS:services.psychopat.org) > > > Version: > bahamut(pelennor)-1.4(08). irc.psychopat.org CHiI TS3ow-r[RELEASE] > > > parameters wrongs ?! > add a q:line to all services nicknames to avoid such phainomenon. "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From gizm0 at mail.gr Sat May 18 14:59:37 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Two Suggestions Message-ID: <102172317701@mailserver.mail.gr> Óôßò Sat, 18 May 2002 14:39:50 EEST Panagiotis Kefalidis Ýãñáøå: > Óôßò Fri, 17 May 2002 19:11:19 +0200 "Ekim Engin" Ýãñáøå: > > > Hello, > > > > Just wondering if it is (or could be) planned to add some features: > > > > 1.- cs info showing maximum (and maybe avarage) user count on the > > channel > > > this already exists with /chanserv access #channel count. sorry but this is for access list entries count and not for the current number of users in the channel. "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From uhc0 at rz.uni-karlsruhe.de Sat May 18 06:40:12 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:24 2004 Subject: AW: [IRCServices Coding] Services 5.0a33 Bug?! In-Reply-To: <102172275602@mailserver.mail.gr> Message-ID: <000201c1fe71$9af54790$02c8a8c0@nygmatech.local> Just to correct you, the case described does not have anything to do with qlines, since services users do not get killed because of collisions, but because of bad NICK lines, since the server does not understand what services is sending. As I stated before, the cause is the old version of bahamut, the solution lies in installing the new 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 Panagiotis Kefalidis ( Gizm0 ) > Gesendet: Samstag, 18. Mai 2002 16:53 > An: ircservices-coding@ircservices.za.net > Betreff: Re: [IRCServices Coding] Services 5.0a33 Bug?! > > > ???? Fri, 17 May 2002 22:23:56 -0400 (EDT) "Marc-Andre A. > Fuentes" ??????: > > > From services.log: > > > > [May 17 22:10:50 2002] IRC Services 5.0a33 starting up > > [May 17 22:15:45 2002] protocol/bahamut: sjoin: SJOIN to channel > > #chile for non-existent nick PsYcHoPaT (1021688148 #chile > +) [May 17 > > 22:19:58 2002] nickserv/main: user record for PsYcHoPaT not > found [May > > 17 22:20:03 2002] nickserv/main: user record for PsYcHoPaT > not found > > [May 17 22:20:40 2002] nickserv/main: user record for wert5 > not found > > [May 17 22:20:48 2002] nickserv/main: user record for wert5 > not found > > > > > > From IRC: > > -irc.psychopat.org- *** Routing -- from irc.psychopat.org: > Link with > > services.psychopat.org[(+)nothing@0.0.0.0] established: > ULined TS link > > -irc.psychopat.org- *** Notice -- Nick Collision on > > OperServ(services.psychopat.org(NOUSER) <- > > OperServ!services@psychopat.org)(TS:services.psychopat.org) > > -irc.psychopat.org- *** Notice -- Nick Collision on > > Global(services.psychopat.org(NOUSER) <- > > Global!services@psychopat.org)(TS:services.psychopat.org) > > > > > > Version: > > bahamut(pelennor)-1.4(08). irc.psychopat.org CHiI TS3ow-r[RELEASE] > > > > > > parameters wrongs ?! > > > add a q:line to all services nicknames to avoid such phainomenon. > > > > "I can see the darkness in your eyes." > Gizm0.- > > ------------------------------------------------------------- > http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! ------------------------------------------------------------------ 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 May 18 06:54:12 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:24 2004 Subject: AW: [IRCServices Coding] 5.0a33 In-Reply-To: <00ab01c1fe2c$b8ff9be0$0300000a@asi200> Message-ID: <000001c1fe73$8faa4780$02c8a8c0@nygmatech.local> Hello; Hi, > 1) Upon registering a nickname that has not been completly > AUTH'd, your > email address shows up in a /ns INFO report. At this point, > you cannot set > HIDE email on. Possibly a privacy issue. In the example-modules.conf you will see: # NSDef... [OPTIONAL] # Sets the default options for newly registered nicks. Note that # changing these options will have no effect on nicks which are # already registered. Options not listed here will be unset on new # nicks. # # If both NSDefKill and NSDefKillQuick are given, NSDefKillQuick # takes precedence. KILL IMMED cannot be specified as a default. #NSDefKill #NSDefKillQuick NSDefSecure #NSDefPrivate #NSDefHideEmail #NSDefHideUsermask #NSDefHideQuit NSDefMemoSignon Where you can set NSDefHideEmail, and newly registered nicknames will have hidden email addresses. So your case does not really exist, and there is no privacy issue with it ;-) > 2) I would have a "NSIsOp", "CSIsOp" etc. to say whether or > not you want > services' pseudo-clients to have the +o flag after > registration. Maybe I'm > just nitpicking, i'd rather not see robots in /who 0 o. Question: After which registration ? Information: Some commands services clients generate, can get rejected by the server, if these do not have operator flags. Example: If OperServ were not +o, you could not KILL noone. This does not necessarily apply to U:Line capable servers, though. Regards; yusuf From achurch at achurch.org Sat May 18 23:35:35 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] 5.0a33 Message-ID: <3ce66a3a.41131@achurch.org> >0) The FreeBSD smtp socket issue.. >[May 18 01:26:28.858924 2002] mail/smtp: SMTP(0x8163a00) received: >220-mail4.nc.rr.com Microsoft SMTP MAIL ready at Sat, 18 May 2002 >01:17:14 -0400 Version: 5.5.1877.757.75 >[May 18 01:26:28.859473 2002] mail/smtp: SMTP(0x8163a00) received: 220 ESMTP >spoken here >[May 18 01:26:28.860008 2002] debug: Top of main loop > >And thats where it sits. Progress, yes! But not quite done. Can you try and trace through the smtp_readline() routine in modules/mail/smtp.c (run Services with -nofork from gdb, set a breakpoint at smtp_readline after the modules are loaded) and see what happens with that second line? I can't see any reason it wouldn't proceed. >1) Upon registering a nickname that has not been completly AUTH'd, your >email address shows up in a /ns INFO report. At this point, you cannot set >HIDE email on. Possibly a privacy issue. As mentioned, you can avoid this with NSDefHideEmail, but since the address may be invalid anyway, not showing it is probably the better option. >2) I would have a "NSIsOp", "CSIsOp" etc. to say whether or not you want >services' pseudo-clients to have the +o flag after registration. Maybe I'm >just nitpicking, i'd rather not see robots in /who 0 o. Again as mentioned, the pseudoclients are +o because they have to be. Some protocols may not require this, but it would take a lot of testing to make sure of that, and it's not all that big a deal in the first place, so I'm going to leave this as is for 5.0. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Sat May 18 23:50:41 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Two Suggestions Message-ID: <3ce66a5d.41140@achurch.org> These are both among features I'm considering for a future version, but they won't be included in 5.0. --Andrew Church achurch@achurch.org http://achurch.org/ >Hello, > >Just wondering if it is (or could be) planned to add some features: > >1.- cs info showing maximum (and maybe avarage) user count on the >channel > >This feature could be used to determine the ovberall situation of a >channel allowing networks with e.g. Bot policies to respond to the >requests faster. Also users could compare their channels with others. > >2.- ns info showing the total online time of an user. > >This feature is mainly used by channel foudners on our Network on >decissons on adding or removing channel operators. Also it can be used >to decide if a nick is used or just "hold" a nick (illegaly compare >nickserv help ;-) > >Greets Ekim > >+------------------------+------------------------+ >| Talesin aka Ekim Engin | ircadmin@ttnet.net.tr | >| IRC Administration | http://www.ttchat.net | >| TTNet Network (Turkey) | irc://irc.ttnet.net.tr | >|------------------------^------------------------| >| < 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 achurch at achurch.org Sat May 18 23:51:51 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] nick.db - Invalid Format Message-ID: <3ce66aca.41156@achurch.org> >[May 17 19:37:46 2002] unknown message from server >(:irc.last-horizon.co.uk SETHOST Recon >1654620b.1de2983b.in-addr.btopenworld.com) This looks like you're using the wrong protocol module. Try using the right protocol modules, deleting your database files and starting over. >-==== Start nick.db =====- Good Lord, don't send the thing in binary as is, and for crying out loud DON'T post it on the mailing list! --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Sat May 18 23:53:05 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Services 5.0a33 Immediately send akill/sline fails Message-ID: <3ce66ba9.41762@achurch.org> >Having just upgraded to the latest alpha, it seems that the immediately >send options for akill and sline no longer operate and the akills/slines >are not propogated to servers allowing the users to remain connected. Works fine for me: [May 18 23:54:24.918461 2002] operserv/main: Alcan: akill add *@test.test test [May 18 23:54:24.918820 2002] debug: Sent: :OperServ GLOBOPS :Alcan added an AKILL for *@test.test (expires in 30 days) [May 18 23:54:24.919087 2002] debug: Sent: :services.localhost.net TKL + G * test.test Alcan 1024325664 1021733664 :Autokilled: test As mentioned, ImmediatelySend{Autokill,Sline} have never killed currently-connected users, only sent the appropriate commands to prevent new connections. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Sat May 18 23:58:54 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Cosmetic in modules.conf Message-ID: <3ce66ccf.42007@achurch.org> > # EnableExclude [OPTIONAL] > # Causes autokill exclusions to be usable. If not given, the > # EXCLUDE command will be unavailable, and any autokill > # exclusions previously added will be ignored. > # > # NOTICE: On IRC servers without autokill exclusion functionality > # (such as that in trircd version 5), this will cause > >... as you were saying? Oops, fixed. (: It's supposed to say that autokills won't be sent to the server anymore, and Services will instead send KILLs as needed. --Andrew Church achurch@achurch.org http://achurch.org/ From brtb at unirc.net Sat May 18 10:28:42 2002 From: brtb at unirc.net (Brendan Bowden) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] nick.db - Invalid Format References: <3CE56D18.6040008@viaraix.net> Message-ID: <3CE68F4A.2080602@unirc.net> I'm getting the same kind of thing using bahamut-1.4.33 and ircserv-a33... seemingly random segfaults followed by a corrupted nick.db. Any hints on how I can get this bug tracked down? Oh, and the operserv supass isn't getting saved between services restarts; is this by design or a bug? Dan Jones wrote: > [May 17 19:37:46 2002] unknown message from server > (:irc.last-horizon.co.uk SETHOST Recon > 1654620b.1de2983b.in-addr.btopenworld.com) > [May 17 19:38:06 2002] Services terminating: Segmentation fault > [May 17 20:59:28 2002] IRC Services 5.0a33 starting up > [May 17 20:59:29 2002] FATAL: database/version4: Invalid format in > nick.db > > > -==== Start nick.db =====- > > [cut for sake of sanity] > > -===== end nick.db =====- > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From rg at tcslon.com Sat May 18 10:58:28 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] nick.db - Invalid Format In-Reply-To: <3CE68F4A.2080602@unirc.net> References: <3CE56D18.6040008@viaraix.net> <3CE68F4A.2080602@unirc.net> Message-ID: <1021744714.7830.10.camel@russell.gui.tcslon.com.> On Sat, 2002-05-18 at 18:28, Brendan Bowden wrote: > I'm getting the same kind of thing using bahamut-1.4.33 and > ircserv-a33... seemingly random segfaults followed by a corrupted > nick.db. Any hints on how I can get this bug tracked down? Recompile services with the -dumpcore option passed to configure (if it isn't already - can we have this enabled by default in the alpha/beta?), then wait for services to segfault and you should have a core file in the same directory as the ircservices executable. Feed it into gdb like this: gdb /path/to/ircservices /path/to/core gdb will spew out lots of rubbish, followed by a (gdb) prompt - type 'bt', then grab the resulting trace and post it to the list. Russ Garrett (russ@garrett.co.uk) From mark at ctcp.net Sun May 19 10:15:24 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Odd problems with Services 5.0a33 Message-ID: <1217.193.237.130.98.1021828524.squirrel@secure.uksolutions.co.uk> As other people have posted, I seem to also have the seemingly random segfault followed by corrupted nickname database problem (Services is linked to Unreal). AFAICT nothing has happened nor any messages issued to services to trigger this so I assume it is during one of Services timed updates: [ircservices.log] Services terminating: Segmentation fault [ircservices.log] IRC Services 5.0a33 starting up [ircservices.log] FATAL: database/version4: Invalid format in nick.db Another seemingly random problem that I have seen once or twice in the past but almost every time I start services with this latest alpha is: [ircservices.log] IRC Services 5.0a33 starting up [ircservices.log] sockets: [v]sockprintf() with NULL socket! [ircservices.log] sockets: [v]sockprintf() with NULL socket! [ircservices.log] sockets: [v]sockprintf() with NULL socket! [ircservices.log] sockets: [v]sockprintf() with NULL socket! [ircservices.log] sockets: [v]sockprintf() with NULL socket! [ircservices.log] sockets: [v]sockprintf() with NULL socket! [ircservices.log] sockets: [v]sockprintf() with NULL socket! The number of socket errors varies from none to several. While going through the logs since the upgrade and looking for possible causes, I came across the following during one startup: [ircservices.log] nickserv/main: Expiring nickname jcat-buffy [ircservices.log] database/version4: Extension data found for nonexisting nick `jcat-buffy' I guess this means that expiring of nicknames is not correctly cleaning up extension data. I am not sure what services will do with this now redundant extension data so maybe the message could be changed to include what has been done about it. E.g. "database/version4: Deleting extension data found for nonexisting nick `jcat-buffy'". I will be playing around with various things to try and get more info on the problems, but wanted to report them ASAP in case there is something obvious that could be causing them. -- Mark. From master at xchat.gr Sun May 19 14:49:27 2002 From: master at xchat.gr (George Stamatiou) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] GHOST command Services 5.0a33 References: <1217.193.237.130.98.1021828524.squirrel@secure.uksolutions.co.uk> Message-ID: <000a01c1ff7f$0eefa380$d083fea9@218> hmmm... it doesn't look that the command /ns ghost nick pass works. it doesn't kill the user.i have bahamut 1.4(31). i don't know if somebody else has that problem or has a problem with the command /cs secureops on.it doesn't deop the user if set From frostycoolslug at hotmail.com Sun May 19 14:57:28 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Mode Merging Message-ID: is it possible for merge modes to Prioritise? a mean.. instead of.. *** You Have joined Channel #test *WAIT 3 SECS*.. Change topic mess around.. *** Chanserv sets mode +tnr-o Craig it goes... *** You Have joined Channel #test *** Chanserv sets mode -o Craig *WAIT 3 SECS*.. cant do nething bad.. *** Chanserv sets mode +tnr it just means there isnt a massive security hole there ;) -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From uhc0 at rz.uni-karlsruhe.de Sun May 19 15:14:11 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:24 2004 Subject: AW: [IRCServices Coding] Mode Merging In-Reply-To: Message-ID: <000001c1ff82$93762770$02c8a8c0@nygmatech.local> Hello; just to make a little advertisement about the coming release of tr-ircd, I'd say, that this problem can as well be solved by the ircd itself. TR-IRCD 5.x series servers introduce a new channelmode, +T, which is similar to +t, but requires protect (+a) privileges for /topic, and can only be set by oper or higher (like +O) The ircd sets any empty channel +Tn on JOIN, regardless of what services might then do. So the user will not be able to change the topic, since they cannot become +a on JOIN. After the mergechannelmodes time, ChanServ either may +a the user, or deop them, or set the channel -T, or leave it. In either case you will have no user who can /topic the way they want. :-) Best 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, 19. Mai 2002 23:57 > An: ircservices-coding@ircservices.za.net > Betreff: [IRCServices Coding] Mode Merging > > > is it possible for merge modes to Prioritise? > a mean.. instead of.. > *** You Have joined Channel #test > *WAIT 3 SECS*.. Change topic mess around.. > *** Chanserv sets mode +tnr-o Craig > > it goes... > *** You Have joined Channel #test > *** Chanserv sets mode -o Craig > *WAIT 3 SECS*.. cant do nething bad.. > *** Chanserv sets mode +tnr > > it just means there isnt a massive security hole there ;) > > -- > Craig McLure > Craig@chatspike.net > Network Administrator of the ChatSpike IRC Network. > ChatSpike, the users network! www.chatspike.net > > > _________________________________________________________________ > 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 griever at t2n.org Sun May 19 15:22:16 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Mode Merging In-Reply-To: Message-ID: On Sun, 19 May 2002, Craig McLure wrote: > is it possible for merge modes to Prioritise? > a mean.. instead of.. > *** You Have joined Channel #test > *WAIT 3 SECS*.. Change topic mess around.. > *** Chanserv sets mode +tnr-o Craig > > it goes... > *** You Have joined Channel #test > *** Chanserv sets mode -o Craig > *WAIT 3 SECS*.. cant do nething bad.. > *** Chanserv sets mode +tnr > > it just means there isnt a massive security hole there ;) > This is why you don't set it to 3 secs, you set it to .5 secs :P From frostycoolslug at hotmail.com Sun May 19 15:26:48 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Mode Merging Message-ID: i tried that.. still took a good 2secs to gather the modes ;) >From: Finny Merrill >Reply-To: ircservices-coding@ircservices.za.net >To: ircservices-coding@ircservices.za.net >Subject: Re: [IRCServices Coding] Mode Merging >Date: Sun, 19 May 2002 16:22:16 -0600 (CST) > >On Sun, 19 May 2002, Craig McLure wrote: > > > is it possible for merge modes to Prioritise? > > a mean.. instead of.. > > *** You Have joined Channel #test > > *WAIT 3 SECS*.. Change topic mess around.. > > *** Chanserv sets mode +tnr-o Craig > > > > it goes... > > *** You Have joined Channel #test > > *** Chanserv sets mode -o Craig > > *WAIT 3 SECS*.. cant do nething bad.. > > *** Chanserv sets mode +tnr > > > > it just means there isnt a massive security hole there ;) > > > >This is why you don't set it to 3 secs, you set it to .5 secs :P > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From gizm0 at mail.gr Mon May 20 09:39:43 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Odd problems with Services 5.0a33 Message-ID: <102187678401@mailserver.mail.gr> Óôßò Sun, 19 May 2002 18:15:24 +0100 (BST) "Mark Hetherington" Ýãñáøå: > As other people have posted, I seem to also have the seemingly random > segfault followed by corrupted nickname database problem (Services is > linked to Unreal). AFAICT nothing has happened nor any messages issued to > services to trigger this so I assume it is during one of Services timed > updates: > > [ircservices.log] Services terminating: Segmentation fault > [ircservices.log] IRC Services 5.0a33 starting up > [ircservices.log] FATAL: database/version4: Invalid format in nick.db > > Another seemingly random problem that I have seen once or twice in > the past > but almost every time I start services with this latest alpha is: > > [ircservices.log] IRC Services 5.0a33 starting up > [ircservices.log] sockets: [v]sockprintf() with NULL socket! > [ircservices.log] sockets: [v]sockprintf() with NULL socket! > [ircservices.log] sockets: [v]sockprintf() with NULL socket! > [ircservices.log] sockets: [v]sockprintf() with NULL socket! > [ircservices.log] sockets: [v]sockprintf() with NULL socket! > [ircservices.log] sockets: [v]sockprintf() with NULL socket! > [ircservices.log] sockets: [v]sockprintf() with NULL socket! > > The number of socket errors varies from none to several. > > While going through the logs since the upgrade and looking for possible > causes, I came across the following during one startup: > > [ircservices.log] nickserv/main: Expiring nickname jcat-buffy > [ircservices.log] database/version4: Extension data found for nonexisting > nick `jcat-buffy' I've report it also but church has answered in a very ironic way coz i haven't updated the version.h to log as "Starting IRCServices a33 "and not "Starting IRCServices a29". :) "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From gizm0 at mail.gr Mon May 20 09:41:00 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] GHOST command Services 5.0a33 Message-ID: <102187686101@mailserver.mail.gr> Óôßò Mon, 20 May 2002 00:49:27 +0300 "George Stamatiou" Ýãñáøå: > hmmm... it doesn't look that the command /ns ghost nick pass works. > it doesn't kill the user.i have bahamut 1.4(31). > i don't know if somebody else has that problem or has a problem with the > command /cs secureops on.it doesn't deop the user if set > Update to latest alpha.In mine services both features work excellent. "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From achurch at achurch.org Tue May 21 15:07:21 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Odd problems with Services 5.0a33 Message-ID: <3ce9e437.66372@achurch.org> >I've report it also but church has answered in a very ironic way coz i >haven't updated the version.h to log as "Starting IRCServices a33 "and >not "Starting IRCServices a29". :) If you're modifying Services yourself you're not helping testing at all and I have no intention of helping you either. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue May 21 15:08:43 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Mode Merging Message-ID: <3ce9e55e.66407@achurch.org> This is documented in the configuration file, and the option is off by default, so I don't see a problem with this. If it troubles you, by all means, turn it off. Services will still collect mode changes for a single command (e.g. first user joining a channel, or multiple users in an SJOIN). Additionally, even with MergeChannelModes, Services will reverse any mode changes made by users who have a deop pending. It won't do that for the topic, but there's always SET TOPICLOCK ON if that becomes a problem and you don't want to disable MergeChannelModes. --Andrew Church achurch@achurch.org http://achurch.org/ >is it possible for merge modes to Prioritise? >a mean.. instead of.. >*** You Have joined Channel #test >*WAIT 3 SECS*.. Change topic mess around.. >*** Chanserv sets mode +tnr-o Craig > >it goes... >*** You Have joined Channel #test >*** Chanserv sets mode -o Craig >*WAIT 3 SECS*.. cant do nething bad.. >*** Chanserv sets mode +tnr > >it just means there isnt a massive security hole there ;) > >-- >Craig McLure >Craig@chatspike.net >Network Administrator of the ChatSpike IRC Network. >ChatSpike, the users network! www.chatspike.net > > >_________________________________________________________________ >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 gizm0 at mail.gr Tue May 21 10:25:34 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Odd problems with Services 5.0a33 Message-ID: <102196593401@mailserver.mail.gr> Óôßò Tue, 21 May 2002 15:07:21 JST achurch@achurch.org Ýãñáøå: > >I've report it also but church has answered in a very ironic way coz i > >haven't updated the version.h to log as "Starting IRCServices a33 "and > >not "Starting IRCServices a29". :) > > If you're modifying Services yourself you're not helping testing at > all and I have no intention of helping you either. > just to inform you ,i've deleted my "modified services" and compiled the a33 release.i got the same message again,meaning that there IS a problem.this happens right after a nick expires or after 30 min when the next nick expiration check is being done by the services. "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From brtb at unirc.net Tue May 21 12:20:09 2002 From: brtb at unirc.net (Brendan Bowden) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Odd problems with Services 5.0a33 References: <102196593401@mailserver.mail.gr> Message-ID: <3CEA9DE9.6040808@unirc.net> Aha... caught one. Services crashed while updating the nick.db; file size after crash is 8192 bytes, nick.db.save is 43429. ---------------------------------------------------------------- last few lines from services.log: [May 21 10:32:41 2002] nickserv/main: brtb_!brtb@10.0.0.10 identified for nick brtb_ [May 21 10:33:10 2002] nickserv/main: Expiring nickname ^MrMike^ [May 21 10:33:10 2002] nickserv/main: Expiring nickname DanielKurland [May 21 10:33:10 2002] nickserv/main: Expiring nickname LS1 [May 21 10:33:10 2002] nickserv/main: Expiring nickname Mark [May 21 10:33:10 2002] nickserv/main: Expiring nickname Zell [May 21 10:33:47 2002] database/version4: Opening database file nick.db for write: Backup file nick.db.save exists, aborting [May 21 10:34:29 2002] httpd/main: Accepted connection from 65.35.21.113:64812 [May 21 11:32:13 2002] chanserv/main: Channel #MCPA registered by andor!~andor@h02206f0389e7.ne.client2.attbi.com [May 21 12:10:12 2002] nickserv/main: Pikachu!dustin@lion.escaped.net identified for nick Pikachu [May 21 12:42:53 2002] nickserv/main: Shiloh!shiloh@216-53-218-159.ppp.mpinet.net identified for nick Shiloh [May 21 13:05:05 2002] nickserv/main: Android_37!kylejava@AC9389F8.ipt.aol.com identified for nick Android_37 [May 21 13:11:25 2002] nickserv/main: Shiloh!shiloh@216-53-218-050.ppp.mpinet.net identified for nick Shiloh [May 21 13:11:26 2002] nickserv/main: Shiloh!shiloh@216-53-218-050.ppp.mpinet.net identified for nick Shiloh [May 21 13:47:48 2002] nickserv/main: Jordan!~javalite@45.102.73.24.cfl.rr.com identified for nick Jordan [May 21 14:27:24 2002] nickserv/main: Meson!Meson@ny-lasalle1b-77.buf.adelphia.net identified for nick Meson ---------------------------------------------------------------- the gdb trace: ---------------------------------------------------------------- GNU gdb 5.0 [gpl stuff] This GDB was configured as "i386-slackware-linux"... Core was generated by `./ircservices'. Program terminated with signal 11, Segmentation fault. [lots of "Loading symbols" lines] #0 0x40157dba in check_expire_nick (ni=0x8136510) at util.c:149 (gdb) bt #0 0x40157dba in check_expire_nick (ni=0x8136510) at util.c:149 #1 0x4011cf7d in next_nickinfo () at version4.c:113 #2 0x4011e655 in default_tzdir.129 () at version4.c:646 #3 0x40152bb0 in do_save_data () at main.c:210 #4 0x805496c in call_callback_5 (module=0x0, id=2, arg1=0x0, arg2=0x0, arg3=0x0, arg4=0x0, arg5=0x0) at modules.c:632 #5 0x8052526 in main (ac=1, av=0xbffffc04, envp=0xbffffc0c) at main.c:222 #6 0x400359cb in key () from /lib/libc.so.6 (gdb) quit ---------------------------------------------------------------- From mark at ctcp.net Tue May 21 15:59:19 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Bug - Any user can issue /cs topic #chan text Message-ID: <1515.193.237.130.98.1022021959.squirrel@secure.uksolutions.co.uk> Services 5.0a33 IRCD Unreal All users seem to be able to isses the command /cs topic #chan text and it take effect regardless of their access level (or lack of one) in an access list. For example, one user not on an access list managed to change a channel topic with /cs topic /chan newtext, while another user with a negative level (-200) or something also managed to change the topic in this way. All affected channels have been set +t (only ops can change topics) and are usually topiclock on. -- Mark. From achurch at achurch.org Wed May 22 13:29:08 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Odd problems with Services 5.0a33 Message-ID: <3ceb1ed5.67325@achurch.org> Do you still have the core file from this crash? If so, can you send me (privately) that core file along with your ircservices executable and modules directory? --Andrew Church achurch@achurch.org http://achurch.org/ >Aha... caught one. Services crashed while updating the nick.db; file >size after crash is 8192 bytes, nick.db.save is 43429. > >---------------------------------------------------------------- > >last few lines from services.log: > >[May 21 10:32:41 2002] nickserv/main: brtb_!brtb@10.0.0.10 identified >for nick brtb_ >[May 21 10:33:10 2002] nickserv/main: Expiring nickname ^MrMike^ >[May 21 10:33:10 2002] nickserv/main: Expiring nickname DanielKurland >[May 21 10:33:10 2002] nickserv/main: Expiring nickname LS1 >[May 21 10:33:10 2002] nickserv/main: Expiring nickname Mark >[May 21 10:33:10 2002] nickserv/main: Expiring nickname Zell >[May 21 10:33:47 2002] database/version4: Opening database file nick.db >for write: Backup file nick.db.save exists, aborting >[May 21 10:34:29 2002] httpd/main: Accepted connection from >65.35.21.113:64812 >[May 21 11:32:13 2002] chanserv/main: Channel #MCPA registered by >andor!~andor@h02206f0389e7.ne.client2.attbi.com >[May 21 12:10:12 2002] nickserv/main: Pikachu!dustin@lion.escaped.net >identified for nick Pikachu >[May 21 12:42:53 2002] nickserv/main: >Shiloh!shiloh@216-53-218-159.ppp.mpinet.net identified for nick Shiloh >[May 21 13:05:05 2002] nickserv/main: >Android_37!kylejava@AC9389F8.ipt.aol.com identified for nick Android_37 >[May 21 13:11:25 2002] nickserv/main: >Shiloh!shiloh@216-53-218-050.ppp.mpinet.net identified for nick Shiloh >[May 21 13:11:26 2002] nickserv/main: >Shiloh!shiloh@216-53-218-050.ppp.mpinet.net identified for nick Shiloh >[May 21 13:47:48 2002] nickserv/main: >Jordan!~javalite@45.102.73.24.cfl.rr.com identified for nick Jordan >[May 21 14:27:24 2002] nickserv/main: >Meson!Meson@ny-lasalle1b-77.buf.adelphia.net identified for nick Meson > >---------------------------------------------------------------- > > >the gdb trace: >---------------------------------------------------------------- > >GNU gdb 5.0 > >[gpl stuff] > >This GDB was configured as "i386-slackware-linux"... >Core was generated by `./ircservices'. >Program terminated with signal 11, Segmentation fault. > >[lots of "Loading symbols" lines] > >#0 0x40157dba in check_expire_nick (ni=0x8136510) at util.c:149 >(gdb) bt >#0 0x40157dba in check_expire_nick (ni=0x8136510) at util.c:149 >#1 0x4011cf7d in next_nickinfo () at version4.c:113 >#2 0x4011e655 in default_tzdir.129 () at version4.c:646 >#3 0x40152bb0 in do_save_data () at main.c:210 >#4 0x805496c in call_callback_5 (module=0x0, id=2, arg1=0x0, arg2=0x0, >arg3=0x0, arg4=0x0, > arg5=0x0) at modules.c:632 >#5 0x8052526 in main (ac=1, av=0xbffffc04, envp=0xbffffc0c) at main.c:222 >#6 0x400359cb in key () from /lib/libc.so.6 >(gdb) quit > >---------------------------------------------------------------- > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Wed May 22 13:31:25 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Bug - Any user can issue /cs topic #chan text Message-ID: <3ceb1f2f.67345@achurch.org> >Services 5.0a33 >IRCD Unreal > >All users seem to be able to isses the command /cs topic #chan text and it >take effect regardless of their access level (or lack of one) in an access >list. For example, one user not on an access list managed to change a >channel topic with /cs topic /chan newtext, while another user with a >negative level (-200) or something also managed to change the topic in this >way. Fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Wed May 22 14:23:29 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Odd problems with Services 5.0a33 Message-ID: <3ceb2c1f.70721@achurch.org> >Another seemingly random problem that I have seen once or twice in the past >but almost every time I start services with this latest alpha is: > >[ircservices.log] IRC Services 5.0a33 starting up >[ircservices.log] sockets: [v]sockprintf() with NULL socket! Can you try to determine where this is coming from? E.g., add a raise(SIGSEGV) right after that error message is logged (sockets.c:880), then do a backtrace on the core file and send me the output. >While going through the logs since the upgrade and looking for possible >causes, I came across the following during one startup: > >[ircservices.log] nickserv/main: Expiring nickname jcat-buffy >[ircservices.log] database/version4: Extension data found for nonexisting >nick `jcat-buffy' This is known and harmless. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Thu May 23 13:50:14 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Services 5.0 alpha 34 released Message-ID: <3cec7704.10712@achurch.org> Okay, here we go again with a beta release candidate. Everything reported on alpha 33 _should_ be fixed (let me know if I missed something). This version also gets rid once and for all of the problem with databases getting corrupted on crashes. Note to brtb@unirc.org: my message to you was a bit hasty, it seems-- I found the problem shortly after mailing you. Thanks for your help. Changes in version 5.0 alpha 34 ------------------------------- 2002/05/23 Fixed crash caused by trying to use forbidden nicks. Reported by 2002/05/23 Fixed spurious log warnings on forbidding in-use nicknames. 2002/05/22 Fixed bug allowing all users to use the ChanServ TOPIC command. Reported by Mark Hetherington 2002/05/17 Users are now no longer auto-joined to channels they are already in when identifying for their nick. 2002/05/15 Fixed bugs in OperServ EXCEPTION MOVE. 2002/05/15 Fixed bug causing NickServ LIST to not return any results. Reported by Romek Krisztian 2002/05/14 Services admins can now modify channel access lists without identifying for the channel. Suggested by Panagiotis Kefalidis 2002/05/14 Rewrote database saving routines to avoid data loss. --Andrew Church achurch@achurch.org http://achurch.org/ From brtb at unirc.net Wed May 22 22:44:16 2002 From: brtb at unirc.net (Brendan Bowden) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Services 5.0 alpha 34 released References: <3cec7704.10712@achurch.org> Message-ID: <3CEC81B0.7040007@unirc.net> UnIRC.net, actually... the .org one is a network of brazilian spambots and script kiddies. ;) Any word on the supass thing? Andrew Church wrote: > Okay, here we go again with a beta release candidate. Everything >reported on alpha 33 _should_ be fixed (let me know if I missed something). >This version also gets rid once and for all of the problem with databases >getting corrupted on crashes. > > Note to brtb@unirc.org: my message to you was a bit hasty, it seems-- >I found the problem shortly after mailing you. Thanks for your help. > >Changes in version 5.0 alpha 34 >------------------------------- >2002/05/23 Fixed crash caused by trying to use forbidden nicks. > Reported by >2002/05/23 Fixed spurious log warnings on forbidding in-use nicknames. >2002/05/22 Fixed bug allowing all users to use the ChanServ TOPIC > command. Reported by Mark Hetherington >2002/05/17 Users are now no longer auto-joined to channels they are > already in when identifying for their nick. >2002/05/15 Fixed bugs in OperServ EXCEPTION MOVE. >2002/05/15 Fixed bug causing NickServ LIST to not return any results. > Reported by Romek Krisztian >2002/05/14 Services admins can now modify channel access lists without > identifying for the channel. Suggested by Panagiotis > Kefalidis >2002/05/14 Rewrote database saving routines to avoid data loss. > > --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 frostycoolslug at hotmail.com Wed May 22 23:46:26 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] MySQL DataBase Module... Message-ID: Hi, i'm Craig McLure.. you might remember me from such mailing lists as.... anyway.. I heard someone was working on a MySQL Database module for Services, could i ask how progress on this is? I have my elite coding team working on a BotServ module, should make some people happy, as this has been requested a few times ;) Cheers -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From mark at ctcp.net Thu May 23 12:37:41 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Services 5.0 alpha 34 released Message-ID: <1264.193.237.130.98.1022182661.squirrel@secure.uksolutions.co.uk> Andrew Church wrote: > 2002/05/14 Services admins can now modify channel access lists without > identifying for the channel. Suggested by Panagiotis > Kefalidis There have been a number of discussions on the list in the past wrt this issue and it seems that people were against this as well as for it. Any chance of making this a config option rather than permanent behaviour? -- Mark. From griever at t2n.org Thu May 23 12:56:55 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Services 5.0 alpha 34 released In-Reply-To: <1264.193.237.130.98.1022182661.squirrel@secure.uksolutions.co.uk> Message-ID: yOn Thu, 23 May 2002, Mark Hetherington wrote: > Andrew Church wrote: > > 2002/05/14 Services admins can now modify channel access lists without > > identifying for the channel. Suggested by Panagiotis > > Kefalidis > > There have been a number of discussions on the list in the past wrt this > issue and it seems that people were against this as well as for it. Any > chance of making this a config option rather than permanent behaviour? > How about a CS OVERRIDE command? From achurch at achurch.org Fri May 24 08:19:48 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Services 5.0 alpha 34 released Message-ID: <3ced7939.44521@achurch.org> >Andrew Church wrote: >> 2002/05/14 Services admins can now modify channel access lists without >> identifying for the channel. Suggested by Panagiotis >> Kefalidis > >There have been a number of discussions on the list in the past wrt this >issue and it seems that people were against this as well as for it. Any >chance of making this a config option rather than permanent behaviour? I don't see the need; if you don't trust people to not abuse it, don't make them Services admins. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Fri May 24 08:20:55 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Services 5.0 alpha 35 released Message-ID: <3ced7b44.51430@achurch.org> Dum dee dum... Changes in version 5.0 alpha 35 ------------------------------- 2002/05/24 a35 Fixed crash on use of unregistered nicks. 2002/05/23 Fixed OperServ SU password not being saved. Reported by --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Thu May 23 18:30:45 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Services 5.0 alpha 34 released In-Reply-To: <3ced7939.44521@achurch.org> Message-ID: yOn Fri, 24 May 2002, Andrew Church wrote: > >Andrew Church wrote: > >> 2002/05/14 Services admins can now modify channel access lists without > >> identifying for the channel. Suggested by Panagiotis > >> Kefalidis > > > >There have been a number of discussions on the list in the past wrt this > >issue and it seems that people were against this as well as for it. Any > >chance of making this a config option rather than permanent behaviour? > > I don't see the need; if you don't trust people to not abuse it, don't > make them Services admins. > There's still a potential for using it accidentally (believe me). Why not make an OVERRIDE command that identifies a services admin as channel founder, and put it in a module? From achurch at achurch.org Fri May 24 11:09:00 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Services 5.0 alpha 34 released Message-ID: <3ceda0f3.51520@achurch.org> >yOn Fri, 24 May 2002, Andrew Church wrote: > >> >Andrew Church wrote: >> >> 2002/05/14 Services admins can now modify channel access lists without >> >> identifying for the channel. Suggested by Panagiotis >> >> Kefalidis >> > >> >There have been a number of discussions on the list in the past wrt this >> >issue and it seems that people were against this as well as for it. Any >> >chance of making this a config option rather than permanent behaviour? >> >> I don't see the need; if you don't trust people to not abuse it, don't >> make them Services admins. >> > >There's still a potential for using it accidentally (believe me). Why not >make >an OVERRIDE command that identifies a services admin as channel founder, >and put it in a module? Because too much flexibility is a problem in and of itself. I do see the point about using the command accidentally, though, so I'll think about some sort of workaround. --Andrew Church achurch@achurch.org http://achurch.org/ From frostycoolslug at hotmail.com Fri May 24 00:59:13 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Services 5.0 alpha 34 released Message-ID: only let Services root Admin or SU do it? >From: achurch@achurch.org (Andrew Church) >Reply-To: ircservices-coding@ircservices.za.net >To: ircservices-coding@ircservices.za.net >Subject: RE: [IRCServices Coding] Services 5.0 alpha 34 released >Date: Fri, 24 May 2002 11:09:00 JST > > >yOn Fri, 24 May 2002, Andrew Church wrote: > > > >> >Andrew Church wrote: > >> >> 2002/05/14 Services admins can now modify channel access lists >without > >> >> identifying for the channel. Suggested by Panagiotis > >> >> Kefalidis > >> > > >> >There have been a number of discussions on the list in the past wrt >this > >> >issue and it seems that people were against this as well as for it. >Any > >> >chance of making this a config option rather than permanent behaviour? > >> > >> I don't see the need; if you don't trust people to not abuse it, >don't > >> make them Services admins. > >> > > > >There's still a potential for using it accidentally (believe me). Why not > >make > >an OVERRIDE command that identifies a services admin as channel founder, > >and put it in a module? > > Because too much flexibility is a problem in and of itself. I do see >the point about using the command accidentally, though, so I'll think about >some sort of workaround. > > --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 -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From VisionOfHell at aol.com Fri May 24 08:55:21 2002 From: VisionOfHell at aol.com (VisionOfHell@aol.com) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Re: Crontab Script Message-ID: <1a2.2b95a48.2a1fbc69@aol.com> Andrew the last time I wrote wrt the my crontab script you stated that it was my script that was faulty. I am now using yours and am still getting the same results. Basically I set the script and put a path to it in the crontab. Every ten minutes I not only get an email stating services is starting but I get the expected error in irc stating that it is cancelling the new link as it already exists. I then look in /lib and find that the .pid file has disappeared (it was there when services started). All I can think is that this element of the config is wrong: # RunGroup [OPTIONAL] # Specify the group which Services should run as. can be # either a group name or an equals sign ("=") followed by a group ID. # If not specified, Services will use the group ID it is started with. # Note that Unix setgid permission on the executable file will do the # same thing, but the setgid permission bit is cleared whenever the # file is modified, while this setting will always be used (if the # system permits it) when Services is started. #RunGroup ice #RunGroup =65534 # A common value for the "nogroup" group # Umask [RECOMMENDED] # Sets the umask (file creation mask) for Services. This mask is # applied to all data files created by Services, including database # files (which are recreated on every database update) and the process # ID file (PIDFile, below), and indicates which file permission bits # are NOT to be set on those files as an octal value. Common values # are given in the examples below. If not specified, the umask in # place when Services is started will be used. #Umask 077 # Disallows access to all but file owner # (recommended when RunGroup is not set) #Umask 007 # Allows access to members of file group as well # (recommended when RunGroup is set) I have tried various combinations of the above to no avail. Any help or advice would be much appreciated :) From RT.Mail at verizon.net Fri May 24 10:31:37 2002 From: RT.Mail at verizon.net (RT.Mail@verizon.net) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Re: [IRCServices Coding] In-Reply-To: <1a2.2b95a48.2a1fbc69@aol.com> Message-ID: <20020524172917.CHNT10042.out006.verizon.net@bofh> I feel that what Andrew has done with allowing services admin to modify the channel access list is great. There is no need for an override command. Trust me. I have worked with services that allowed admins to do anything to the channel that people on the channel access list could do. Those were and until the final release of 5.0, I think still are the best services I have worked with. Its not that easy to make a mistake. And usually its not that hard to correct one if you do. Just let Andrew get these services finished and released. If you still feel the need for him to add an override command in let it be an addition to the next version. Just let him get 5.0 out :P From VisionOfHell at aol.com Fri May 24 12:42:50 2002 From: VisionOfHell at aol.com (VisionOfHell@aol.com) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Re: CS Topic Message-ID: <1b9.15faa63.2a1ff1ba@aol.com> Ok it seems the cd topic bug is fixed however how about the folloowing: I have a channel where the level for topic is set to 100 it also has topic lock on My assumption was that if a user at level 50 tried to change the topic, it would just give them permission denied, however, it lets topic lock kick in. Surely the reason for having a topic level on a channel is so that anyone below that cannot even get as far as being duped by topic lock? From frostycoolslug at hotmail.com Fri May 24 12:58:45 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Re: CS Topic Message-ID: Topic changing is handled by the IRCd and not Services, Services cannot prevent a topic from being changed, instead change it back to what it was previously. >From: VisionOfHell@aol.com >Reply-To: ircservices-coding@ircservices.za.net >To: ircservices-coding@ircservices.za.net >Subject: [IRCServices Coding] Re: CS Topic >Date: Fri, 24 May 2002 15:42:50 EDT > >Ok it seems the cd topic bug is fixed however how about the folloowing: > >I have a channel where the level for topic is set to 100 >it also has topic lock on > >My assumption was that if a user at level 50 tried to change the topic, it >would just give them permission denied, however, it lets topic lock kick >in. > >Surely the reason for having a topic level on a channel is so that anyone >below that cannot even get as far as being duped by topic lock? >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From rg at tcslon.com Fri May 24 13:03:28 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Re: CS Topic In-Reply-To: Message-ID: > Topic changing is handled by the IRCd and not Services, > Services cannot > prevent a topic from being changed, instead change it back > to what it was > previously. Just to clarify that - if the user is [h]op in a channel, the topic will be changed, but services will detect this and switch it back - this isn't the topiclock kicking in, it's services changing it back because of the user level. If you get my drift. Cheers, Russ Garrett russ@garrett.co.uk http://www.faereal.net From frostycoolslug at hotmail.com Fri May 24 13:09:48 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Re: CS Topic Message-ID: ta for clarifying :p >From: "Russell Garrett" >Reply-To: ircservices-coding@ircservices.za.net >To: >Subject: RE: [IRCServices Coding] Re: CS Topic >Date: Fri, 24 May 2002 21:03:28 +0100 > > > Topic changing is handled by the IRCd and not Services, > > Services cannot > > prevent a topic from being changed, instead change it back > > to what it was > > previously. > >Just to clarify that - if the user is [h]op in a channel, the topic >will be changed, but services will detect this and switch it back - >this isn't the topiclock kicking in, it's services changing it back >because of the user level. If you get my drift. > >Cheers, > >Russ Garrett >russ@garrett.co.uk >http://www.faereal.net > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From serdar at konuk.net Sat May 25 00:31:20 2002 From: serdar at konuk.net (serdar@konuk.net) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] How Can I do Message-ID: <34117.217.131.124.70.1022311880.bayposta@mail.konuk.net> I cant install te ircservices 5,0 alpha version it gaves always boulnd move directory of modules (and some same like problems) how can ? install my services I think the main problem is Modules From gizm0 at mail.gr Sat May 25 12:01:21 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] How Can I do Message-ID: <102231728101@mailserver.mail.gr> Óôßò Sat, 25 May 2002 10:31:20 +0300 (EEST) serdar@konuk.net Ýãñáøå: > I cant install te ircservices 5,0 alpha version it gaves always > boulnd move > directory of modules (and some same like problems) how can ý install my > services I think the main problem is Modules > I can't understand what he's trying to explain us. :P anyone who did? "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From admin at nevernet.net Sat May 25 02:32:25 2002 From: admin at nevernet.net (Elijah) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] How Can I do In-Reply-To: <102231728101@mailserver.mail.gr> Message-ID: <000e01c203cf$146e6d10$d26b3a44@noc4> Not I. ELIJAH -----Original Message----- From: ircservices-coding-admin@ircservices.za.net [mailto:ircservices-coding-admin@ircservices.za.net] On Behalf Of Panagiotis Kefalidis ( Gizm0 ) Sent: Saturday, May 25, 2002 1:01 PM To: ircservices-coding@ircservices.za.net Subject: Re: [IRCServices Coding] How Can I do ???? Sat, 25 May 2002 10:31:20 +0300 (EEST) serdar@konuk.net ??????: > I cant install te ircservices 5,0 alpha version it gaves always boulnd > move directory of modules (and some same like problems) how can ? > install my services I think the main problem is Modules > I can't understand what he's trying to explain us. :P anyone who did? "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From serdar at konuk.net Sat May 25 02:34:34 2002 From: serdar at konuk.net (serdar@konuk.net) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] How Can I do In-Reply-To: <102231728101@mailserver.mail.gr> References: <102231728101@mailserver.mail.gr> Message-ID: <38144.217.131.5.142.1022319274.bayposta@mail.konuk.net> > ???? Sat, 25 May 2002 10:31:20 +0300 (EEST) serdar@konuk.net ??????: > >> I cant install te ircservices 5,0 alpha version it gaves always >> boulnd move >> directory of modules (and some same like problems) how can ? install >> my services I think the main problem is Modules >> > I can't understand what he's trying to explain us. :P anyone who did? > > > > "I can see the darkness in your eyes." > Gizm0.- > Oke I will write again I can't install ircservices alpha version I think there is a fault in modules When I make it compile (make) it doesn't complete.. oke and says could not move directory modules How can I install te services From gizm0 at mail.gr Sat May 25 12:19:10 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] How Can I do Message-ID: <102231835001@mailserver.mail.gr> > Oke I will write again I can't install ircservices alpha version I think > there is a fault in modules When I make it compile (make) it doesn't > complete.. oke and says could not move directory modules How can I install > te services did you run the configure script? "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From serdar at konuk.net Sat May 25 02:53:42 2002 From: serdar at konuk.net (serdar@konuk.net) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] How Can I do In-Reply-To: <102231835001@mailserver.mail.gr> References: <102231835001@mailserver.mail.gr> Message-ID: <15216.217.131.5.142.1022320422.bayposta@mail.konuk.net> >> Oke I will write again I can't install ircservices alpha version I >> think there is a fault in modules When I make it compile (make) it >> doesn't complete.. oke and says could not move directory modules How >> can I install te services > did you run the configure script? > > > "I can see the darkness in your eyes." > Gizm0.- Yes I run configure everthing seems rigth but when I run make it gives lots of eror mesagges Ok I will ask you can it be coused by my ircservices version From admin at nevernet.net Sat May 25 02:56:19 2002 From: admin at nevernet.net (Elijah) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] How Can I do In-Reply-To: <15216.217.131.5.142.1022320422.bayposta@mail.konuk.net> Message-ID: <001501c203d2$6b0e4cf0$d26b3a44@noc4> Try gmake. -----Original Message----- From: ircservices-coding-admin@ircservices.za.net [mailto:ircservices-coding-admin@ircservices.za.net] On Behalf Of serdar@konuk.net Sent: Saturday, May 25, 2002 10:54 AM To: ircservices-coding@ircservices.za.net Subject: Re: [IRCServices Coding] How Can I do >> Oke I will write again I can't install ircservices alpha version I >> think there is a fault in modules When I make it compile (make) it >> doesn't complete.. oke and says could not move directory modules How >> can I install te services > did you run the configure script? > > > "I can see the darkness in your eyes." > Gizm0.- Yes I run configure everthing seems rigth but when I run make it gives lots of eror mesagges Ok I will ask you can it be coused by my ircservices version ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From serdar at konuk.net Sat May 25 03:05:42 2002 From: serdar at konuk.net (serdar@konuk.net) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] How Can I do In-Reply-To: <001501c203d2$6b0e4cf0$d26b3a44@noc4> References: <001501c203d2$6b0e4cf0$d26b3a44@noc4> Message-ID: <18621.217.131.5.142.1022321142.bayposta@mail.konuk.net> I try it lots of time but it doesnt work > Try gmake. > > -----Original Message----- > From: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net] On Behalf Of > serdar@konuk.net > Sent: Saturday, May 25, 2002 10:54 AM > To: ircservices-coding@ircservices.za.net > Subject: Re: [IRCServices Coding] How Can I do > > >>> Oke I will write again I can't install ircservices alpha version I >>> think there is a fault in modules When I make it compile (make) it >>> doesn't complete.. oke and says could not move directory modules How >>> can I install te services >> did you run the configure script? >> >> >> "I can see the darkness in your eyes." >> Gizm0.- > Yes I run configure everthing seems rigth but when I run make it gives > lots of eror mesagges Ok I will ask you can it be coused by my > ircservices version From admin at nevernet.net Sat May 25 03:09:06 2002 From: admin at nevernet.net (Elijah) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] How Can I do In-Reply-To: <18621.217.131.5.142.1022321142.bayposta@mail.konuk.net> Message-ID: <001601c203d4$346f1380$d26b3a44@noc4> You've tried both make and gmake then? -----Original Message----- From: ircservices-coding-admin@ircservices.za.net [mailto:ircservices-coding-admin@ircservices.za.net] On Behalf Of serdar@konuk.net Sent: Saturday, May 25, 2002 11:06 AM To: ircservices-coding@ircservices.za.net Subject: RE: [IRCServices Coding] How Can I do I try it lots of time but it doesnt work > Try gmake. > > -----Original Message----- > From: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net] On Behalf Of > serdar@konuk.net > Sent: Saturday, May 25, 2002 10:54 AM > To: ircservices-coding@ircservices.za.net > Subject: Re: [IRCServices Coding] How Can I do > > >>> Oke I will write again I can't install ircservices alpha version I >>> think there is a fault in modules When I make it compile (make) it >>> doesn't complete.. oke and says could not move directory modules How >>> can I install te services >> did you run the configure script? >> >> >> "I can see the darkness in your eyes." >> Gizm0.- > Yes I run configure everthing seems rigth but when I run make it gives > lots of eror mesagges Ok I will ask you can it be coused by my > ircservices version ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From serdar at konuk.net Sat May 25 03:18:36 2002 From: serdar at konuk.net (serdar@konuk.net) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] How Can I do In-Reply-To: <001601c203d4$346f1380$d26b3a44@noc4> References: <001601c203d4$346f1380$d26b3a44@noc4> Message-ID: <30114.217.131.5.142.1022321916.bayposta@mail.konuk.net> yes you are rigth > You've tried both make and gmake then? > > -----Original Message----- From mort at icenet.org.za Sat May 25 03:29:31 2002 From: mort at icenet.org.za (Mortalica) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] How Can I do References: <001601c203d4$346f1380$d26b3a44@noc4> <30114.217.131.5.142.1022321916.bayposta@mail.konuk.net> Message-ID: <15fd01c203d7$0e9ff090$86160ec4@poseidon> Could you maybe paste the error message so that we can get more info? ----- Original Message ----- From: To: Sent: Saturday, May 25, 2002 12:18 PM Subject: RE: [IRCServices Coding] How Can I do > yes you are rigth > > > You've tried both make and gmake then? > > From serdar at konuk.net Sat May 25 03:40:29 2002 From: serdar at konuk.net (serdar@konuk.net) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] How Can I do In-Reply-To: <15fd01c203d7$0e9ff090$86160ec4@poseidon> References: <15fd01c203d7$0e9ff090$86160ec4@poseidon> Message-ID: <23371.217.131.5.142.1022323229.bayposta@mail.konuk.net> sh version.sh gcc -DCLEAN_COMPILE -DDUMPCORE -O2 -Wall -Wmissing-prototypes -g -c version.c -o version.o ide0(3,3): write failed, user block limit reached. cc1: /tmp/cceH4FJp.s: I/O error make: *** [version.o] Error 1 > Could you maybe paste the error message so that we can get more info? > > > ----- Original Message ----- > From: > To: > Sent: Saturday, May 25, 2002 12:18 PM > Subject: RE: [IRCServices Coding] How Can I do > > >> yes you are rigth >> >> > You've tried both make and gmake then? >> > > > > > ------------------------------------------------------------------ To > unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From VisionOfHell at aol.com Sat May 25 04:01:45 2002 From: VisionOfHell at aol.com (VisionOfHell@aol.com) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] Crontab Script Message-ID: Andrew the last time I wrote wrt the my crontab script you stated that it was my script that was faulty. I am now using yours and am still getting the same results. Basically I set the script and put a path to it in the crontab. Every ten minutes I not only get an email stating services is starting but I get the expected error in irc stating that it is cancelling the new link as it already exists. I then look in /lib and find that the .pid file has disappeared (it was there when services started). All I can think is that this element of the config is wrong: # RunGroup [OPTIONAL] # Specify the group which Services should run as. can be # either a group name or an equals sign ("=") followed by a group ID. # If not specified, Services will use the group ID it is started with. # Note that Unix setgid permission on the executable file will do the # same thing, but the setgid permission bit is cleared whenever the # file is modified, while this setting will always be used (if the # system permits it) when Services is started. #RunGroup ice #RunGroup =65534 # A common value for the "nogroup" group # Umask [RECOMMENDED] # Sets the umask (file creation mask) for Services. This mask is # applied to all data files created by Services, including database # files (which are recreated on every database update) and the process # ID file (PIDFile, below), and indicates which file permission bits # are NOT to be set on those files as an octal value. Common values # are given in the examples below. If not specified, the umask in # place when Services is started will be used. #Umask 077 # Disallows access to all but file owner # (recommended when RunGroup is not set) #Umask 007 # Allows access to members of file group as well # (recommended when RunGroup is set) I have tried various combinations of the above to no avail. Any help or advice would be much appreciated :) From gizm0 at mail.gr Sat May 25 13:56:30 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] How Can I do Message-ID: <102232419001@mailserver.mail.gr> Óôßò Sat, 25 May 2002 13:40:29 +0300 (EEST) serdar@konuk.net Ýãñáøå: > sh version.sh > gcc -DCLEAN_COMPILE -DDUMPCORE -O2 -Wall -Wmissing-prototypes -g -c > version.c -o version.o > ide0(3,3): write failed, user block limit reached. > cc1: /tmp/cceH4FJp.s: I/O error > make: *** [version.o] Error 1 have you any free space in you HDD anyway?or permission to access /tmp/ ? "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From uhc0 at rz.uni-karlsruhe.de Sat May 25 04:24:02 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:24 2004 Subject: AW: [IRCServices Coding] How Can I do In-Reply-To: <23371.217.131.5.142.1022323229.bayposta@mail.konuk.net> Message-ID: <000001c203de$be328480$02c8a8c0@nygmatech.local> Your administrator activated quotas on your system. Services compilation requires more space than your quota is allowing you to have. So file creation fails, and compilation also fails. Ask your administrator for a higher quota, or if you are the administrator, disable quotas for your account. 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 serdar@konuk.net > Gesendet: Samstag, 25. Mai 2002 12:40 > An: ircservices-coding@ircservices.za.net > Betreff: Re: [IRCServices Coding] How Can I do > > > sh version.sh > gcc -DCLEAN_COMPILE -DDUMPCORE -O2 -Wall -Wmissing-prototypes > -g -c version.c -o version.o > ide0(3,3): write failed, user block limit reached. > cc1: /tmp/cceH4FJp.s: I/O error > make: *** [version.o] Error 1 > > > Could you maybe paste the error message so that we can get > more info? > > > > > > ----- Original Message ----- > > From: > > To: > > Sent: Saturday, May 25, 2002 12:18 PM > > Subject: RE: [IRCServices Coding] How Can I do > > > > > >> yes you are rigth > >> > >> > You've tried both make and gmake then? > >> > > > > > > > > > > ------------------------------------------------------------------ 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 gizm0 at mail.gr Sat May 25 14:34:46 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:24 2004 Subject: AW: [IRCServices Coding] How Can I do Message-ID: <102232648701@mailserver.mail.gr> Óôßò Sat, 25 May 2002 13:24:02 +0200 "Yusuf Iskenderoglu" Ýãñáøå: > > Your administrator activated quotas on your system. > Services compilation requires more space than your quota is > allowing you to have. So file creation fails, and compilation > also fails. > > Ask your administrator for a higher quota, or if you are the > administrator, disable quotas for your account. > > Regards; > yusuf > yusuf, this is the second possibility :] "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From RT.Mail at verizon.net Sat May 25 06:36:30 2002 From: RT.Mail at verizon.net (RT.Mail@verizon.net) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] SQL DB In-Reply-To: <001501c203d2$6b0e4cf0$d26b3a44@noc4> Message-ID: <20020525123436.UTGW4743.out004.verizon.net@bofh> I had heard a mention of the access list being in sql form. I know this isnt planned for this version however I love that idea. Id love to see that included in future versions or see some sort of addon written for it. Being able to modify a channel access list via php/sql would be great for admins and even users. From frostycoolslug at hotmail.com Sat May 25 10:44:44 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] SQL DB Message-ID: you obviously heard/read/were told wrongly then. there would be little point in only doing the access lists in SQL form, what might be happening, is the *ENTIRE DATABASE* done in SQL, i heard some1 was working on a module to do this, i recently asked who, and when it would be compleated, but with no responce. >From: "RT.Mail@verizon.net" >Reply-To: ircservices-coding@ircservices.za.net >To: >Subject: [IRCServices Coding] SQL DB >Date: Sat, 25 May 2002 08:36:30 -0500 > > >I had heard a mention of the access list being in sql form. I know >this isnt planned for this version however I love that idea. Id love >to see that included in future versions or see some sort of addon >written for it. Being able to modify a channel access list via >php/sql would be great for admins and even users. > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From rg at tcslon.com Sat May 25 10:53:00 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] SQL DB In-Reply-To: Message-ID: > you obviously heard/read/were told wrongly then. > there would be little point in only doing the access lists > in SQL form, what > might be happening, is the *ENTIRE DATABASE* done in SQL, > i heard some1 was > working on a module to do this, i recently asked who, and > when it would be > compleated, but with no responce. I said I *might* have a go, but Andy informed me that the current module structure doesn't lend itself to making other database modules currently, although this will change in 5.1. If I make a module for 5.0, it will certainly be experimental and not for production use until 5.1 comes around and I can fix it and ensure it will be maintainable in the future. Additionally, I won't be able to try for a month or so yet, as I'm quite busy at the moment. Russ Garrett russ@garrett.co.uk http://www.faereal.net From frostycoolslug at hotmail.com Sat May 25 10:56:48 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] SQL DB Message-ID: aah, ok :) cheers :) >From: "Russell Garrett" >Reply-To: ircservices-coding@ircservices.za.net >To: >Subject: RE: [IRCServices Coding] SQL DB >Date: Sat, 25 May 2002 18:53:00 +0100 > > >I said I *might* have a go, but Andy informed me that the current >module structure doesn't lend itself to making other database modules >currently, although this will change in 5.1. If I make a module for >5.0, it will certainly be experimental and not for production use >until 5.1 comes around and I can fix it and ensure it will be >maintainable in the future. Additionally, I won't be able to try for >a month or so yet, as I'm quite busy at the moment. > >Russ Garrett >russ@garrett.co.uk >http://www.faereal.net > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From griever at t2n.org Sat May 25 12:21:32 2002 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] SQL DB In-Reply-To: <20020525123436.UTGW4743.out004.verizon.net@bofh> Message-ID: On Sat, 25 May 2002, RT.Mail@verizon.net wrote: > > I had heard a mention of the access list being in sql form. I know > this isnt planned for this version however I love that idea. Id love > to see that included in future versions or see some sort of addon > written for it. Being able to modify a channel access list via > php/sql would be great for admins and even users. > The database/mysql module is something I started on a rainy day but haven't had the time to finish. If you want the partially-done version, I can give it to you. From RT.Mail at verizon.net Sat May 25 16:17:17 2002 From: RT.Mail at verizon.net (RT.Mail@verizon.net) Date: Sat Oct 23 23:09:24 2004 Subject: [IRCServices Coding] SQL DB In-Reply-To: Message-ID: <20020525221520.OJYI28968.out002.verizon.net@bofh> Yes thats what i was reffering to. I was just useing the access list as an example. Russ I hope you continue to work on it. Finny sure Ill take a partially done version of it. I lknow someone who might be willing to work on it. Thanks From adrian.cantrill at dial.pipex.com Sat May 25 16:04:52 2002 From: adrian.cantrill at dial.pipex.com (Adrian Cantrill) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] Query In-Reply-To: <000e01c203cf$146e6d10$d26b3a44@noc4> Message-ID: <000001c20440$93ebd700$0100a8c0@ado> Hi Peeps, I am interested in making a few situation specific enhancements to the code for services and for this I need to do the following. Need a code segment to fit in the nickserv module that can ascertain the level that a user has in a specific channel. I.e. when a user executes the identify command as part of that function I need to be able to ascertain the level the use holds in a specific channel i.e. #titans specifically. I have tried without success to do the modifications myself, any of you peeps suggest a small code segment to do the job I would be very grateful. Thanks The method I would like to do it is .. given the user running identify and a channel string i.e "#titans" produce a int containing their level. Thanks for any help u can provide. Adrian From uhc0 at rz.uni-karlsruhe.de Sat May 25 17:50:42 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:25 2004 Subject: AW: [IRCServices Coding] Query In-Reply-To: <000001c20440$93ebd700$0100a8c0@ado> Message-ID: <000601c2044f$6ec35de0$02c8a8c0@nygmatech.local> Why don?t you simply say, that you are willing to expand LISTCHANS to display the channels the user has access in, and the appropriate level ? You do make the case sound far more complicated than it actually should be. Otoh, if you are just willing to display the access level the user has in ONE single channel, there is already the STATUS command for this purpose. /cs HELP STATUS for more information. 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 Adrian Cantrill > Gesendet: Sonntag, 26. Mai 2002 01:05 > An: ircservices-coding@ircservices.za.net > Betreff: [IRCServices Coding] Query > > > > Hi Peeps, > > I am interested in making a few situation specific > enhancements to the code for services and for this I need to > do the following. > > Need a code segment to fit in the nickserv module that can > ascertain the level that a user has in a specific channel. > I.e. when a user executes the identify command as part of > that function I need to be able to ascertain the level the > use holds in a specific channel i.e. #titans specifically. > > I have tried without success to do the modifications myself, > any of you peeps suggest a small code segment to do the job I > would be very grateful. Thanks > > The method I would like to do it is .. given the user running > identify and a channel string i.e "#titans" produce a int > containing their level. > > Thanks for any help u can provide. > > Adrian > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo> /ircservices-coding > From mark at ctcp.net Sat May 25 18:09:34 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] Query Message-ID: <21025.193.237.130.98.1022375374.squirrel@secure.uksolutions.co.uk> Adrian Cantrill wrote: > Need a code segment to fit in the nickserv module that can ascertain the > level that a user has in a specific channel. I.e. when a user executes > the identify command as part of that function I need to be able to > ascertain the level the use holds in a specific channel i.e. #titans > specifically. Try: /cs status #titans nickname -- Mark. From r-krisztian at softhome.net Sat May 25 23:03:56 2002 From: r-krisztian at softhome.net (Romek =?iso-8859-1?q?Kriszti=E9n?=) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] HTTP Error In-Reply-To: References: Message-ID: <02052608035600.18393@adsl52064> Hello! I cannot reproduce the problem but somebody was browsing the services web server and caused an error to the services so i have a core file: Core was generated by `./ircservices'. Program terminated with signal 11, Segmentation fault. ... #0 http_unquote_url (buf=0x8194387 'z' ...) at util.c:332 332 *out++ = *buf++; I don't know if it can help you so if i can, i will reproduce the problem. AngryWolf From achurch at achurch.org Sun May 26 15:27:21 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] HTTP Error Message-ID: <3cf0806c.17113@achurch.org> Fixed (I think), thanks. (I can't imagine what I must have been on when I wrote that code...) --Andrew Church achurch@achurch.org http://achurch.org/ >Hello! > >I cannot reproduce the problem but somebody was browsing the services web >server and caused an error to the services so i have a core file: > >Core was generated by `./ircservices'. >Program terminated with signal 11, Segmentation fault. >... >#0 http_unquote_url (buf=0x8194387 'z' ...) at util.c:332 >332 *out++ = *buf++; > >I don't know if it can help you so if i can, i will reproduce the problem. > >AngryWolf >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From r-krisztian at softhome.net Sat May 25 23:46:00 2002 From: r-krisztian at softhome.net (Romek =?iso-2022-jp?q?Kriszti=1B=28B=3F=1B=28Bn?=) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] Bug or not... In-Reply-To: <3cf0806c.17113@achurch.org> References: <3cf0806c.17113@achurch.org> Message-ID: <02052608460000.20350@adsl52064> >From ircservices.log: [May 25 21:16:47 2002] user: do_part: no channel record for pOliCe on #webadmin (bug?) [May 25 21:14:48 2002] user: do_part: no channel record for pOliCe on #opers (bug?) I have still Unreal3.2beta9. I can't say more :) From r-krisztian at softhome.net Sat May 25 23:53:45 2002 From: r-krisztian at softhome.net (Romek =?iso-2022-jp?q?Kriszti=1B=28B=3F=1B=28Bn?=) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] HTTP Error In-Reply-To: <3cf0806c.17113@achurch.org> References: <3cf0806c.17113@achurch.org> Message-ID: <02052608534501.20350@adsl52064> Ah, yes, I had to have time to see what's the problem really. :(( I've started to learn C but too later, so sorry because of my little experience of the language! :) I'ld like to see if it's okey or not, so can you send me a patch or anything? Romek Krisztian ------------------------------------------------------------------ > Fixed (I think), thanks. (I can't imagine what I must have been on > when I wrote that code...) > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > > >Hello! > > > >I cannot reproduce the problem but somebody was browsing the services web > >server and caused an error to the services so i have a core file: > > > >Core was generated by `./ircservices'. > >Program terminated with signal 11, Segmentation fault. > >... > >#0 http_unquote_url (buf=0x8194387 'z' ...) at > > util.c:332 332 *out++ = *buf++; > > > >I don't know if it can help you so if i can, i will reproduce the problem. > > > >AngryWolf From VisionOfHell at aol.com Sun May 26 01:31:45 2002 From: VisionOfHell at aol.com (VisionOfHell@aol.com) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] Crontab Script Message-ID: <148.efc94fe.2a21f771@aol.com> The last time I wrote wrt the my crontab script you stated that it was my script that was faulty. I am now using yours and am still getting the same results. Basically I set the script and put a path to it in the crontab. Every ten minutes I not only get an email stating services is starting but I get the expected error in irc stating that it is cancelling the new link as it already exists. I then look in /lib and find that the .pid file has disappeared (it was there when services started). All I can think is that this element of the config is wrong: # RunGroup [OPTIONAL] # Specify the group which Services should run as. can be # either a group name or an equals sign ("=") followed by a group ID. # If not specified, Services will use the group ID it is started with. # Note that Unix setgid permission on the executable file will do the # same thing, but the setgid permission bit is cleared whenever the # file is modified, while this setting will always be used (if the # system permits it) when Services is started. #RunGroup ice #RunGroup =65534 # A common value for the "nogroup" group # Umask [RECOMMENDED] # Sets the umask (file creation mask) for Services. This mask is # applied to all data files created by Services, including database # files (which are recreated on every database update) and the process # ID file (PIDFile, below), and indicates which file permission bits # are NOT to be set on those files as an octal value. Common values # are given in the examples below. If not specified, the umask in # place when Services is started will be used. #Umask 077 # Disallows access to all but file owner # (recommended when RunGroup is not set) #Umask 007 # Allows access to members of file group as well # (recommended when RunGroup is set) I have tried various combinations of the above to no avail. Any help or advice would be much appreciated :) From admin at nevernet.net Sun May 26 01:36:48 2002 From: admin at nevernet.net (Elijah) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] Crontab Script In-Reply-To: <148.efc94fe.2a21f771@aol.com> Message-ID: <002201c20490$7a0588e0$d26b3a44@noc4> How many times are we going to see this same message? -----Original Message----- From: ircservices-coding-admin@ircservices.za.net [mailto:ircservices-coding-admin@ircservices.za.net] On Behalf Of VisionOfHell@aol.com Sent: Sunday, May 26, 2002 9:32 AM To: ircservices-coding@ircservices.za.net Subject: [IRCServices Coding] Crontab Script The last time I wrote wrt the my crontab script you stated that it was my script that was faulty. I am now using yours and am still getting the same results. Basically I set the script and put a path to it in the crontab. Every ten minutes I not only get an email stating services is starting but I get the expected error in irc stating that it is cancelling the new link as it already exists. I then look in /lib and find that the .pid file has disappeared (it was there when services started). All I can think is that this element of the config is wrong: # RunGroup [OPTIONAL] # Specify the group which Services should run as. can be # either a group name or an equals sign ("=") followed by a group ID. # If not specified, Services will use the group ID it is started with. # Note that Unix setgid permission on the executable file will do the # same thing, but the setgid permission bit is cleared whenever the # file is modified, while this setting will always be used (if the # system permits it) when Services is started. #RunGroup ice #RunGroup =65534 # A common value for the "nogroup" group # Umask [RECOMMENDED] # Sets the umask (file creation mask) for Services. This mask is # applied to all data files created by Services, including database # files (which are recreated on every database update) and the process # ID file (PIDFile, below), and indicates which file permission bits # are NOT to be set on those files as an octal value. Common values # are given in the examples below. If not specified, the umask in # place when Services is started will be used. #Umask 077 # Disallows access to all but file owner # (recommended when RunGroup is not set) #Umask 007 # Allows access to members of file group as well # (recommended when RunGroup is set) I have tried various combinations of the above to no avail. Any help or advice would be much appreciated :) ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From serdar at konuk.net Sun May 26 02:57:18 2002 From: serdar at konuk.net (serdar@konuk.net) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] Initialization failed, exiting. Message-ID: <35647.195.175.176.117.1022407038.bayposta@mail.konuk.net> The fault is "Initialization failed, exiting." I wrote everything to ircservices.conf but it doesnt work help pls From r-krisztian at softhome.net Sun May 26 04:33:19 2002 From: r-krisztian at softhome.net (Romek Krisztian) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] Initialization failed, exiting. In-Reply-To: <35647.195.175.176.117.1022407038.bayposta@mail.konuk.net> References: <35647.195.175.176.117.1022407038.bayposta@mail.konuk.net> Message-ID: <02052613331900.29484@adsl52064> > The fault is "Initialization failed, exiting." I wrote everything to > ircservices.conf but it doesnt work help pls Look at ircservices.log and see what's happened. Check your link is okey or not, check everything. Read again your configuration file, etc... The answer is on your computer. Romek Krisztian From r-krisztian at softhome.net Sun May 26 05:14:43 2002 From: r-krisztian at softhome.net (Romek Krisztian) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] Crontab Script In-Reply-To: <002201c20490$7a0588e0$d26b3a44@noc4> References: <002201c20490$7a0588e0$d26b3a44@noc4> Message-ID: <02052614144300.32048@adsl52064> Hello! > How many times are we going to see this same message? :)) > The last time I wrote wrt the my crontab script you stated that it was > my script that was faulty. > I am now using yours and am still getting the same results. The script works for me. I don't use RunGroup but Umask (077). I think the problem isn't there. You said that your link is alive when the crontab script runs. Try to find why and give us more information about that like how did the services crashed or anything... Romek Krisztian From VisionOfHell at aol.com Mon May 27 03:40:51 2002 From: VisionOfHell at aol.com (VisionOfHell@aol.com) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] Crontab Script Message-ID: <107.1250186b.2a236733@aol.com> Services didnt crash, services is just fine, its just the script cant seem to see that services is running so tries to start it again, the link gets cancelled because it is already live. From VisionOfHell at aol.com Mon May 27 08:54:27 2002 From: VisionOfHell at aol.com (VisionOfHell@aol.com) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] Strange Errors in 5.0 Message-ID: <103.15e3042a.2a23b0b3@aol.com> [May 27 15:22:00 2002] IRC Services 5.0pre0 starting up [May 27 15:22:00 2002] setrlimit(RLIMIT_CORE, RLIM_INFINITY): Operation not permitted [May 27 15:22:03 2002] unknown message from server (:glacier-irc.ice-inferno.com SMO o :(^Blink^B) Link glacier-irc.ice-inferno.com -> services.irc.ice-inferno.com[@194.72.61.8.59322] established) [May 27 15:22:03 2002] operserv/sline: warning: client IP addresses not available with this IRC server From rg at tcslon.com Mon May 27 09:02:52 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] Strange Errors in 5.0 In-Reply-To: <103.15e3042a.2a23b0b3@aol.com> Message-ID: > [May 27 15:22:00 2002] IRC Services 5.0pre0 starting up > [May 27 15:22:00 2002] setrlimit(RLIMIT_CORE, > RLIM_INFINITY): Operation not > permitted This looks like because the OS is stopping services from changing the maximum core memory size, probably because of a quota or something. Probably not a problem, unless the limit is really small. > [May 27 15:22:03 2002] unknown message from server > (:glacier-irc.ice-inferno.com SMO o :(^Blink^B) Link > glacier-irc.ice-inferno.com -> > services.irc.ice-inferno.com[@194.72.61.8.59322] established) > [May 27 15:22:03 2002] operserv/sline: warning: client IP > addresses not > available with this IRC server Aaaand you're not using a supported IRC server, or you're using the wrong module for your ircd. If it's the former problem, you might not be using a supported version of the supported ircd (Bahamut < 1.4.25 is the most common problem). If you're using an unsupported ircd, have fun ;) (I personally have had services running very well on UltimateIRCD v3 alpha using the Bahamut module, although were loads of warnings in the log. YMMV). Russ Garrett russ@garrett.co.uk From fabulous at t7ds.com.br Mon May 27 07:52:10 2002 From: fabulous at t7ds.com.br (fabulous) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] call to introduce_users Message-ID: <3CF2481A.2000104@t7ds.com.br> Something that's not very important, but has caused a bit of trouble for me is the time when introduce_users is called. IRCServices (4.x or 5.x) should wait for the hub to reply the password(and compare it, why not?) before sending it's pseudo-clients (nickserv,chanserv,etc). Actually it sends it's SERVER information and right after start flooding the hub with its client information without waiting for the 'PASS' command. This create a problem with some ircds that won't accept this initial flood and will just ignore it causing a introduce_user loop right after the linking. The way I fixed it was creating a m_pass function and calling introduce_user in it instead of calling it from the main routine. Here is the m_pass :] static void m_pass(char *source, int ac, char **av) { if (ac < 1) return; if (!strcmp(av[0], RemotePassword)) { introduce_user(NULL); } else fatal("Invalid password received from hub: %s", av[0]); } []'s From achurch at achurch.org Tue May 28 08:50:12 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] Strange Errors in 5.0 Message-ID: <3cf2c7bf.40222@achurch.org> >[May 27 15:22:00 2002] IRC Services 5.0pre0 starting up >[May 27 15:22:00 2002] setrlimit(RLIMIT_CORE, RLIM_INFINITY): Operation not >permitted This probably means you're not running under root and you have (or your system administrator has) limited your core dump file size. It's harmless in terms of program function, and will only potentially affect you if Services crashes and you try to get a core dump. If it bothers you, run ./configure with the -no-dumpcore option and this code will be disabled. (-dumpcore is enabled by default in beta versions in order to help catch bugs.) >[May 27 15:22:03 2002] unknown message from server >(:glacier-irc.ice-inferno.com SMO o :(^Blink^B) Link >glacier-irc.ice-inferno.com -> >services.irc.ice-inferno.com[@194.72.61.8.59322] established) This indicates an unrecognized message from the server. What IRC server are you using? >[May 27 15:22:03 2002] operserv/sline: warning: client IP addresses not >available with this IRC server This indicates that your IRC server doesn't send client IP addresses in the NICK message, which means that Services won't be able to enforce SZlines directly. On some servers, it may be possible to send SZlines directly to the IRC servers by enabling ImmediatelySendSline in modules.conf, but if your servers do not support SZlines, then you will be unable to use them at all. --Andrew Church achurch@achurch.org http://achurch.org/ From r-krisztian at softhome.net Mon May 27 21:05:44 2002 From: r-krisztian at softhome.net (Romek Krisztian) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] Strange Errors in 5.0 In-Reply-To: <3cf2c7bf.40222@achurch.org> References: <3cf2c7bf.40222@achurch.org> Message-ID: <02052806054400.15892@adsl52064> Hi! > >[May 27 15:22:03 2002] unknown message from server > >(:glacier-irc.ice-inferno.com SMO o :(^Blink^B) Link > >glacier-irc.ice-inferno.com -> > >services.irc.ice-inferno.com[@194.72.61.8.59322] established) > > This indicates an unrecognized message from the server. What IRC > server are you using? > Unreal3.2-Selene[beta10] I have the same problem. Romek Krisztian From VisionOfHell at aol.com Tue May 28 08:49:29 2002 From: VisionOfHell at aol.com (VisionOfHell@aol.com) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] Strange Errors in 5.0 Message-ID: Yes, I am using Unreal 3.2 Beta10 also and these problems have only started since Upgrading to services 5 Beta 1 n a message dated 28/05/2002 11:01:39 GMT Daylight Time, ircservices-coding-request@ircservices.za.net writes: > [IRCServices Coding] Strange Errors in 5.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20020528/1f270737/attachment.htm From mark at ctcp.net Tue May 28 10:54:34 2002 From: mark at ctcp.net (Mark Hetherington) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] Strange Errors in 5.0 Message-ID: <1125.193.237.130.98.1022608474.squirrel@secure.uksolutions.co.uk> > >[May 27 15:22:03 2002] unknown message from server > >(:glacier-irc.ice-inferno.com SMO o :(^Blink^B) Link > >glacier-irc.ice-inferno.com -> > >services.irc.ice-inferno.com[@194.72.61.8.59322] established) > > This indicates an unrecognized message from the server. What IRC > server are you using? This is an Unreal message that happens during the server link phase. Services has never recognised this message for any version of Unreal. I mentioned it ages ago with some other unsupported ones but this link process remained "unknown". I think it was considered too low priority to fix. A quick look at the protocol code shows that the SMO message is listed in the table but it doesn't recognise up the link notifications. An example when "leaf" connects to "hub" follows: unknown message from server (:hub SMO o :(sync) Link leaf -> hub is now synced [secs: 0 recv: 0.698 sent: 3.225]) unknown message from server (:leaf SMO o :(sync) Link hub -> leaf is now synced [secs: 0 recv: 3.285 sent: 0.698]) Sometimes there will be an additional: unknown message from server (:hub SMO o :(sync) Possible negative TS split at link leaf (1022499961 - 1022499962 = -1)) While on the subject of Unreal messages, aniother unsupported one is the SILENCE command: unknown message from server (:nick SILENCE Nick :*!*user@host) -- Mark. From rg at tcslon.com Wed May 29 10:06:01 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] RAW question In-Reply-To: <003701bfc98c$5997d3b0$6501a8c0@Turby> Message-ID: >I have RAW commands enabled (runnign Unreal ircd 3.1.3, and IRCServices 5.0beta0) in the config for services.... > >But Inotice they are restricted to Services SuperUser only... how can I make them available to Services Admins also? There is no reason in operational use on a network that you should need to use RAW. That's the official line. If you really trust your SAs to use it semi-responsibly (and I wouldn't - a one-liner can kill your network), and you want them to be able to do funky things with RAW, then you'll have to modify the code yourself. It's a very simple change, but I don't have access to the code at the moment so I can't show you. note: I love using raw to confuse people as an SA myself, but I don't agree with giving SAs that power (I don't run the network). I haven't crashed anything using RAW for several years, using the command weekly almost ;) (in contrast... I crashed our net's epona services last week using JUPE... *ahem* no comment lol). However I consider myself an expert at RAW use (LOL) and a simple mistake like /msg operserv raw join #channel can cause your whole network to die. Not good. I strongly advise against it, but I see why people want to use it (I only use it myself because it's there ;)). Russ Garrett russ@garrett.co.uk www.faereal.net From saturn at jetirc.net Wed May 29 10:56:06 2002 From: saturn at jetirc.net (saturn@jetirc.net) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] RAW question Message-ID: <200205291756.g4THu4e04281@mole.e-mol.com> A non-text attachment was scrubbed... Name: not available Type: text Size: 1895 bytes Desc: not available Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20020529/e5bda193/attachment.pot From r-krisztian at softhome.net Wed May 29 11:29:03 2002 From: r-krisztian at softhome.net (Romek Krisztian) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] RAW question References: <200205291756.g4THu4e04281@mole.e-mol.com> Message-ID: <3CF51DEF.7090501@softhome.net> I don't know people why don't answer the question and why just make any suggestions. Is it right? If you don't change the code, only Super Users can use RAW. I prefer that way because Services Admins can also become Super Users by using OperServ SU command and normal users can't, even if they know the password. Although I suggest you to SET a good SUPASS, and it will be all right. If you really want to use RAW, try that way! I use it too. More help: OperServ HELP SU OperServ HELP SET SUPASS Romek Krisztian saturn@jetirc.net wrote: > When you get the chance, I would still like to know how to make that change -- > unless you have a way to set up more than one person as Services Super User > (besides the SU command)? > > Thanks > > ircservices-coding@ircservices.za.net wrote: > >>>I have RAW commands enabled (runnign Unreal ircd 3.1.3, and >>> >>IRCServices 5.0beta0) in the config for services.... >> >>>But Inotice they are restricted to Services SuperUser only... how >>> >>can I make them available to Services Admins also? >> >>There is no reason in operational use on a network that you should >>need to use RAW. That's the official line. If you really trust your >>SAs to use it semi-responsibly (and I wouldn't - a one-liner can kill >>your network), and you want them to be able to do funky things with >>RAW, then you'll have to modify the code yourself. It's a very simple >>change, but I don't have access to the code at the moment so I can't >>show you. >> >>note: I love using raw to confuse people as an SA myself, but I don't >>agree with giving SAs that power (I don't run the network). I haven't >>crashed anything using RAW for several years, using the command >>weekly almost ;) (in contrast... I crashed our net's epona services >>last week using JUPE... *ahem* no comment lol). However I consider >>myself an expert at RAW use (LOL) and a simple mistake like /msg >>operserv raw join #channel can cause your whole network to die. Not >>good. I strongly advise against it, but I see why people want to use >>it (I only use it myself because it's there ;)). >> >> >>Russ Garrett >>russ@garrett.co.uk >>www.faereal.net >> >>------------------------------------------------------------------ >>To unsubscribe or change your subscription options, visit: >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding >> >> > > > _______________________________________________________ > Sent through e-mol. E-mail, Anywhere, Anytime. http://www.e-mol.com > > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > From saturn at jetirc.net Wed May 29 11:53:04 2002 From: saturn at jetirc.net (saturn@jetirc.net) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] RAW question Message-ID: <200205291853.g4TIr4e08276@mole.e-mol.com> A non-text attachment was scrubbed... Name: not available Type: text Size: 3285 bytes Desc: not available Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20020529/a657da11/attachment.asc From rg at tcslon.com Wed May 29 12:31:51 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] RAW Patch [WAS: RAW question] In-Reply-To: <200205291853.g4TIr4e08276@mole.e-mol.com> Message-ID: If anyone's still interested, the patch is here http://russ.garrett.co.uk/ircservices-5.0pre0-saraw.patch - This is really just a 2-minute job there for those who want it - you've heard my view, you really shouldn't need to use it. I tried to patch the help but I never really worked out how all this language compiler stuff works, so the help still says it's root-only. Use at your own risk, YMMV, don't come running to this list to complain when your services admins break your network... Russ Garrett russ@garrett.co.uk www.faereal.net From beng at nc.rr.com Wed May 29 16:19:53 2002 From: beng at nc.rr.com (Ben Goldstein) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] still having smtp_readline problems Message-ID: <002501c20767$c3982830$0300000a@asi200> from smtp_readline, modules/mail/smtp.c:202 if (!have_eol || si->replychar != ' ') return; Should that not be AND? If we dont have the end of line and the socket's replychar isnt a space, return and read again(?). I dont know why anyone else isn't having problems with sendmail functions.. maybe its my mail server. When this code executes, si->replychar == '-'. Change it to && or comment it out, I get mail. 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 ircservices-5.0pre0 services.bstu.dhs.org build #14, compiled Wed May 29 19:12:33 EDT 2002 -- Ben Goldstein (beng@nc.rr.com) From beng at nc.rr.com Wed May 29 16:42:13 2002 From: beng at nc.rr.com (Ben Goldstein) Date: Sat Oct 23 23:09:25 2004 Subject: [IRCServices Coding] httpd question References: <003b01bfc9c4$753f29f0$6501a8c0@Turby> Message-ID: <003601c2076a$84d67450$0300000a@asi200> > Hope this one's really easy to fix, but the manual (for this section) is > rather vague.... > > How do I get the http module to actually OUTPUT the information to the web > dir?? ircservices' httpd module does not actually write files for web content. When you access the webserver, all the content and pages are generated in realtime, straight from ircservices. To access the information, point your webbrowser to http://your.services.machine:port. If you do not have a top-page, you will have to go directly to any "pages" you defined in modules.conf. If you used the examples in modules.conf, try http://your.machine:port/dbaccess or http://your.machine:port/debug. It is a very good idea to have these password protected and limit their access with AllowHost/DenyHost. If you have registered nicks/channels with URL set, you can access those URL's through the httpd, too. If you enabled the httpd/redirect directive, http://your.machine:port/~nick and http://your.machine:port/channel/channame should work. > Is there a template top_page.htm file i shoudl know about?? http/top-page is included so you can create your own opening menu/welcome page for ircservices. From this page you could include links to the other facets of ircservices' httpd. This can be a text file or HTML, which makes more sense, created from an editor or a webpage creation editor. Since there are several different URLs that can be accessed (as mentioned above), it is probably a good idea to make your own toppage that has links/instructions to get around the ircservices/httpd "site". > > Thanks > You're welcome -- Ben Goldstein (beng@nc.rr.com) From gizm0 at mail.gr Thu May 30 10:46:32 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] RAW Patch [WAS: RAW question] Message-ID: <102274479301@mailserver.mail.gr> Óôßò Wed, 29 May 2002 20:31:51 +0100 "Russell Garrett" Ýãñáøå: > If anyone's still interested, the patch is here > http://russ.garrett.co.uk/ircservices-5.0pre0-saraw.patch - This is > really just a 2-minute job there for those who want it - you've heard > my view, you really shouldn't need to use it. I tried to patch the > help but I never really worked out how all this language compiler > stuff works, so the help still says it's root-only. > i've done both.the operserv/main.c patch for services admins to use raw and the language file to work fine :] it's quite easy russ :] mail me private if you want the language file.i've also added a command to report the raw command use to channel #services.it also report what the raw string was.i can send you this also. "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From rg at tcslon.com Thu May 30 01:20:47 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] RAW Patch [WAS: RAW question] In-Reply-To: <102274479301@mailserver.mail.gr> Message-ID: > i've done both.the operserv/main.c patch for services > admins to use raw > and the language file to work fine :] it's quite easy russ > :] mail me > private if you want the language file.i've also added a > command to report > the raw command use to channel #services.it also report > what the raw > string was.i can send you this also. Yeh I've done it before, I was just too tired yesterday to be bothered to fix it :) Russ From achurch at achurch.org Thu May 30 19:16:34 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] Bug with memoserv SAVE (beta0) Message-ID: <3cf5fc28.44317@achurch.org> Fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ >Runnign the services 5.0beta0 release > >My ircd: >Unreal3.1.3-Komara(JetIRC). saturn.jetirc.net CFhiInXSs [Linux >localhost.localdomain 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 >unknown=2302(H)] > >The problem: >At any time, if ANYone uses the Memoserv SAVE command to save a memo from >expiry, services immediately terminates with no entry to the normal log file >for a reason. > >I ran the -debug option.... >In the log file, the last relavant entry is: > [May 29 08:34:54.511303 2002] debug: Received: :Saturn PRIVMSG >MemoServ@services.jetirc.net :save 1 >Then the file ends. > >using GDB, i got the following, right after using the memoserv save command: >#0 save_memo_callback (u=0x8173ed0, num=6, args=0xbffff4c0) at main.c:544 >#1 0x08053611 in process_numlist (numstr=0xbffff63c "", >count_ret=0xbffff4dc, > callback=0x40214f14 , u=0x8173ed0) at misc.c:537 >#2 0x40215b30 in do_save (u=0x8173ed0) at main.c:885 >#3 0x0804e191 in run_cmd (service=0x8171af8 "", u=Cannot access memory at >address 0xbffff534) at commands.c:175 >#4 0x4021468c in memoserv (source=Cannot access memory at address >0xbffff560) at main.c:153 >#5 0x080545de in call_callback_5 (module=Cannot access memory at address >0xbffff5a0) at modules.c:632 >#6 0x080528b9 in m_privmsg (source=Cannot access memory at address >0xbffff5f0) at messages.c:177 >#7 0x08054b43 in process () at process.c:131 >#8 0x0805624f in check_sockets () at sockets.c:392 >#9 0x080522be in main (ac=Cannot access memory at address 0xbffffa30) at >main.c:248 >#10 0x40053507 in __libc_start_main (main=Cannot access memory at address >0xbffffa70) > at ../sysdeps/generic/libc-start.c:129 >Cannot access memory at address 0xbffffa68 > >---- > >I hope this is enough to go on.... > > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Thu May 30 19:17:49 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] RAW question Message-ID: <3cf5fc8f.44333@achurch.org> >I have RAW commands enabled (runnign Unreal ircd 3.1.3, and IRCServices = >5.0beta0) in the config for services.... > >But Inotice they are restricted to Services SuperUser only... how can I = >make them available to Services Admins also? You can't. RAW is a dangerous command, and is limited to the Services superuser for that reason. If you want other people to be able to use it, you need to give them superuser privileges by setting an SU password with OperServ. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Thu May 30 19:24:16 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] still having smtp_readline problems Message-ID: <3cf5fed7.44352@achurch.org> OR is correct. The code reads "repeat the loop if -EITHER- (1) we haven't seen an end-of-line character (i.e. this line hasn't been completely read) -OR- we have read the line completely, but si->replychar (the fourth character of the line) is not a space." The second condition is required to handle multiple-line SMTP replies, in which the fourth character of every line except the last one is '-', and the fourth character of the last line is a space. Maybe your mail server is broken? --Andrew Church achurch@achurch.org http://achurch.org/ > >from smtp_readline, modules/mail/smtp.c:202 > if (!have_eol || si->replychar != ' ') > return; > >Should that not be AND? If we dont have the end of line and the socket's >replychar isnt a space, return and read again(?). I dont know why anyone >else isn't having problems with sendmail functions.. maybe its my mail >server. When this code executes, si->replychar == '-'. Change it to && or >comment it out, I get mail. > >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 > >ircservices-5.0pre0 services.bstu.dhs.org build #14, compiled Wed May 29 >19:12:33 EDT 2002 > >-- Ben Goldstein (beng@nc.rr.com) > > > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From frostycoolslug at hotmail.com Thu May 30 04:01:03 2002 From: frostycoolslug at hotmail.com (Craig McLure) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] RAW question Message-ID: you can.. involves changing operserv.c find the Line: {"RAW", do_raw, is_services_root,OPER_HELP_RAW, -1,-1}, Change it to: {"RAW", do_raw, is_services_admin,OPER_HELP_RAW, -1,-1}, re-compile, and restart services.. et voilla :D >From: achurch@achurch.org (Andrew Church) >Reply-To: ircservices-coding@ircservices.za.net >To: ircservices-coding@ircservices.za.net >Subject: Re: [IRCServices Coding] RAW question >Date: Thu, 30 May 2002 19:17:49 JST > > You can't. RAW is a dangerous command, and is limited to the >Services >superuser for that reason. If you want other people to be able to use it, >you need to give them superuser privileges by setting an SU password with >OperServ. > > --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 -- Craig McLure Craig@chatspike.net Network Administrator of the ChatSpike IRC Network. ChatSpike, the users network! www.chatspike.net _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From gizm0 at mail.gr Thu May 30 16:06:14 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] RAW question Message-ID: <102276397401@mailserver.mail.gr> Óôßò Thu, 30 May 2002 12:01:03 +0100 "Craig McLure" Ýãñáøå: > you can.. involves changing operserv.c > find the Line: can you realize that you are reply to the services author?Is it ever reasonable for you that he don't knows how this works?he created the almost all the services code and he don't knows where the RAW command is defined to be used ONLY "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From gizm0 at mail.gr Thu May 30 16:09:17 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] RAW question Message-ID: <102276415702@mailserver.mail.gr> Óôßò Thu, 30 May 2002 12:01:03 +0100 "Craig McLure" Ýãñáøå: > you can.. involves changing operserv.c > find the Line: by the services superuser? :] P.S sorry for my two replys but i accidentally hit return. "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From achurch at achurch.org Thu May 30 22:36:06 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] RAW question Message-ID: <3cf62bd7.44446@achurch.org> Technically, he's correct; by changing the source code, you can make the RAW command usable by Services admins. However, as you very correctly point out, I am the author of Services, and not only will I refuse to support any version of Services with modifications such as this, if you (not you personally, Gizmo, anyone in general, and the previous poster in particular) actually use such modifications, I hereby reserve the right to publicly laugh in your face if your Services admins cause you trouble by using the RAW command. Does that clear things up? --Andrew Church achurch@achurch.org http://achurch.org/ >> you can.. involves changing operserv.c >> find the Line: > >can you realize that you are reply to the services author?Is it ever >reasonable for you that he don't knows how this works?he created the >almost all the services code and he don't knows where the RAW command is >defined to be used ONLY > >"I can see the darkness in your eyes." > Gizm0.- > >------------------------------------------------------------- >http://www.mail.gr/ - Get Your Private Free Email Address! >http://www.ringtone.gr/ - Ringtones & Logos for your mobile! >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From gizm0 at mail.gr Thu May 30 16:31:31 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] RAW question Message-ID: <102276549101@mailserver.mail.gr> Óôßò Thu, 30 May 2002 22:36:06 JST achurch@achurch.org Ýãñáøå: > Technically, he's correct; by changing the source code, you >can make > the RAW command usable by Services admins. However, as you very correctly > point out, I am the author of Services, and not only will I refuse to > support any version of Services with modifications such as this, if you > (not you personally, Gizmo, anyone in general, and the previous poster in > particular) actually use such modifications, I hereby reserve the right to > publicly laugh in your face if your Services admins cause you trouble by > using the RAW command. > > Does that clear things up? > yes,it does. :] "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From RT.Mail at verizon.net Thu May 30 08:42:06 2002 From: RT.Mail at verizon.net (RT.Mail@verizon.net) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] RAW question In-Reply-To: Message-ID: <20020530144010.CSIN4569.out012.verizon.net@bofh> Hi. We havent upgraded to the newer services yet as we are going to wait until a leter beta. Also im just new to these services in general. Im only trying to gather some information for when we do upgrade. It is my understanding that to become a super user you must switch to the certain nick that is defind and then enter the password. We want the two head admins to be able to use raw commands. Is it possible to add two nicks? We basically want to be able to have two super users. Or am I totally wrong about how that works? Thanks. From rg at tcslon.com Thu May 30 07:45:22 2002 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] RAW question In-Reply-To: <20020530144010.CSIN4569.out012.verizon.net@bofh> Message-ID: > Hi. We havent upgraded to the newer services yet as we are > going to > wait until a leter beta. Also im just new to these services in > general. Im only trying to gather some information for when we do > upgrade. It is my understanding that to become a super > user you must > switch to the certain nick that is defind and then enter the > password. We want the two head admins to be able to use > raw commands. > Is it possible to add two nicks? We basically want to be > able to have > two super users. Or am I totally wrong about how that works? I originally thought that as well, but if you are the services root specified in the config file, you automatically have access to root commands once you're identified and opered. Other identified and opered Services Admins can obtain root privileges by using the SU command and the password. Russ Garrett russ@garrett.co.uk www.faereal.net From r-krisztian at softhome.net Thu May 30 08:45:13 2002 From: r-krisztian at softhome.net (Romek Krisztian) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] Little bugs & Questions References: <002e01bfc98c$267c7bc0$6501a8c0@Turby> Message-ID: <3CF64909.2050705@softhome.net> Hello! These are little bugs or not, they're not serious but I'ld be happy to see them or some of them corrected because some users use the keyboard in a very stupid way. :))) 1. Two problems where somebody inserts more than one space after or before a command: " help set " -NickServ- No help available for set . " help set email" -NickServ- No help available for set email. In some ways, more than one space is ignored: help set email -NickServ- Syntax: SET EMAIL address set language 1 -NickServ- Language changed to English. 3. In this example, I mean it would be better to filter some formatting characters: help set -NickServ- Unknown command help. Type /msg NickServ HELP for help. 5. What about giving more than one word for passwords? set password first second -NickServ- Password changed to first. 6. Giving URLs set url sdf://sdf.d:3425/ -NickServ- URLs must be in the form http://hostname[:port]/... (or ftp://, etc.). This is the same when I try ChanServ. 7. Timezone problems set timezone +1:3 -NickServ- The current time in this time zone is ... set timezone +2:6 -NickServ- Syntax: SET TIMEZONE {UTC-offset | time-zone | DEFAULT} It's the same when i try 7, 8, 9 instead of 6. 8. Syntax help help unset -NickServ- Syntax: UNSET {URL | INFO} unset -NickServ- Syntax: UNSET URL list -NickServ- Syntax: LISTEMAIL pattern [FORBIDDEN] [NOEXPIRE] [SUSPENDED] [NOAUTH] 9. list and listemail doesn't check if i say something else than FORBIDDEN, NOEXPIRE, SUSPENDED or NOAUTH list * for bidden -NickServ- List of entries matching *: (...) -NickServ- End of list; 50/74 matches shown. 10. MLOCK problem I don't know whether it's a bug, but it's interesting: set #arena mlock +nt-ikOAN+k -ChanServ- Parameter required for MLOCK +k. set #arena mlock +nt-ikOAN+k something -ChanServ- Mode lock on channel #arena changed to +ntk-iOAN. 11. Is there a way to clear entrymsg? 12. I can send a memo for myself, is it okey? Thats all for now. :) From achurch at achurch.org Fri May 31 01:04:51 2002 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] Bug with memoserv SAVE (beta0) Message-ID: <3cf64daa.45044@achurch.org> Not until the next release. >Is there a patch? =) > >-Dave >irc.jetirc.net > >----- Original Message ----- >From: "Andrew Church" >To: >Sent: Thursday, May 30, 2002 3:16 AM >Subject: Re: [IRCServices Coding] Bug with memoserv SAVE (beta0) > > >> Fixed, thanks. >> >> --Andrew Church >> achurch@achurch.org >> http://achurch.org/ >> >> >Runnign the services 5.0beta0 release >> > >> >My ircd: >> >Unreal3.1.3-Komara(JetIRC). saturn.jetirc.net CFhiInXSs [Linux >> >localhost.localdomain 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 >> >unknown=2302(H)] >> > >> >The problem: >> >At any time, if ANYone uses the Memoserv SAVE command to save a memo from >> >expiry, services immediately terminates with no entry to the normal log >file >> >for a reason. >> > >> >I ran the -debug option.... >> >In the log file, the last relavant entry is: >> > [May 29 08:34:54.511303 2002] debug: Received: :Saturn PRIVMSG >> >MemoServ@services.jetirc.net :save 1 >> >Then the file ends. >> > >> >using GDB, i got the following, right after using the memoserv save >command: >> >#0 save_memo_callback (u=0x8173ed0, num=6, args=0xbffff4c0) at >main.c:544 >> >#1 0x08053611 in process_numlist (numstr=0xbffff63c "", >> >count_ret=0xbffff4dc, >> > callback=0x40214f14 , u=0x8173ed0) at misc.c:537 >> >#2 0x40215b30 in do_save (u=0x8173ed0) at main.c:885 >> >#3 0x0804e191 in run_cmd (service=0x8171af8 "", u=Cannot access memory >at >> >address 0xbffff534) at commands.c:175 >> >#4 0x4021468c in memoserv (source=Cannot access memory at address >> >0xbffff560) at main.c:153 >> >#5 0x080545de in call_callback_5 (module=Cannot access memory at address >> >0xbffff5a0) at modules.c:632 >> >#6 0x080528b9 in m_privmsg (source=Cannot access memory at address >> >0xbffff5f0) at messages.c:177 >> >#7 0x08054b43 in process () at process.c:131 >> >#8 0x0805624f in check_sockets () at sockets.c:392 >> >#9 0x080522be in main (ac=Cannot access memory at address 0xbffffa30) at >> >main.c:248 >> >#10 0x40053507 in __libc_start_main (main=Cannot access memory at address >> >0xbffffa70) >> > at ../sysdeps/generic/libc-start.c:129 >> >Cannot access memory at address 0xbffffa68 >> > >> >---- >> > >> >I hope this is enough to go on.... >> > >> > >> > >> >------------------------------------------------------------------ >> >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 beng at nc.rr.com Thu May 30 11:31:19 2002 From: beng at nc.rr.com (Ben Goldstein) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] Correction in language file Message-ID: <00ca01c20808$8f5d1d40$0300000a@asi200> en_us.l: NICK_SETAUTH_USER_NOTICE You must authorize your nickname before continuing to use it. An author Type ^B/msg %S HELP AUTH^B for more information. Should be %s. -- Ben Goldstein (beng@nc.rr.com) From beng at nc.rr.com Thu May 30 11:46:17 2002 From: beng at nc.rr.com (Ben Goldstein) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] Concerns with sendpass Message-ID: <00e001c2080a$4af28c60$0300000a@asi200> 1) In order to sendpass, you have to be using the nick you want to retreive the password for. If someone else is online using your nickname, you're stuck. 2) When you request a sendpass, your email address is shown to you. This would typically a good thing, but this means I can go around and get anyone's email address and spam away, getting around SET HIDE EMAIL. I suggest not showing the address if HIDE EMAIL is set, or either requiring the user to /ns sendpass . 3) Not related to sendpass but to AUTH: I am thinking an OS SET switch to suspend pending AUTH-expirys might be good in case your ISP is having mail problems. This might only be a problem on larger networks, but then again they are more likely to have their own mailserver.. *shrug* Some things to think about. -- Ben Goldstein (beng@nc.rr.com) btw, good work as always, Andrew. From gizm0 at mail.gr Thu May 30 21:46:38 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] Concerns with sendpass Message-ID: <102278439801@mailserver.mail.gr> Óôßò Thu, 30 May 2002 14:46:17 -0400 "Ben Goldstein" Ýãñáøå: > 1) In order to sendpass, you have to be using the nick you want to > retreive > the password for. If someone else is online using your nickname, you're > stuck. > > 2) When you request a sendpass, your email address is shown to you. This > would typically a good thing, but this means I can go around and get > anyone's email address and spam away, getting around SET HIDE EMAIL. I you will propably get killed for services flood. > suggest not showing the address if HIDE EMAIL is set, or either good idea. requiring > the user to /ns sendpass . are you crazy?imaging changing to your nick ,doing /ns sendpass yournick mymail@mymail.arpa and sending your password to my e-mail account :] > > 3) Not related to sendpass but to AUTH: I am thinking an OS SET switch to > suspend pending AUTH-expirys might be good in case your ISP is having mail > problems. This might only be a problem on larger networks, but then again > they are more likely to have their own mailserver.. *shrug* > > Some things to think about. > > -- Ben Goldstein (beng@nc.rr.com) > and for your previous post about the %S and %s.The %S it is correct.it used to identify if we are reffering to a services pseudoclient ( so it is %S ) or to any kind of other stuff ( so it is %s) "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From saturn at jetirc.net Thu May 30 12:14:56 2002 From: saturn at jetirc.net (saturn@jetirc.net) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] Concerns with sendpass Message-ID: <200205301914.g4UJEre30060@mole.e-mol.com> A non-text attachment was scrubbed... Name: not available Type: text Size: 1443 bytes Desc: not available Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20020530/cf94a46f/attachment.pot From uhc0 at rz.uni-karlsruhe.de Thu May 30 12:31:06 2002 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu) Date: Sat Oct 23 23:09:26 2004 Subject: AW: [IRCServices Coding] Concerns with sendpass In-Reply-To: <102278439801@mailserver.mail.gr> Message-ID: <000801c20810$9cc23f30$02c8a8c0@nygmatech.local> Just to correct you, Panagiotis; > > 2) When you request a sendpass, your email address is shown > to you. > > This would typically a good thing, but this means I can go > around and > > get anyone's email address and spam away, getting around SET HIDE > > EMAIL. I > you will propably get killed for services flood. No, you can try sendpass only for 3 single nicks in one hour. You will collect 72 per day, 504 per week, etc. This is just an example to detect how to spam. > > suggest not showing the address if HIDE EMAIL is set, or either > good idea. > requiring > > the user to /ns sendpass . > are you crazy?imaging changing to your nick ,doing /ns > sendpass yournick mymail@mymail.arpa and sending your > password to my e-mail account :] You did not understand. He suggests services require the correct email, not AN email address. > and for your previous post about the %S and %s.The %S it is > correct.it used to identify if we are reffering to a services > pseudoclient ( so it is %S ) or to any kind of other stuff ( > so it is %s) Again he is right, because notice_lang does not replace %S with pseudoclient name, but ONLY notice_help. In his case, the text was to sent with notice_lang, so %S is wrong, %s is right. It would be adviseable for all of us to read an email twice before seeing a need to reply to it. 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 | | ------------------------------------------------------------------ From gizm0 at mail.gr Thu May 30 22:52:28 2002 From: gizm0 at mail.gr (Panagiotis Kefalidis ( Gizm0 )) Date: Sat Oct 23 23:09:26 2004 Subject: AW: [IRCServices Coding] Concerns with sendpass Message-ID: <102278834801@mailserver.mail.gr> Óôßò Thu, 30 May 2002 21:31:06 +0200 "Yusuf Iskenderoglu" Ýãñáøå: > > Just to correct you, Panagiotis; > i was absolutelly off the point.i'm kind of tired today and this is the result.i apollogize for the incovinience. yusuf thanx for correcting me. :] (i'm still wondering if i spelled the whole mail right.) "I can see the darkness in your eyes." Gizm0.- ------------------------------------------------------------- http://www.mail.gr/ - Get Your Private Free Email Address! http://www.ringtone.gr/ - Ringtones & Logos for your mobile! From beng at nc.rr.com Thu May 30 14:36:05 2002 From: beng at nc.rr.com (Ben Goldstein) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] Correction in language file References: <00ca01c20808$8f5d1d40$0300000a@asi200> Message-ID: <013401c20822$918814c0$0300000a@asi200> Oops, forgot the other part.. modules/mail-auth.c: if (ni2->user) { notice_lang(s_NickServ, ni2->user, NICK_SETAUTH_USER_NOTICE, - ngi->email); + ngi->email, s_NickServ); Line 310 is missing last parameter (s_NickServ) That should do it. -- Ben Goldstein (beng@nc.rr.com) > en_us.l: > NICK_SETAUTH_USER_NOTICE > You must authorize your nickname before continuing to use it. An > author > Type ^B/msg %S HELP AUTH^B for more information. > > Should be %s. > > -- Ben Goldstein (beng@nc.rr.com) From beng at nc.rr.com Thu May 30 14:40:12 2002 From: beng at nc.rr.com (Ben Goldstein) Date: Sat Oct 23 23:09:26 2004 Subject: [IRCServices Coding] Correction in language file References: <00ca01c20808$8f5d1d40$0300000a@asi200> Message-ID: <013601c20822$d62870c0$0300000a@asi200> Oops, forgot the other part.. modules/mail-auth.c: if (ni2->user) { notice_lang(s_NickServ, ni2->user, NICK_SETAUTH_USER_NOTICE, - ngi->email); + ngi->email, s_NickServ); Line 310 is missing last parameter (s_NickServ) That should do it. O