/connect services.brasirc.net ??? :) O post de hoje é só para IRCops, hehehe... usuários comuns dificilmente vão entender o que eu escrevi aqui. Hoje eu me diverti vendo quanta merda as pessoas são capazes de falar em GlobOps... incrível como chegam a ser IRCOps. A pérola de hoje foi o F-Lelo dizendo que dá pra usar /connect nos services, hehehe... Ok, vamos lá... explicando... :) Exceto os sistemas de Inteligência Artificial, nenhum programa "aprende" coisa alguma sozinho. Para que um programa seja capaz de executar uma ação, ele precisa, obrigatoriamente, ter alguma função em seu código que o "ensine" a executar essa ação. Por exemplo, se eu peço a versão dos services (/version services.brasirc.net), eles vão responder, pois eles possuem uma função capaz de "fazer o handle" dos requests de version. A função é essa: void m_version(char *source, int ac, char **av) { if (source) send_cmd(ServerName, "351 %s BrasIRC.NET Services-%s %s :%s -- %s", source, version_number, ServerName, version_flags, version_build); } Se eu "arrancar" essa função do código, os services simplesmente não saberão mais o que é um request do tipo version, e não vão mais responder. Da mesma forma, existem nos services funções para que eles possam "interpretar e entender" muitas outras mensagens, como stats, away (para que eles possam enviar dados sobre memos para o usuário), kicks, modes, motd, mensagens de mudança de nicks e muito mais. Outro exemplo: se eu removesse do código dos services a função m_nick, o NickServ não iria mais pedir as senhas dos usuários, simplesmente porque é essa função que, digamos, "ensina a ele o que é uma mudança de nick". Sem essa função, ele iria "ver" o usuário mudar de nick, mas não seria mais capaz de entender o que significa isso (se bem que não é o NickServ quem vê isso, mas essa é uma outra história). Pois bem: os services não possuem nenhuma rotina capaz de entender um pedido de connect enviado por um servidor para eles. Eles não esperam por /connects, nem são capazes de entendê-los quando os recebem. Além disso, os services são feitos para "morrerem" automaticamente, caso eles se deslinkem da rede por qualquer motivo. A rotina que "mata" os services faz parte do código original, e existe em todos os tipos de services. Ao desconectarem da rede, os services executam um services_shutdown(). Isso significa que, quando os services deslinkam, o processo deles cai e, portanto, não vai mais responder a coisa alguma. Duplo motivo para que o /connect não funcione. Imagine você tentando conectar no IRC sem nenhum programa capaz de conectar aberto, nem mIRC, nem bx, nem telnet, nem coisa alguma... vai conseguir connectar como? Nem sendo mágico... :) Um outro exemplo de mensagem que os services originais não são capazes de entender por completo é o SQUIT. Para que o nosso jupe estilo akill funcionasse mesmo com a rede alagada, foi preciso "ensinar" os services a esperarem pacientemente que o servidor jupado seja efetivamente squitado. Isso porque, quando a rede alaga, o squit demora para chegar até o seu destino. E para cuidar disso, nós tivemos que implementar uma nova rotina m_squit. Ok, então alguém diz: mas eu dei /connect nos services e funcionou! É sério, eu vi, eu juro que vi! Não querido. Você viu uma coisa e entendeu outra. O que rola é que, quando os services deslikam, o processo "morre". Exatamente por ele morrer, ele fica instalado na crontab da máquina, senão ele não volta nunca mais, correto? Pois bem, na BrasIRC, usamos um tempo de apenas 1 minuto para rodar o script que checa se o processo services está up. Assim, se os services caírem, no máximo 1 minuto depois da queda (ou um pouco mais, dependendo dos recursos da máquina) eles voltarão. E se eles voltam logo depois que alguém deu um /connect neles, isso cria a ilusão de que eles estão conectando graças a esse comando. Mas é só isso: pura ilusão, mais nada. Eles voltam por estarem na crontab, não por causa do comando /connect. Com ou sem connect, eles vão voltar de qualquer jeito, a menos que haja algum problema maior, que exigirá que um dos Services Roots entrem na máquina para checar o que está rolando de errado. Os FAQs dos diferentes services não trazem informação tão detalhada sobre esse assunto como a que eu coloquei aqui. Eles simplesmente dizem que é óbvio que um /connect não funciona, mas não explicam o motivo. Seja como for, para quem quiser ler mais sobre isso pra depois não sair falando imbecilidades pela rede e fazer papel de palhaço, eu sugiro os endereços abaixo: 1) http://www.ircservices.za.net/FAQ 1) e http://www.epona.org/faq/index.php?faqid=010 dizem: My IRC server is giving me messages like "Connection to services.whatever.net[127.0.0.1] activated" and then "Access denied -- no N line". Why? R.: This is typically caused by including a port number in the C:line for services, which tells your server to try to autoconnect to it (depending on the class (Y:line) settings). This is not what you want, because Services will connect to the server itself, BUT DOES NOT LISTEN FOR SERVERS TO CONNECT TO IT. The solution is to remove the port number from the C:line. 2) http://www.ircservices.za.net/FAQ 1) e http://www.epona.org/faq/index.php?faqid=011 dizem: When I say "/connect services.*", it doesn't work! R.: OF COURSE NOT. RTFM (Read The Fine Manual), and see the previous answer. O mais engraçado de tudo era ver o imbecil nitidamente convencido de que ele estava certo. O gênio brilhante havia acabado de entrar no delírio de que todos, até mesmo os próprios criadores dos services, estavam enganados e ele certo... na mente dele, os services devem possuir inteligência própria e aprender coisas sozinhos, hehehe. É... se as pessoas procurassem se informar melhor antes de falar bobagens, não passariam tanta vergonha... :)