Significant parts of the server<->server protocol have few sanity checks, so a malformed command can cause some very serious problems. Even with sufficient knowledge of the protocol (and there is a reference), /os raw is dangerous because we are only human, and typos DO (read: WILL) happen.
First of all, realize that many commands WILL desynch services from the uplink. A prime example is using /os RAW to set channel modes on someone. A desynch WILL occur because the MODE isn't echoed back, so anope thinks that the old mode state is still valid - when it isn't. The same is true if you raw a KICK, KILL or SVSKILL, since it is not echoed back. In that case, even worse scenarios can happen if services choke (read: crash) on what they see as a duplicate introduction or join of the user when he reconnects/rejoins... This is also true if RAWing SVS(2)MODE as the mode change isn't echoed back (except when using SVSMODE to clear channel lists) so anope won't, for example, see a user that has been given +o (even if given properly) as an IRCop. Far worse is if you RAW an SQUIT. Newer anope versions iirc understand PROTOCTL NOQUIT (meaning an SQUIT implies quits for everyone that would be lost). Either way, anope won't know the server has gone (along with everyone connected) and when the net resynchs, anope is going to have a TON of server and nick "collisions" to deal with.
As an extra note: bots joined into a channel a'la /os raw won't be seen by anope as in the channel. This means that when everyone else leaves, anope sees the channel as destroyed, and when it's next joined will try to do it's usual on-create stuff (reset topic, add modes from mlock, etc). This might be acceptable in standard cases. One potentially annoying problem can result from this however: if an AKICKed user or anyone otherwise forbidden to enter is the "first to join" even though every service bot is there, anope will attempt to join ChanServ in the channel to squat it (it may already be there, expect notices like "SJOIN for user already in channel" or stuff like that) for however long, after which it leaves (anope won't remember that ChanServ was already there).
Some possible additional scenarios that can result from this:
- (Maybe) Worst case scenario: Service uplink crashes. In this case, anope also exits when the uplink crashes; there might be data lossage but I cannot be sure on this. Specific cases include attempting to send OPER over the link, and possibly other commands (you might see some such cases appear in
http://bugs.unrealircd.org/).
- Worst case scenario if dealing with ban related commands is you accidentally ban *. Fortunately in this case, OperServ won't know about it or try to enforce it - so you can except tkl {} your way back on to /gline -* if you can. Your users won't be happy however.
- I've heard that using RAW to change a service's nick effectively breaks it. I could understand some good cases of using MODE to add extra usermodes (like making everything but NickServ +R, since really noone but registered+identified users should muck with ChanServ/MemoServ/etc). Don't use MODE for channels though - see above :P .
- Desynch cases as I've noted above.
Although I can think of no cases of outright delinkage by the ircd, services can be dropped when the ircd crashes (and if you play with raw a lot, you will crash it eventually ;) ).
