2016-04-07 11:00:25 +02:00
|
|
|
/* modules/m_modules.c - module for module loading
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
*
|
|
|
|
* Copyright (c) 2016 Charybdis Development Team
|
2016-04-07 11:00:25 +02:00
|
|
|
* Copyright (c) 2016 Elizabeth Myers <elizabeth@interlinked.me>
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
* Copyright (c) 2016 Jason Volk <jason@zemos.net>
|
2016-04-07 11:00:25 +02:00
|
|
|
*
|
|
|
|
* Permission to use, copy, modify, and/or distribute this software for any
|
|
|
|
* purpose with or without fee is hereby granted, provided that the above
|
|
|
|
* copyright notice and this permission notice is present in all copies.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
|
|
|
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
|
|
|
|
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
|
|
|
|
* DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
|
|
|
|
* INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
|
|
|
|
* (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
|
|
|
|
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
|
|
|
|
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
|
|
|
|
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
|
|
|
* POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
2016-08-13 05:05:54 +02:00
|
|
|
using namespace ircd;
|
|
|
|
|
2016-08-23 02:37:07 +02:00
|
|
|
static void m_modlist(struct MsgBuf *, client::client &, client::client &, int, const char **);
|
2016-06-26 08:40:43 +02:00
|
|
|
|
2016-08-23 02:37:07 +02:00
|
|
|
static void mo_modload(struct MsgBuf *, client::client &, client::client &, int, const char **);
|
|
|
|
static void mo_modreload(struct MsgBuf *, client::client &, client::client &, int, const char **);
|
|
|
|
static void mo_modunload(struct MsgBuf *, client::client &, client::client &, int, const char **);
|
|
|
|
static void mo_modrestart(struct MsgBuf *, client::client &, client::client &, int, const char **);
|
2016-04-07 11:00:25 +02:00
|
|
|
|
2016-08-23 02:37:07 +02:00
|
|
|
static void me_modload(struct MsgBuf *, client::client &, client::client &, int, const char **);
|
|
|
|
static void me_modlist(struct MsgBuf *, client::client &, client::client &, int, const char **);
|
|
|
|
static void me_modreload(struct MsgBuf *, client::client &, client::client &, int, const char **);
|
|
|
|
static void me_modunload(struct MsgBuf *, client::client &, client::client &, int, const char **);
|
|
|
|
static void me_modrestart(struct MsgBuf *, client::client &, client::client &, int, const char **);
|
2016-04-07 11:00:25 +02:00
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
static void do_modload(client::client &, const std::string &);
|
|
|
|
static void do_modunload(client::client &, const std::string &);
|
|
|
|
static void do_modreload(client::client &, const std::string &);
|
|
|
|
static void do_modlist(client::client &, const std::string &);
|
2016-08-23 02:37:07 +02:00
|
|
|
static void do_modrestart(client::client &);
|
2016-04-07 11:00:25 +02:00
|
|
|
|
2016-09-06 01:05:16 +02:00
|
|
|
/*
|
2016-04-07 11:00:25 +02:00
|
|
|
struct Message modload_msgtab = {
|
|
|
|
"MODLOAD", 0, 0, 0, 0,
|
|
|
|
{mg_unreg, mg_not_oper, mg_ignore, mg_ignore, {me_modload, 2}, {mo_modload, 2}}
|
|
|
|
};
|
|
|
|
|
|
|
|
struct Message modunload_msgtab = {
|
|
|
|
"MODUNLOAD", 0, 0, 0, 0,
|
|
|
|
{mg_unreg, mg_not_oper, mg_ignore, mg_ignore, {me_modunload, 2}, {mo_modunload, 2}}
|
|
|
|
};
|
|
|
|
|
|
|
|
struct Message modreload_msgtab = {
|
|
|
|
"MODRELOAD", 0, 0, 0, 0,
|
|
|
|
{mg_unreg, mg_not_oper, mg_ignore, mg_ignore, {me_modreload, 2}, {mo_modreload, 2}}
|
|
|
|
};
|
|
|
|
|
|
|
|
struct Message modlist_msgtab = {
|
|
|
|
"MODLIST", 0, 0, 0, 0,
|
2016-06-26 08:40:43 +02:00
|
|
|
{mg_unreg, {m_modlist, 0}, mg_ignore, mg_ignore, {me_modlist, 0}, {m_modlist, 0}}
|
2016-04-07 11:00:25 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
struct Message modrestart_msgtab = {
|
|
|
|
"MODRESTART", 0, 0, 0, 0,
|
|
|
|
{mg_unreg, mg_not_oper, mg_ignore, mg_ignore, {me_modrestart, 0}, {mo_modrestart, 0}}
|
|
|
|
};
|
2016-09-06 01:05:16 +02:00
|
|
|
*/
|
2016-04-07 11:00:25 +02:00
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
mapi::header IRCD_MODULE
|
|
|
|
{
|
|
|
|
"Provides module management commands",
|
2016-09-06 01:05:16 +02:00
|
|
|
mapi::NO_FLAGS
|
|
|
|
//&modload_msgtab,
|
|
|
|
//&modunload_msgtab,
|
|
|
|
//&modreload_msgtab,
|
|
|
|
//&modlist_msgtab,
|
|
|
|
//&modrestart_msgtab,
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
};
|
2016-04-07 11:00:25 +02:00
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
// load a module ..
|
2016-04-07 11:00:25 +02:00
|
|
|
static void
|
2016-08-23 02:37:07 +02:00
|
|
|
mo_modload(struct MsgBuf *msgbuf_p, client::client &client, client::client &source, int parc, const char **parv)
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
if(!IsOperAdmin(&source))
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
sendto_one(&source, form_str(ERR_NOPRIVS),
|
|
|
|
me.name, source.name, "admin");
|
2016-04-07 11:00:25 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if(parc > 2)
|
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
sendto_match_servs(&source, parv[2], CAP_ENCAP, NOCAPS,
|
2016-04-07 11:00:25 +02:00
|
|
|
"ENCAP %s MODLOAD %s", parv[2], parv[1]);
|
|
|
|
if(match(parv[2], me.name) == 0)
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-08-23 02:37:07 +02:00
|
|
|
do_modload(source, parv[1]);
|
2016-04-07 11:00:25 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2016-08-23 02:37:07 +02:00
|
|
|
me_modload(struct MsgBuf *msgbuf_p, client::client &client, client::client &source, int parc, const char **parv)
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
if(!find_shared_conf(source.username, source.host, source.servptr->name, SHARED_MODULE))
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
sendto_one_notice(&source, ":*** You do not have an appropriate shared block "
|
2016-04-07 11:00:25 +02:00
|
|
|
"to load modules on this server.");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-08-23 02:37:07 +02:00
|
|
|
do_modload(source, parv[1]);
|
2016-04-07 11:00:25 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
// unload a module ..
|
2016-04-07 11:00:25 +02:00
|
|
|
static void
|
2016-08-23 02:37:07 +02:00
|
|
|
mo_modunload(struct MsgBuf *msgbuf_p, client::client &client, client::client &source, int parc, const char **parv)
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
if(!IsOperAdmin(&source))
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
sendto_one(&source, form_str(ERR_NOPRIVS),
|
|
|
|
me.name, source.name, "admin");
|
2016-04-07 11:00:25 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if(parc > 2)
|
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
sendto_match_servs(&source, parv[2], CAP_ENCAP, NOCAPS,
|
2016-04-07 11:00:25 +02:00
|
|
|
"ENCAP %s MODUNLOAD %s", parv[2], parv[1]);
|
|
|
|
if(match(parv[2], me.name) == 0)
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-08-23 02:37:07 +02:00
|
|
|
do_modunload(source, parv[1]);
|
2016-04-07 11:00:25 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2016-08-23 02:37:07 +02:00
|
|
|
me_modunload(struct MsgBuf *msgbuf_p, client::client &client, client::client &source, int parc, const char **parv)
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
if(!find_shared_conf(source.username, source.host, source.servptr->name, SHARED_MODULE))
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
sendto_one_notice(&source, ":*** You do not have an appropriate shared block "
|
2016-04-07 11:00:25 +02:00
|
|
|
"to load modules on this server.");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-08-23 02:37:07 +02:00
|
|
|
do_modunload(source, parv[1]);
|
2016-04-07 11:00:25 +02:00
|
|
|
}
|
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
// unload and load in one!
|
2016-04-07 11:00:25 +02:00
|
|
|
static void
|
2016-08-23 02:37:07 +02:00
|
|
|
mo_modreload(struct MsgBuf *msgbuf_p, client::client &client, client::client &source, int parc, const char **parv)
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
if(!IsOperAdmin(&source))
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
sendto_one(&source, form_str(ERR_NOPRIVS),
|
|
|
|
me.name, source.name, "admin");
|
2016-04-07 11:00:25 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if(parc > 2)
|
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
sendto_match_servs(&source, parv[2], CAP_ENCAP, NOCAPS,
|
2016-04-07 11:00:25 +02:00
|
|
|
"ENCAP %s MODRELOAD %s", parv[2], parv[1]);
|
|
|
|
if(match(parv[2], me.name) == 0)
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-08-23 02:37:07 +02:00
|
|
|
do_modreload(source, parv[1]);
|
2016-04-07 11:00:25 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2016-08-23 02:37:07 +02:00
|
|
|
me_modreload(struct MsgBuf *msgbuf_p, client::client &client, client::client &source, int parc, const char **parv)
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
if(!find_shared_conf(source.username, source.host, source.servptr->name, SHARED_MODULE))
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
sendto_one_notice(&source, ":*** You do not have an appropriate shared block "
|
2016-04-07 11:00:25 +02:00
|
|
|
"to load modules on this server.");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-08-23 02:37:07 +02:00
|
|
|
do_modreload(source, parv[1]);
|
2016-04-07 11:00:25 +02:00
|
|
|
}
|
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
// list modules ..
|
2016-04-07 11:00:25 +02:00
|
|
|
static void
|
2016-08-23 02:37:07 +02:00
|
|
|
m_modlist(struct MsgBuf *msgbuf_p, client::client &client, client::client &source, int parc, const char **parv)
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
|
|
|
if(parc > 2)
|
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
sendto_match_servs(&source, parv[2], CAP_ENCAP, NOCAPS,
|
2016-04-07 11:00:25 +02:00
|
|
|
"ENCAP %s MODLIST %s", parv[2], parv[1]);
|
|
|
|
if(match(parv[2], me.name) == 0)
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-08-23 02:37:07 +02:00
|
|
|
do_modlist(source, parc > 1 ? parv[1] : NULL);
|
2016-04-07 11:00:25 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2016-08-23 02:37:07 +02:00
|
|
|
me_modlist(struct MsgBuf *msgbuf_p, client::client &client, client::client &source, int parc, const char **parv)
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
do_modlist(source, parv[1]);
|
2016-04-07 11:00:25 +02:00
|
|
|
}
|
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
// unload and reload all modules
|
2016-04-07 11:00:25 +02:00
|
|
|
static void
|
2016-08-23 02:37:07 +02:00
|
|
|
mo_modrestart(struct MsgBuf *msgbuf_p, client::client &client, client::client &source, int parc, const char **parv)
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
if(!IsOperAdmin(&source))
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
sendto_one(&source, form_str(ERR_NOPRIVS),
|
|
|
|
me.name, source.name, "admin");
|
2016-04-07 11:00:25 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if(parc > 1)
|
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
sendto_match_servs(&source, parv[1], CAP_ENCAP, NOCAPS,
|
2016-04-07 11:00:25 +02:00
|
|
|
"ENCAP %s MODRESTART", parv[1]);
|
|
|
|
if(match(parv[1], me.name) == 0)
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-08-23 02:37:07 +02:00
|
|
|
do_modrestart(source);
|
2016-04-07 11:00:25 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2016-08-23 02:37:07 +02:00
|
|
|
me_modrestart(struct MsgBuf *msgbuf_p, client::client &client, client::client &source, int parc, const char **parv)
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
if(!find_shared_conf(source.username, source.host, source.servptr->name, SHARED_MODULE))
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
sendto_one_notice(&source, ":*** You do not have an appropriate shared block "
|
2016-04-07 11:00:25 +02:00
|
|
|
"to load modules on this server.");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-08-23 02:37:07 +02:00
|
|
|
do_modrestart(source);
|
2016-04-07 11:00:25 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
do_modload(client::client &source,
|
|
|
|
const std::string &name)
|
|
|
|
try
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
mods::load(name);
|
|
|
|
}
|
|
|
|
catch(const std::exception &e)
|
|
|
|
{
|
|
|
|
sendto_one_notice(&source, "%s", e.what());
|
2016-04-07 11:00:25 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
do_modunload(client::client &source,
|
|
|
|
const std::string &name)
|
|
|
|
try
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
if(!mods::loaded(name))
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
sendto_one_notice(&source, ":%s is not loaded", name.c_str());
|
2016-04-07 11:00:25 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
mods::unload(name);
|
|
|
|
}
|
|
|
|
catch(const std::exception &e)
|
|
|
|
{
|
|
|
|
sendto_one_notice(&source, "%s", e.what());
|
2016-04-07 11:00:25 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
do_modreload(client::client &source,
|
|
|
|
const std::string &name)
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2016-08-23 02:37:07 +02:00
|
|
|
do_modrestart(client::client &source)
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
/*
|
2016-06-18 07:59:15 +02:00
|
|
|
unsigned int modnum = 0;
|
|
|
|
rb_dlink_node *ptr, *nptr;
|
2016-04-07 11:00:25 +02:00
|
|
|
|
2016-08-23 02:37:07 +02:00
|
|
|
sendto_one_notice(&source, ":Reloading all modules");
|
2016-04-07 11:00:25 +02:00
|
|
|
|
2016-06-18 07:59:15 +02:00
|
|
|
RB_DLINK_FOREACH_SAFE(ptr, nptr, module_list.head)
|
|
|
|
{
|
2016-07-13 07:17:21 +02:00
|
|
|
struct module *mod = (module *)ptr->data;
|
2016-06-22 02:39:44 +02:00
|
|
|
if(!unload_one_module(mod->name, false))
|
|
|
|
{
|
|
|
|
ilog(L_MAIN, "Module Restart: %s was not unloaded %s",
|
|
|
|
mod->name,
|
|
|
|
mod->core? "(core module)" : "");
|
|
|
|
|
|
|
|
if(!mod->core)
|
2016-08-26 13:50:12 +02:00
|
|
|
sendto_realops_snomask(sno::GENERAL, L_NETWIDE,
|
2016-06-22 02:39:44 +02:00
|
|
|
"Module Restart: %s failed to unload",
|
|
|
|
mod->name);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2016-06-18 07:59:15 +02:00
|
|
|
modnum++;
|
|
|
|
}
|
2016-04-07 11:00:25 +02:00
|
|
|
|
|
|
|
load_all_modules(false);
|
|
|
|
rehash(false);
|
|
|
|
|
2016-08-26 13:50:12 +02:00
|
|
|
sendto_realops_snomask(sno::GENERAL, L_NETWIDE,
|
2016-06-18 07:59:15 +02:00
|
|
|
"Module Restart: %u modules unloaded, %lu modules loaded",
|
|
|
|
modnum, rb_dlink_list_length(&module_list));
|
|
|
|
ilog(L_MAIN, "Module Restart: %u modules unloaded, %lu modules loaded", modnum, rb_dlink_list_length(&module_list));
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
*/
|
2016-04-07 11:00:25 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
do_modlist(client::client &source, const std::string &pattern)
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
for(const auto &pit : mods::loaded())
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
const auto &mod(*pit.second);
|
|
|
|
if(pattern.empty() || match(pattern, name(mod)))
|
2016-04-07 11:00:25 +02:00
|
|
|
{
|
2016-08-23 02:37:07 +02:00
|
|
|
sendto_one(&source, form_str(RPL_MODLIST),
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
me.name,
|
|
|
|
source.name,
|
|
|
|
name(mod).c_str(),
|
|
|
|
ulong(0),
|
|
|
|
"*",
|
|
|
|
"*",
|
|
|
|
"*", //version(mod),
|
|
|
|
desc(mod));
|
2016-04-07 11:00:25 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
sendto_one(&source, form_str(RPL_ENDOFMODLIST),
|
|
|
|
me.name,
|
|
|
|
source.name);
|
2016-04-07 11:00:25 +02:00
|
|
|
}
|