|

KNOWLEDGEBASE
Setting Up psyBNC -
If you know nothing about bncs, a bnc is short for
a 'bouncer.' A bnc acts as a proxy for irc, allowing you to hide
your real IP address and use a vhost (vanity host - something like
'this.is.a.l33t.vhost.com'). What are the advantages of this?
Well, mainly there's just one important one: It'll stop stupid
packet kiddies from trying to knock you off the network. Everyone
hates getting disconnected, and with a bnc on a decent shell, you
should be pretty immune. Remember though: the kiddies can still
nuke you, but it is assumed that the shell provider has a
high-bandwidth line that allows it to withstand the numerous
packets. If your shell is on a 56.6, you'll still be screwed.
So... why psybnc? There are a variety of other
open source bnc's available for you to download, most notably
EZBounce and plain-ol BNC. Both of these do the exact same
basic thing as psybnc: hide your real host. But that's about
where the similarity ends. I've been using psy for a long time
now, and I love with all the features that it offers. To name a
few:
· You'll always be connected to irc. Even when
you close your irc client, psy will maintain your connection.
When you connect later, you'll instantly be back on the channels
you left. This also lets you hold your nick (if you need that
feature), or hold ops on a channel.
· psy hides your IP even in DCC sessions. In
other bncs, a direct client-client session is opened, thus
revealing your IP. In psy, the connection is bounced through the
shell, and your IP remains your dirty little secret ;)
· You can link multiple psy's together. This
allows you to share vhosts, and also create a small ircd, termed
the 'internal' network on the bncs.
· psyBNC now supports SSL. woohoo :)))
There are tons more features, but you can just
download the source and view the README.
Now... for the first part of this tutorial, the
Basic section, I assume you have little or no experience with
shells/irc. For the Intermediate section, though, I assume you can
hold your own. For most users, the Basic is as far as they need to
go, but all the fun stuff is a bit more complicated.
onfiguring and Compiling
Hopefully you have already downloaded the
source. If not, you can find it here:
http://www.psychoid.lam3rz.de.
After you have downloaded that, fire up your favorite ftp client
and upload it to the root directory of your shell. You could also
get the source by using lynx or wget. Example wget command:
wget
http://www.psychoid.lam3rz.de/psyBNC2.3.1.tar.gz
The next step is to decompress this file (.tar.gz
is kinda like a .zip file for all you windoze ppl out there). To
do this, type:
tar zxvf psyBNC2.3.1.tar.gz
Notice that it's case-sensitive. Everything in
unix is case-sensitive. Keep that in mind for everything in the
future.
If you typed the correctly, you should have a
psybnc directory on your shell. Change to it and see what
you have!
cd psybnc
ls -al
Now, this next part is where it gets a bit
harder. psyBNC includes a GUI for configuring the bnc. However,
this requires ncurses to be installed on your shell, something a
bunch of shells do not have. In my experience, most
flavors of linux have it installed, but some others
don't. So, give it a whirl. Type:
make menuconfig
If you get a GUI, congrats: the configuring
process is much easier. If not, well, welcome to my world ;) With
menuconfig, the GUI is very easy to follow: obviously an [X]
denotes that the option is selected, while [ ] indicates it's not.
For all those stuck doing it by hand, after each
option I explain how to set it. For all the compiling options,
everything is placed in the file config.h, which is found in the
psybnc directory. Just open that file with your favorite editor on
the shell (I use and recommend pico - You can edit the file by
typing:
pico config.h
In this file, if you want something added, it
has to be defined. Example: #define INTNET adds support for the
internal network.
The key for the section below is as follows:
Option Name
The #define line for config.h
A description of the option
Compiling options
Support Encryption
#define CRYPT
This encrypts all your passwords, and enables
support for channel encryption, relay encryption, etc... I
highly recommend you leave this enabled.
Encryption Type
#define BLOWFISH or #define IDEA
(default = Blowfish) Cryptographically
speaking, these ciphers are about equally secure. However,
Blowfish is much faster. You can read more about Blowfish
here Also,
IDEA is patent-protected - you should get permission before
using it!
Support Translation
#define TRANSLATE
This lets you type in english (or whatever
your language is) and have the text in the channel appear in a
different language. You'll have to see the README for more
information: I don't use this feature.
Support Internal Network
#define INTNET
This lets you use the internal ircd that psy
has. Think of it as a big partyline where you can set
modes/bans/topic/etc... I like it, and I recommend you leave it
enabled.
Support Traffic Logging
#define TRAFFICLOG
This enables support for logging channels when
you're not around. It can be handy, but it can also eat up your
shell disk space VERY fast. So be careful if you enable this.
(note: you can leave support for it enabled here, then disable
it after it is compiled by simply turning it off)
Support Linkage
#define LINKAGE
If you want your bnc to link to others (or
others to link to yours), enable this. I use it.
Support DCC Files / DCC Chat
#define DCCFILES and #define
DCCCHAT
Standard DCC features over IRC. Most people
use these features, so leave em be.
User Mode
#define MULTIUSER or #define
SINGLEUSER
Multiuser or Singleuser. If you're going to
share your bnc, set it to multi. If it's just you, set it to
Single.
Maxium users
#define MAXUSER n
Pretty self-explanatory. However note that
each network you add (if you use multiple networks) adds a
virtual user. Be sure to keep this in mind when setting a
max! (And really a max is pointless unless you are running an
anonymous bnc) (n = # of users)
Maximum connections
#define MAXCONN n
This is the number that each user can
have. They need at least 2 (incoming/outgoing) and more for
dcc's, multiple networks, etc. I suggest leaving it at 25. (n =
# of connections per user)
Support Scripting
#define SCRIPTING
psyBNC allows user-specific scripts. I will
not discuss that in this tutorial, but it doesn't hurt to leave
support for it enabled.
Support oIdentd
#define OIDENTD
If your shell supports it, this allows users
to define their own ident. Most don't support it. I don't use
it. (for more info on oIdentd:
http://ojnk.sourceforge.net/)
Use asynchroneous resolving
#define ???? definition unknown
EXPERIMENTAL!!Tells psy to use
asynchronous (as opposed to synchronous) DNS lookups. This is
not a tutorial on DNS so I will not get into it. Note this works
only if your system supports it!
Support Multiple IRC Networks
#define NETWORK
This allows users to connect to >1 network
with the same client. Hence, in one mirc session, the user could
be on efnet, dalnet and ircnet. I love this feature and
recommend you leave it enabled (even if you don't plan to use it
now).
Support proxy usage
#define PROXYS
If you want to further anonymize your
connection by bouncing mirc-->bnc-->proxy-->irc, enable this.
But since most irc servers check for open proxies, this won't
work in many cases.
Anonymous Bouncer Usage
#define ANONYMOUS
Want the whole world to use your bnc? Then
enable this! (not recommended)
No Permanent IRC-Connections
#define DYNAMIC
If this is enabled, psy will disconnect you
from irc when you disconnect rom the bnc. Otheriwse, you'll
always stay connected to irc unless you force it to quit.
Loglevel
#define LOGLEVEL n
3 different options here, choose your poison.
I prefer to leave them all enabled since I like to know
everything going on with my bnc. (define where n is: 0
= Errors, Warnings and Info; 1 = Errors and Warnings; 2 = Errors
only)
Use the 2.1.1 compatible
partyline #define PARTYCHANNEL
If you're going to be linking to old psy's,
this might be good to enable. But if you're the only bnc, or if
they're all > 2.2, no need to enable this option.
Version reply
#define CTCPVERSION "reply"
Set the reply psybnc will send when someone
sends you a CTCP VERSION query. (note: when you are connected to
the bnc, psy will be transparent, all ctcp's will be answered by
mirc. When you're not connected, psy will only answer to the
version ctcp as set by this option.) (psy defaults to: "psyBNC
2.3.1 by the most psychoid")
SSL-Path
#define SSLPATH "/path/to/ssl"
(default: wherever your openssl installation
has been detected) - If you wish the use SSL on your bnc, the
default here should be fine. However, if you have multiple
openssl installations for some reason, then define the path to
the one you want to use. If you do not want SSL compiled into
psyBNC, then specify something like /dev/null here. Note that
you can compile SSL support into your bnc and simply not use it.
SSL-SecLevel
#define SSLSEC n
(default: Check Certs and Keys (NOT
IMPLEMENTED)) - Sets the security level of your SSL setup. This
can be one of the following: None, Check Certs, or the default.
These different options correspond to values 0, 1 and 2
respectively for use in config.h. As with async DNS, this is not
an SSL tutorial. Note however that setting 'None' does NOT
disable SSL; it simply does not check client certificates. If
you're using SSL for encryption only, then you can safely set
this option to None. Furthermore, psyBNC has not yet implemented
client-checking functions.
Once you have all these options set, you have
two choices: If you're using menuconfig, skip to the next step. If
you're doing it manually, this is where you actually want to
compile your bnc. It's very easy to do. In the psybnc directory,
simply type:
make
It won't take long to compile. If you have
compiled with SSL enabled, you'll have to create a self-signed
certificate at the end of the compilation process. Simply follow
the prompts that you are given. The most common error is to
specify a wrong Common Name. According to certificate
standards, the common name must be a FQHN: Fully Qualified
HostName, i.e: psybnc.mydomain.com. Since the certifcate is simply
being used a an encryption seed and not as a validation of
identity, this is not really important - the cert is not being
signed a real CA anyway!
Configuring options
If you're using the GUI, all these options are
accessable under the Bouncer-Config part of the menu. If you're
not using the GUI, all these options are in psybnc.conf, which is
created in the psybnc directory after it is compiled. To edit
these options manually, just edit this file. The
Appendix has
the proper syntax for each option. The rest of this section will
cover the GUI method.
Before going through these options, do the
following: know the IP of your shell. for example, if you connect
to l33t.shell.com open up a console (or command prompt in
Win) and ping the hostname. You should see something like this:
-bash-2.05b$ ping
www.efnet.org
PING www.efnet.org (193.45.36.242): 56 data
bytes
64 bytes from 193.45.36.242: icmp_seq=0 ttl=49 time=132.975 ms
So if your shell was www.efnet.org (which I can
guarantee it is not!), the corresponding IP would be
193.45.36.242.
Also, choose a port for the bnc. Check the Terms
of Use of your shell - some companies require you to use a certain
port range. And if you're on a *nix shell, the port will have to
be higher than 1024 (unless you run the bnc as root, which is
certainly not recommended!). Ok, on to the options, same
basic format as the compiling options.
Listening ports
You have to tell the bnc where to listen. You
can have it listen on more than one port on the same IP, on
multiple IPs with the same port, etc. For most people, listening
on just one port on one IP is adequate. (the psy default is
31337, and you can leave it at that with no problems, but it is
always a good security practice to change the port). If you wish
to create an SSL listening port, precede the HOSTentry
with "S=" i.e.: PSYBNC.SYSTEM.HOST1=S=123.123.123.123
This will make the specified port(s) on 123.123.123.123 an SSL
port. PSYBNC.SYSTEM.PORT1=xxxxx should never have an "S=" in it.
Links
Don't worry about this now.
Bouncer Name
Name your bnc. Something like mypsy1
will work just fine.
Host Allows
Want to restrict access to certain IPs or
certian IP masks? This is the place to put those permissions.
psy will disallow access to anyone not listed here. To allow
anyone (provided they have the correct username and password)
set this to *.
Users
At this point, you want to just add yourself.
Adding other users will be discussed in more detail later. In
menuconfig, just select this, select New then follow
the directions. Remember that to connect to psybnc, your ident
in mirc must be set to your psybnc username. For all those
manual people, jump down to the
Appendix,
which is where you should be anyway.
DCC Host
The IP to use for all your DCC sessions (if
you defined DCC support). I recommend setting it to the same IP
that your bnc is listening on for simplicity.
Congrats, your setup is complete. If you haven't
done so already, it's time to compile your bnc by typing "make" at
the shell prompt in your psybnc directory. Then type "./psybnc" to
start the bouncer. Hopefully everything went smoothly and you're
ready to jump into the next section.
Setting up your Account
The first thing you need to do is connect to
your bnc. In your irc client, open up the connect dialogue box and
add in another server. Name it My BNC or something like
that, enter the IP and port, and enter the password that you chose
(either through menuconfig or in the conf file). Now make sure
that your ident is set to your username. It's also a good idea to
set your e-mail address to username@whatever.com. If psy
can't get an ident response from you, it checks your e-mail addy
as verification of the username. If everything goes well, you'll
see this when you connect:
-Welcome- psyBNC2.3.1
Now you need to get connected to irc: first, you
need to select your vhost. To see what vhosts are available, at
your shell prompt type:
vhosts
This command is only available if your shell
provider has created such a function, but in my experience 99%
have. For security reasons (?), there is no way to view the vhosts
in psy. After your vhost is selected, you'll need to add in some
irc servers, and set a few other options. the commands follow
below. All commands appear like this /mycommand,
everything else after it is an explanation. All brackets are for
my purposes, don't use brackets in any command!
/bvhost [vhost] --
(this command used to be /vhost) -- [vhost] is your vhost
in alpha form (ie, this.is.a.cool.vhost.com and not
127.0.0.1)
/addserver [server] :[port] -- server
can be in alpha or numeric form...
Once you add in the server, psy will
auto-connect to it in a short while. You can add in more servers
so that if one goes down, psy can reconnect to a different one.
Just use the command above again. For server managment:
/listservers -- lists
all the servers you have added
/delserver [n] -- deletes the server
with #[n] (as shown by the listservers command)
/jump -- disconnects you from your
current server and attempts to connect to the next server in your
list
/bquit -- disconnects you from the
server until you force it to connect
/bconnect -- connects you to irc
Now, remember that psy will keep you connected
to irc even when you're not connected to the bnc. So, these
commands are helpful:
/setaway [message] --
psy will display this message to all channels you're on when you
quit the bnc. It will NOT repeat this message (since that's gay).
To remove the message, just type /setaway
/setawaynick [nick] -- when you quit
the bnc, psy will auto-change your nick to the nick you set here.
When you reconnect, it'll auto change it back to what's shown in
the mirc nick.
OK, now for some more
commands that ppl find useful. Remember that ALL commands are in
the README file that came with psybnc. I'm not going to repeat all
of them.
/playprivatelog --
plays the log of all messages sent to you when you were
disconnected from the bnc. The log will be opened in a window
called -psyBNC.
/eraseprivatelog -- erases the
aforementioned log.
psy has a damn cool feature in that it allows
encryption. You can encrypt text sent to a channel or a person.
Each person needs to have the same key to view the text. This is
helpful if you're paranoid, or if you want to have a private
conversation in a public channel. (Why you wouldn't just pm is
beyond me ;) It also makes you look l33t lol.
/encrypt [password]
:[channel/person] -- make sure everyone you want to speak
with has the same key. And they need to be using psybnc as well.
duh.
/listencrypt -- lists your current
encryptions
/delencrypt [n] -- deletes encryption
#[n] as shown by the listencryption command.
User Management
Obviously, if you have your bnc compiled as
singleuser, this section is pointless for you. But for everyone
else, I'm sure you want to add in other users, delete them, etc...
Here's the commands to do it:
/adduser [user] :[real name]
-- the [user] is what the person will have to set their ident to.
The [real name] part is what ppl will see when doing a /whois. for
example:
/adduser jestrix :me love you long time
will show this in the first line of a whois:
jestrix is ident@vhost * me
love you long time.
/deluser [user] -- deletes the user.
/password [new pass] -- changes your
password. If you're an admin, you can change other ppl's
passwords:/password [user] :[pass]
/madmin [user] -- makes a user into an
admin (choose your admins carefully!)
/unadmin [user] -- removes admin rights
from a user.
/bwho --- see who is added to your
bouncer. Also shows if they're connected, what server they're
connected to, and what their IP is.
I recommend you secure your bnc even more by
restricting what IPs can connect to it:
/addallow [IP or mask]
--- lets whatever IP or mask you specify connect to the bnc. IPs
can be definite, ie. 12.12.12.34 or masked, 12.12.12.*. You can
also use hostnames and masks such as *.myisp.com.
/listallow --- lists the allowed
connections.
/delallow [n] --- deletes allow #n as
shown by listallow.
DCC Stuff
This section assumes that you compiled your bnc
with DCCFILE and DCCCHAT. If you did not, then you can do all your
dcc stuff as you normally would in your irc client, but remember
that your real IP will be revealed by doing this. Like I
stated before, the benefit of psyBNC is that it hides your IP
during DCC sessions, but in order to do this, your life gets a bit
harder. First, let's go over the basic DCC commands:
/dccchat [user] ---
opens a dcc chat session with the user you specify.
/dccsend [file] :[user] --- sends a
file to the person you specify. The file MUST be in
~/psybnc/downloads/USERx (where USERx is your user #. Not sure
what your user # is? do a /bwho
/dccanswer [user] --- if someone sends
you a dcc chat request, psy will inform you through a notice. You
must then type this to accept the request.
/dccget [file] :[user] --- gets a file
that was dcc'd to you by someone. This file will be stored in the
~/psybnc/downloads/USERx directory.
/dccsendme [file] --- tells psy to send
you the file you specify. Use this after you get a file from
another user and then want to get it from your shell. This is the
only way people without shell access can get their files.
/listdcc --- lists all dcc's
/dcccancel [n] --- cancels dcc # n as
shown by /listdcc
If you wish to use SSL encrypted DCC sessions,
precede the value of the command with "S=" ie:
/dccchat S=l33th4x0r - Note that the other person must have
an SSL capable client.
Now for the cool stuff :) my favorite feature of
psy is its ability to stay permanently connected to a bot through
a DCC, and to ask this bot for ops. As anyone who has experience
with running a botnet knows, one of the easiest ways for a channel
to be taken over is to have some idiot /msg [bot] OP [password],
when the bot's nick was taken by someone else. With psy, however,
the askop request can be done two ways: through the partyline when
a DCC is initiated, or through a msg that first checks the mask of
the person being sent the request. Sweet, eh? So, the commands to
do it:
/adddcc [botname] [username]
[password] :[host]:[port] --- The botname is obviously the
name of the bot, The username and password are your personal l/p
that you use to gain access to the bot's partyline. The host is
the host of the bot. It can be either the alpha-form, or the
actual IP address. I prefer the actual IP address, since it's
possible DNS can be down. And finally, the port is the port that
the bot listens on for user connections. Some bots listen
for other bots on one port and for users on another, so make sure
you get the right one :)
/listdcc --- lists all dcc's
/deldcc [n] --- deletes dcc # n as
shown by /listdcc
Now, for the askops part: This part assumes you
added in a DCC to the bot as shown above. If you don't have
partyline access, you can still add an askop, but I'll get to that
later.
/addask [#chan] [password]
:-[botname] --- The chan is the channel you want to get ops
on, the password is your password, and the bot's nick, preceded
with a :-, is the bot which you have a dcc enabled to.
/listask --- lists all the askops you
have
/delask [n] --- deletes askop # n as
shown by /listask
Now, if you don't have partyline access, you can
add the askop in this way:
/addask [#chan] [password]
:[bothost] --- where chan is the channel you want to be
opped on, your password is your password (duh), and the bothost is
the bot's hostmask. A hostmask, for the uninformed, is formed like
this: username!ident@host. Since a bot is set to use a different
nick if someone takes their default, set the host for something
like: *!mybot@damn.cool.vhost.com.
Multiple Networks
One of my other favorite things about psyBNC :)
Do you have a bunch of channels you hang in on efnet, but also one
or two channels on dalnet that you like to go to? If you're like
me, you do...but you alo hate having multiple mirc sessions open.
Fret no more! psyBNC can solve your problems by allowing you to
connect to more than one network with the same mirc client. For
this section I'll assume that you're familiar with most of the
commands in psy. If not, get familiar with them before you try to
do this. Ok, let's get into the commands.
The first thing you need to do is add in another
network:
/addnetwork [name]
--- adds in a network with the name you specify. Keep in mind that
network names are case-sensitive. Furthermore, you'll be typing
the name a lot, so if you're adding in dalnet, use the name
dal or dn or something similar.
Once you have the network added, you need to
choose your vhost for that network. If you don't choose one, it'll
default to the IP the bnc is on, usually something gay like
"my-shell-company.com". So:
/bvhost [network]~[vhost]
--- sets your vhost on the network you specify.
See this command? This is the format for all
commands used on multiple networks. Simply prefix the syntax of
the command with [network]. So, to give some other examples:
/addserver dn~irc.dal.net:6667 --- adds
in the server irc.dal.net with port 6667 to the dn
network.
/join dn~#fxp --- joins #fxp on network
dn. (btw, I hear that some freaky ppl hang in this particular
channel ;)
/msg dn~joeschmoe beeyatch --- sends
the message "beeyatch" to the user with the nick joeschmoe on
network dn.
Now, some weird things about multiple networks:
· Your nick in the nicklists for channels on other networks will
show the nick you're using on your primary network. So, even if
you do: /nick dn~TwatMuffin, even though other ppl will now see
you as TwatMuffin in their list, you'll see yourself as jestrix,
or whatever nick you use.
· If you get opped/voiced in a channel, you won't see it in the
nicklist. You'll just appear to be a regular schmoe.
· Let's say JoeSmith is in #chat on efnet, your primary network.
You head over to dalnet, and he's there in #fxp. Everyone else in
#fxp will look like dn~BobJones, but JoeSmith will be just
JoeSmith. If you try to msg him by dbl-clicking on his nick int he
dalnet channel, you'll really be sending a msg to him on efnet.
You have to use dn~JoeSmith to talk with him on dalnet.
Some final things. Maybe you don't always want
to be on more than one network. I prefer to always be on efnet,
and then head to my other networks when I want to talk with ppl
there.
/bconnect [network]~
--- connects you to the network you specify (assuming you have
servers added for that network)
/bquit [network]~ --- quits you from
that network. You'll still be connected to your primary network.
Note, if you do /bquit, you'll be
quitted from all your networks.
/switchnet [new network] :[current network]
--- This command will let you switch your primary network. By
doing this, you won't have to prefix all your commands with the
~net syntax.
For example, let's say that you are on EFNet and DalNet. Efnet is
your primary network (you dont need to prefix anything with the ~
format) and DalNet is added as ~dn. If you currently did
/msg jestrix, you would be messaging
jestrix on efnet.
If you do /switchnet dn :ef your
current network will be assigned to dn - DalNet. Now if you
/msg jestrix you will get jestrix on
DalNet. To msg him on EFNet, you would have to do
/msg ef~jestrix - since ef was
the prefix you assigned in the switchnet command. To switch back
to your original config, you'd do: /switchnet
ef :dn
OK, multiple networks also includes the psy
internal network. Think of it as an ircd inside your bnc. By using
the network name int you can create private channels that
only ppl connected to your bnc can access.
For example, /join int~#partyline will
have you join the internal channel #partyline. You can set
modes/ops/topic in the internal channels just like you would on a
normal channel. do a whois on someone in an internal channel, it
looks neat ;)
You can also privately msg other people connected to your bnc:
/msg $[nick]. Prefix it with a $ and
psy will send it directly to the person on the bnc; it will not
pass through the irc server. (So if you both are on SSL-enabled
clients/bncs - the message is perfectly secure in transit!)
Linking
A cool aspect of psy is the ability form a psy-net
through the linkage of multiple psybncs. The benefit of this is to
create a private internal network secure from snooping, and secure
from takeovers! Furthermore, you can let ppl on other bouncers use
your machine's vhosts if you wish. As you should have realized by
now, preceding an IP with S= creates an SSL port.
So, to create a link to another bouncer:
/linkto [name of other bnc] :[IP]:[port]
The other bouncer would have to do the
following:
/linkfrom [name of other bnc] :[IP]:[port]
To view all your links:
/listlinks
I love to have everything encrypted, including
my links. To create an encrypted link:
/setlinkkey [link #] :[password]
After doing this on both psy's, do:
/relink [link #] on either bouncer to
reset
To enable the sharing of vhosts:
/relaylink [name of other bnc] :n ---
where n=0 to disable vhost sharing; 1 to enable it.
Final note: If you use hostmasks to restrict
connections to your bnc, you must add the other bnc's IP as an
allowed host!!
Appendix
For one reason or another, you might want to
edit your psybnc.conf (especially if menuconfig doesn't work for
you). So, here are the applicable lines and what they mean. I'm
sure I've missed a few lines, so if you find anything and know
what it does, please email me at jestrix(at)jestrix(dot)net. Note
that all the variables in psybnc.conf are CAPITALIZED and
that there are no spaces on either side of the equal sign.
Variables are shown in
this style.
###SYSTEM SETTINGS###
PSYBNC.SYSTEM.PORT1= The port your
bnc is going to listen on. use a PORTx variable if you want
multiple ports.
PSYBNC.SYSTEM.ME= The name of your
bouncer.
PSYBNC.SYSTEM.HOST1= The IP your bnc
is going to listen on. Use HOSTx for multiple hosts. If you want
an SSL port, Put an 'S=' before the IP.
PSYBNC.SYSTEM.DCCHOST= The IP that
will be used for DCC sessions.
PSYBNC.HOSTALLOWS.ENTRY0= The first
IP that will be allowed to connect to your bouncer. Use *;* for
everyone. This can include masks. The first * indicates the IP,
not sure what the * after the ; denotes... can't find anything
anywhere about it.
###USER SETTINGS###
(note that USERx can be substituted for USER1 where x
is an integer)
USER1.USER.LOGIN= The login name for
the user (ident)
USER1.USER.NICK= The nick the user
will use on irc.
USER1.USER.USER= The 'real name' of
the user (what appears in the whois)
USER1.USER.PASS= The password of the
user (this will be shown in encrypted form; if you change the
password in psybnc, then restart it, the password will become
encrypted.)
USER1.USER.RIGHTS= 0-not an admin;
1-an admin
USER1.USER.ACOLLIDE= 0-disable
anti-collide; 1-enable anti-collide
USER1.USER.SYSMSG= 0-Do not show
system messages to the user; 1-Show them
USER1.USER.VHOST= The user's vhost
USER1.USER.AWAYNICK= The user's away
nick
USER1.USER.AWAY= The user's away msg
USER3.USER.LEAVEMSG= The message
shown when you disconnect from the bnc
USER1.USER.VLINK= (0/1) Not sure what
this does (default =0)
USER1.USER.PPORT= (0/1) Not sure what
this does (default =0)
USER1.USER.PARENT= (0/1) Not sure
what this does (default =0)
USER1.USER.QUITTED= 0-User is
connected to irc; 1-User is quitted
USER1.USER.DCCENABLED= 0-dcc is
diabled; 1-dcc is enabled.
USER1.USER.AIDLE= 0-anti-idle is
disabled; 1-it's enabled.
USER1.USER.LEAVEQUIT= 0-when the user
disconnects from the bnc, they stay on all their channels; 1-when
they quit, they leave all the channels, but still stay connected
to irc.
USER1.USER.AUTOREJOIN= 0-if you get
kicked when not on the bnc, psy will not rejoin the channel; 1-psy
sill rejoin the channel for you if you get kicked.
USER1.USER.LASTLOG= (0/1) Not sure
what this does (default =0)
USER1.SERVERS.SERVER1= The first
server of the user.
USER1.SERVERS.PORT1= The port for
server number 1.
USER1.CHANNELS.ENTRY0= The first
channel the user wants to sit on.
USER1.CHANNELS.KEY0= The key for the
first channel. (This is encrypted as of version 2.3.0)
USER1.INTCHANS.ENTRY0= An internal
channel the user wants to sit on.
USER1.AOP.ENTRY1=Entry for someone to
get ops from your client in the form of hostmask;password. (not
covered in this tutorial)
###LINKAGE STUFF###
LINKS.LINK1.PORT= Port for link 1
LINKS.LINK1.NAME= name of the otehr
bnc
LINKS.LINK1.IAM= name of the other
bnc (redundant?)
LINKS.LINK1.HOST= IP of the link
LINKS.LINK1.PASS= Password for the
link (used only by the bncs)
LINKS.LINK1.ALLOWRELAY= 0-Do not
share vhosts; 1-Allow the sharing of vhosts
LINKS.LINK1.CRKEY= Key set by
negotiation between the bncs
LINKS.LINK1.TYPE= 0-Your bouncer
links to theirs; 1-Their bouncer links to yours.
###DCC AND ASKOP STUFF###
(note: I don't recommend editing any of these variables through
psybnc.onf -> use the commands in mirc.
USER1.DCC.ENTRY0= Stuff pertaining to
DCC #0
USER1.ASK.ENTRY0= Stuff pertaining to
AskOp #0
Setting Up Eggdrop
Recommended Websites
www.egghelp.org & www.egginfo.org
If you're experienced with the Unix shell environment and don't
think you need to read all the stuff on this page, follow this quick
guide to installing Eggdrop (otherwise, proceed straight to
Getting the
Eggdrop Source):
1) Download
eggdrop1.6.18.tar.gz from the
eggheads ftp.
2) Telnet and FTP to the shell.
3) Upload eggdrop1.6.18.tar.gz via FTP.
4) In telnet type tar zxvf eggdrop1.6.18.tar.gz
5) Type cd eggdrop1.6.18
6) Type ./configure
7) Type make config (compiles all modules) or
make iconfig (allows you to select the modules to compile).
8) Type make
9) Type make install DEST=/home/name/botdir
10) Switch to the botdir and edit the sample config file
eggdrop.conf, then rename it to something appropriate (e.g.
botnick.conf).
11) Type ./eggdrop -m <config file>
Note: Eggdrop requires Tcl to compile. If the server does
not have Tcl installed, you will need to
download
and install it.
There are many different versions of Eggdrop available for
download from various FTP sites. Three major versions of Eggdrop are
currently in use - 1.1.5, the 1.3/1.4 series, the
1.6 series. Other versions include the 0.9 series, 1.0 series,
1.2.0, and Eggdrop2, but these aren't used much any more.
1.1.5, which is now more than eight years old, is used by
some experienced users who have become comfortable with that version
and may have spent much time applying their own modifications to
make it work the way they want, and therefore don't wish to move to
a newer version. Some people consider 1.1.5 to be the most stable
and least buggy version of Eggdrop, in no small part due to the
failure of 1.2 to gain acceptance and many bugs early on in the
development of 1.3 series. But later versions of the 1.3 series were
more refined and better overall than the ageing 1.1.5.
Before 1.6, the 1.3/1.4 series was the main version of
Eggdrop in use. The last version in the 1.3 series was 1.3.28,
before it was renamed and became the 1.4 series as part of a new
version numbering system (1.4.0 comes right after 1.3.28). The last
in the 1.4 series is 1.4.5, and is a very stable bot. Some people
who prefer the lower memory footprint and simpler configuration of
the 1.3/1.4 bots are still using versions in this series.
But the best version of Eggdrop, for most people, is the current
1.6 series. This was in development for some time (during
which it was known as the 1.5 series), so it was quite refined and
stable by the time 1.6.0 was released. The current version is
1.6.18, and it is the most complete, feature-rich and functional
version of Eggdrop. If you're just starting out with Eggdrop, you
should use 1.6.18.
The Eggdrop2 bot was a substantial rewrite of Eggdrop in the C++
language and with an even more modular structure. However, it was
considered to be quite buggy, and its developers eventually
abandoned Eggdrop altogether as users stuck with the 1.3 series,
which was further developed by a new team. Most 1.4/1.5/1.6 series
versions are actually newer than Eggdrop2, and Eggdrop2 should not
be confused with the upcoming 2.0 series currently in development.
Eggdrop is distributed primarily on FTP servers in tarball format
(with the .tar.gz filename extension), with the version number in
the filename. The Eggdrop 1.4.5 source, for example, would be named
eggdrop1.4.5.tar.gz.
www.egghelp.org's
file area contains the latest versions of Eggdrop, as well
as important older releases.
ftp.eggheads.org/pub/eggdrop/ is the official site for the
latest releases of Eggdrop 1.3, 1.4 and 1.6.
You can download these directly to your shell using the shell's
FTP client as
described here, but I recommend you download Eggdrop to
your system (then upload it to the shell) so that you have a local
copy of the config file, documentation, etc. to refer to when needed
(you can use 7-Zip to
unzip the .tar.gz file on your system). Note that if you download
Eggdrop with an old version of Internet Explorer or Netscape, the
filename may be corrupted into something like eggdrop1_4_5_tar.tar
once it's downloaded. If that happens, make sure you change it back
to eggdrop1.4.5.tar.gz.
Installing Eggdrop is a relatively simple process provided your
shell has the required tools for successful compilation. On most
commercial shell accounts which allow Eggdrop bots you won't have
any problems with installation, but on some private boxes or a shell
on your ISP you may experience errors during compilation.
Below is a step by step guide to the installation process. These
instructions apply to 1.6 bots. It assumes you will be installing
eggdrop1.6.18.tar.gz, so just change the numbers if you are
installing another version (in the 1.6 series, that is -
installation of 1.4 and older versions varies slightly from 1.6).
1) Put the Eggdrop source on your shell using one of the
specified
download locations, either by downloading the
eggdrop1.6.18.tar.gz file to your system then uploading it to the
shell via FTP (recommended), or downloading it directly to the shell
using the shell's FTP client. You don't need to put the .tar.gz file
in its own directory (it'll be done automatically in the next step).
2) Telnet to the shell (if you haven't already), and type
tar zxvf eggdrop1.6.18.tar.gz (if this doesn't work, try
gunzip eggdrop1.6.18.tar.gz then tar xvf eggdrop1.6.18.tar).
This will extract the Eggdrop source into its installation
directory, named 'eggdrop1.6.18'.
3) Type cd eggdrop1.6.18 to switch to the directory
the Eggdrop source was extracted to.
4) Type ./configure (that's a period followed by a
slash followed by the word 'configure'). This makes sure the shell
has all the right tools for compiling Eggdrop, and helps Eggdrop
figure out how to compile on the shell.
5) When configure is done, type make config. This
sets up which modules are to be compiled. For a more efficient
installation, you can use make iconfig to select the modules
to compile, but if you're not sure just use make config.
6) Type make. This compiles the Eggdrop. The
process takes around two minutes or less on fast systems, longer on
slow systems.
7) Type make install DEST=~/botdir. This will
install Eggdrop into a directory named 'botdir'. You can change 'botdir'
to anything you like.
Note that in some cases you may need to specify the full path,
e.g. make install DEST=/home/cooldude/botdir - using the ~
character in make install won't always work. You can get the
full path by typing pwd.
8) Switch to the root of your directory using cd ~
then type chmod 700 <botdir> (where <botdir> is the directory
you installed the bot to). This is important to keep the contents
your bot directory hidden from prying eyes.
9) You can safely delete the installation directory named
'eggdrop1.6.18' (to do this, type cd ~ then rm -rf
eggdrop1.6.18) that was created previously, although some people
may find it handy to keep that directory for performing additional
or future installations of the same version without recompiling.
That's it! Eggdrop is now installed into its own directory
on the shell. It's time to edit the configuration files to make
Eggdrop work the way you want it to.
There are two files you will need to edit before you can start up
your Eggdrop - the configuration file and (optionally) the botchk
file. You can find the example configuration file in the directory
you extracted the Eggdrop source to, under the name 'eggdrop.conf',
and the 'botchk' file can be found in the /scripts subdirectory. If
you downloaded Eggdrop to your system, you can unzip the tarball (.tar.gz)
file to its own directory using 7-Zip or a similar program, and view
the example config file, botchk file, and all the documentation
files locally. You can use Notepad to edit these files, although
it's sometimes desirable to use an editor that supports the Unix
file format such as EditPlus.
Previous versions of the 1.6 series of Eggdrop came with
eggdrop.simple.conf, eggdrop.advanced.conf, and
eggdrop.complete.conf, with the simple one being the best
sample configuration file for new users. This has been changed since
1.6.13, and there is now only the single, complete sample config
eggdrop.conf. While this makes things simpler for developers and
helpers, the complete config is over 1000 lines long and can be
overwhelming for people new to Eggdrop. I will soon be releasing a
version of my
simple.conf (which I originally wrote for Eggdrop 1.3/1.4)
for 1.6, but in the meantime you're stuck with editing the complete
config file. If you want to take full advantage of all Eggdrop has
to offer, you will eventually need to spend the extra time it takes
to go through and understand many of the options in the complete
config file anyway.
You should first rename the sample config file to something other
than "eggdrop.conf". Giving it the name of the bot's nick (e.g.
NiceBot.conf) is quite common. In the config file, you set up the
IRC servers you want the bot to use, the channels you want the bot
to be in, and set Eggdrop's options to suit your needs. Eggdrop has
many options to configure, and editing the configuration file can
take some time. I recommend you go over the entire config file to
ensure the bot will be configured properly for your needs. All of
the options in the config file have written explanations - be sure
to read them carefully. Some of them can be a little bit vague,
though.
If you're editing the config file on your system (usually a
better idea than editing it on the shell as that can be rather
cumbersome) you'll need to upload it to your bot's directory when
you're done.
Below I elaborate on and make some recommendations for many of
the settings, but it is not a complete list of settings. You'll
probably notice many of the options are commented out (i.e.
preceded by the # (hash) character) - a commented out setting
can either mean the setting is not used or it's set to the default
setting. You can uncomment the setting by removing the hash. Many of
the options can be set to either 0 or 1 - 0 typically
means the option is disabled, while 1 means enabled.
Note that if you're using a version of Eggdrop older than 1.3.27,
some of the settings below may not apply -- if it's not in the
complete sample config that comes with your version of Eggdrop, then
the setting is not supported. If you're editing my
simple.conf
rather than the complete config file, you can skip the descriptions
below as they mainly cover many of the more complex options not
available in simple.conf.
set username: if your shell runs identd (most do), then
you should set this to your account login name.
set my-hostname and set my-ip: you'll need to set
one of these if you want your bot to use a
vhost. The
my-hostname setting is the vhost, e.g. linux.niceshells.net, while
my-ip is the IP address of the vhost, e.g. 206.343.63.217. You don't
need to set both of these, but I recommend you do so
as it can help if the shell is having problems with DNS. Setting
these can also help solve userfile transfer problems.
logfile: keeping logs is a good idea. Generally, you
should have one log for bot stuff, and one log for each of your
channels. For bot stuff, add the line logfile mcobxs * "botnick.log"
to the config. For channels, add logfile jkp #donkeys "#donkeys.log",
logfile jkp #horses "#horses.log", etc. Make sure you remove
the sample logfile lines for the channel #lamest. If you'd like to
put your logfiles in their own directory, specify the directory in
the log name (e.g. logfile jkp #donkeys "logs/#donkeys.log"
to write the logfiles in the /logs directory).
set sort-users: by default, userfile entries are sorted in
the order each user is added, from first to last. Setting this to
1 will make the userlist sort itself based on user flags. Both
sorting methods can be just as useful as the other - I recommend
leaving this set to 0 to start with.
listen 3333 all: you will almost certainly want to change
this, as 3333 will probably be in use if there are other Eggdrops
running on the machine. Generally, you can choose any port from 1024
to 65535, but the 49152-65535 range is best as these are the
private/dynamic ports least likely to be reserved by other
processes. You can choose not to have a port by commenting this line
out, but that will prevent any telnet connections to the bot (you
won't be able to use the bot as a hub, won't be able to telnet to
the bot yourself, and the bot won't respond to /ctcp botnick CHAT
requests).
set protect-telnet: setting this to 1 is strongly
recommended for security reasons.
set require-p: this is a useful feature allowing you to
give party line access on a user-specific basis. I recommend setting
it to 1.
set stealth-telnets: when you telnet to your bot, it will
usually display the bot's nickname and version information. You
probably don't want people seeing this info if they do a port scan
on the bot's shell. Setting this to 1 will prevent the bot
from displaying its nickname and version when someone telnets to it.
set dcc-flood-thr: this setting determines the number of
lines per second you can send to the party line before being booted.
It can be a pain in the butt when you want to paste multiple lines
on the party line, so you may want to increase this to something
like 5 or 10.
set hourly-updates: it's a good idea to change this from
the default setting of 00, since lots of other bots are
already using 00 and putting a lot of stress on the shell at that
time. Choose something that isn't a multiple of 10 (e.g. 03,
37, and 56 are examples of good settings).
set notify-newusers: set this to the nick you will have on
the bot. This setting isn't really used if you have learn-users
switched off.
set owner: you should only put one person in this list -
yourself. Set it to the nick you will have on the bot. Do NOT leave
it set to the default "MrLame, MrsLame".
set default-flags: these are the flags automatically given
to a user when they introduce themselves to the bot (if
learn-users is on) or when they're added using .adduser.
If you don't want the user to be given any flags initially, set this
to "" or "-".
set remote-boots: the default setting of 2 can
result in annoying boots from the party line (which is kind of like
being kicked from an IRC channel). You should probably set this to
0 or 1.
unbind dcc n tcl *dcc:tcl and unbind dcc n set *dcc:set:
these lines unbind the .tcl and .set commands.
It's a good idea to leave these lines alone, as the .tcl and .set
commands can be a security risk since they provide access to your
shell account through the bot. These commands are only really useful
if you plan on writing Tcl scripts.
set must-be-owner: if you have the .tcl and .set commands
enabled, you should definitely set this to 1. In 1.3.26 and
later, you can set it to 2 for even better security.
set chanfile: the chanfile allows you to store 'dynamic'
channels so that the bot rejoins the channel if restarted. Dynamic
channels are those you make the bot join using the .+chan
command - they aren't defined in the config file. The chanfile is
good if you frequently add/remove channels from the bot, but can be
a pain if you only like to add/remove channels using the config file
since settings stored in the chanfile with overwrite those set in
the config. You can choose not to use a chanfile by setting it to
"".
channel add: this is the command you use to add channels
to the bot. There are lots of options for this command. Channels are
added in the following format:
channel add #donkeys {
options
}
channel set #donkeys +option -option
channel add #horses {
options
}
channel set #horses +option -option
All the different options and channels settings are shown in the
examples in the config file. Make sure you remove the example
entries for #lamest and #botcentral.
set nick: this is what you use to specify your bot's
nickname. I recommend against using [ ] { } \ character's in
the bot's nick, since these can cause problems with some Tcl
scripts, but if you'd like to use them, you'll need to precede each
of those characters with a backslash in the setting, e.g. if you
wanted your bot to have the nick [NiceBot], use set nick "\[NiceBot\]".
set altnick: if you want to use [ ] { } \ characters in
the bot's alternate nick, follow the backslash rule described
previously.
set servers: you should specify multiple servers in this
list, in case the bot is unable to connect to the first server. The
format for this list is shown below.
set servers {
irc.chitchat.com:6667
irc.talkworld.com:6665
irc.nice.net:6667
}
Wherever possible, you should use a port other than 6667 (connect
to the server and type /motd to see a list of available
ports). You should use servers that allow bots (some shells have
rules enforcing this), but unless your shell's policy says otherwise
you may also wish to use non-bot servers as a backup in case your
IRC network has very few bot servers your bot is able to connect to
(but place the servers that allow bots at the top of the list).
set use-ison: leave this set to 1, as setting it to
0 will make your bot use the 'trace' command and may get your
bot k:lined (banned) from a server.
set strict-host: if this is set to 0, Eggdrop will
ignore the tilde in idents starting with ~. Setting it to 1
is a little more secure, but it can be a pain when it comes to user
hostmask management. If you're not sure how you should set this,
just leave it set to 0.
set server-cycle-wait: by default, Eggdrop waits 60
seconds between connection attempts to servers. This is quite a long
time, but it is necessary to prevent 'throttling' on Undernet
servers (if a server gets too many connection attempts from a
particular host within a short period of time, it will block all
connections from that host until there's been a break in connection
attempts). If you use Undernet and you're sharing a shell with lots
of other bot users, leave this set to 60. Otherwise, it's a
good idea to decrease this to something like 20.
set trigger-on-ignore: setting this to 1 diminishes
the usefulness of Eggdrop's ignore feature. I recommend you leave it
set to 0.
set bounce-bans: setting this to 1 makes the bot
remove any bans set by a server.
set bounce-modes: setting this to 1 makes the bot
remove any modes set by a server.
set learn-users: this is an important setting that
determines how users will be added to your Eggdrop. If set to 1,
people can add themselves to the bot by sending 'hello' to it (the
user will be added with the flags set in default-flags). If
set to 0, users cannot add themselves - a master or owner
must add them using the .adduser command.
unbind msg - hello *msg:hello and bind msg - myword *msg:hello:
these allow you to change the 'hello' command to something
different. Change myword to the name you the hello command
you want. If you have learn-users set to 0, this
command is only used for when you first introduce yourself to the
bot.
unbind msg - ident *msg:ident and unbind msg - addhost
*msg:addhost: these lines unbind the ident and addhost
commands. You will almost certainly want to rebind the ident
command, either by commenting out the unbind line (this will enable
the default 'ident' msg command) or by binding it to a new command.
It's a good idea to change the command for extra security. To bind
it to another command, let's say 'horse', you would add the line
bind msg - horse *msg:ident.
set dcc-block: although the example config file recommends
you set this to 0 (turbo-dcc), this may cause DCC transfers
to abort prematurely. If you'll be using DCC transfers a lot, set
this to 1024.
loadmodule uptime: read my
uptime module
description for a better idea of what this module is for.
Finally, be sure to remove the 'die' commands from the config
(there are two of them 'hidden' in various places), or the bot won't
start. Once you've finished editing the config file, make sure you
rename it to something other than
"eggdrop.conf" if you haven't already. Then, if you edited the
config file locally, upload the config file to the directory you
installed the bot.
The botchk script and crontab are used to
automatically restart the bot if the shell it's on reboots or if the
bot process is killed for some other reason. You can find the botchk
file in the scripts directory (in the directory you installed the
bot to). Newer versions of Eggdrop (from 1.3.24i) have a script
included that automatically configures botchk and crontab for you.
In telnet, simply switch to the scripts directory and type chmod
700 autobotchk then ./autobotchk <config> -dir /home/botdir -noemail,
where /home/botdir is the directory you installed the bot to and <config>
is the name you chose for your config file.
Otherwise, you can edit the botchk file and insert the required
crontab entry manually. There are only four things you need to set
in the botchk file, all of which are pretty self explanatory. Once
you've edited the botchk file, you need to add an entry to your
crontab. Here's the best method:
1) Your crontab line should look like:
0,10,20,30,40,50 * * * * /home/botdir/scripts/botchk
>/dev/null 2>&1
This will run the botchk script every 10 minutes, which checks
that the bot is running and restarts it if it isn't. You just need
to change the /home/botdir part to the correct path to the
bot on your shell (type pwd to show this). Type the line in
Notepad or some place where you can highlight and copy it from.
2) Type crontab -e. This should bring up the vi
editor (it will appear as a bunch of lines starting with the ~
character), but may open up the pico editor instead.
3) For vi, do the following - hit ctrl-L,
hit i, paste the crontab line you created earlier, hit
Esc, type :wq! then hit Enter (if you make a
mistake doing this, just hit Esc and start over). For pico
- paste the crontab line you created earlier, hit ctrl-X, hit
Y when prompted to save, hit Enter when prompted for a
filename.
You can view your current crontab entries by typing crontab -l.
To clear your crontab, use crontab -r (may be crontab -d
on some shells).
Phew! Now that you've compiled, installed, and configured
Eggdrop, it's time to start it up. Switch to the directory to which
you installed the bot, cross your fingers, and type ./eggdrop -m
<config> (where <config> is the name you gave to the config
file). Eggdrop should start up, and the bot should appear on IRC
within a few minutes. The -m option creates a new userfile
for your bot. In future, you will only need to type ./eggdrop <config>
to start the bot.
Once your bot is on IRC, it's important that you promptly
introduce yourself to the bot. Msg it the 'hello' command you
specified in the config file, e.g. /msg <botnick> hello. This
will make you the bot's owner. Once that's done, you need to set a
password using /msg <botnick> pass <password>. You can then
DCC chat to the bot.
Now that your Eggdrop is on IRC and you've introduced yourself as
owner, it's time to learn how to
use your Eggdrop.
No show?
If your bot didn't appear on IRC, you should log in to the shell
and view or download the bot's logfile (as set in the config
file—the default is "logs/eggdrop.log"). Note that logfile entries
are not written to disk immediately unless quick-logs is
enabled, so you may have to wait a few minutes before the logfile
appears, or contains messages that indicate why your bot isn't
showing up.
|