1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
|
This is the BIP IRC Proxy README.
Bip can be used in two different ways:
- Old school bnc user style: easy and straightforward.
- Unix service style with and init.d scripts and the logs in /var/log
This small README file explains the usage "Old school" with which :
- you do not need the root privileges.
- gives easy access to the logs to the owner of the shell.
Table of contents :
I. Installation
II. Configuration
A. Manual configuration
B. Automated configuration
III. Running bip
IV. Using bip
A. Connecting your client(s)
B. Backlog and flood control
C. Multiple users and ident issues
I. INSTALLATION
Install bip on the machine that will be running bip (which is likely to be
your personnal or shared server) either compiling the package or using your
distro's package. Then create a configuration file.
Choose your distribution package if available. If not, build bip the
old-fashioned way. You will need make, gcc, lex, yacc, automake,
autoconf-archive and optionally libssl-dev to build bip.
Just issue:
From bip-X.Y.Z.tar.gz package:
# ./configure --enable-oidentd && make
From repository:
# autoreconf -i -Wall
# ./configure --enable-maintainer-mode --enable-oidentd && make
If openssl and its developement files are installed, bip should build with
SSL support. After a successful build the bip binary can be found in
./src/bip.
By default, "-Werror" is used. If you encounter warnings, you could try:
# CFLAGS="-Wno-error" ./configure --enable-oidentd && make
II. CONFIGURATION
First of all, create your bip configuration an log directory:
# mkdir -p ~/.bip/logs
There are two ways to create your bip configuration :
- edit the sample bip.conf file to match your needs
- use the bipgenconfig script to easily generate a configuration
If you want to connect to bip using an SSL client, you'll need to create
a certificate / key pair (in a bip.pem file) to allow bip to serve SSL
sockets.
A. MANUAL CONFIGURATION
If you are using a distribution package, the bip.conf sample configuration
file is likely to be shipped in /usr/share/doc/bip/examples/bip.conf.gz or
something similar.
If not, you'll find sample configuration file in the source package's
`samples' subdirectory.
Put the uncompressed configuration file in your ~/.bip directory (its
path should be ~/.bip/bip.conf), and edit it, most importantly the "user"
section that contains information about you and the servers you will want
to connect to. The "name" field in the "user" section is your login to
connect to bip.
The "name" field of the "connection" subsections are the server identifier
for when you connect to bip.
The "password" field is a hash of the password you will use to connect to
bip. To generate a hash value from a password, use bipmkpw, program which
comes in the bip package and source.
If you've set client_side_ssl to true, you'll need to generate a bip.pem
file containing a certificate / key pair. In order to do so, you can use
the third party `openssl' binary :
# openssl req -new -x509 -days 365 -nodes -out bip.pem -keyout bip.pem
You can then remove the passphrase with :
# openssl x509 -subject -dates -fingerprint -noout -in bip.pem
B. AUTOMATED CONFIGURATION
You can also use the bipgenconfig script to generate a new configuration.
This script will also help you generate the SSL certificate / key pair
needed for clients to connect to BIP through SSL.
This script can be found either in the source package's `scripts'
directory or shipped with your distribution's package.
Using the script is very simple, and it will generate a configuration
file but won't overwrite any existing configuration.
It will ask you the path to the bipmkpw binary, to automatically hash the
passwords you'll provide. Please make sure to enter the correct path to
the binary or you might observe unexpected behaviour.
You'll need to move the generated configuration from bip.conf.autogen to
bip.conf and the generated PEM file from bip.pem.autogen to bip.pem (or
whatever path you've configured in bip.conf).
III. RUNNING BIP
Once all this is configured, start bip as your regular user:
# ./src/bip
If you have installed bip in your path (or if you are using you
distribution's package), simply use:
# bip
Once bip starts, it connects to the different servers your defined in
all "user"'s "connection" blocks.
IV. USING BIP
A. CONNECTING YOUR CLIENT(S)
Then you want to use your regular irc client and connect to bip. Point
your client to the machine bip is running and set the proper port number
(defined in your bip.conf). You should then configure the client to use a
specific irc server password constructed this way:
user:password:connection
The user is the name field of the "user" section, the password is the
password (*not* the hash) corresponding to the "password" field of the
same user section (which is the hash generated with bipmkpw) and the
connection is the "name" field of the "connection" subsection. This is
how bip authenticates you and puts your client to the correct network.
Using the default (or sample file) configuration, logs are in ~/.bip/logs/
B. BACKLOG AND FLOOD CONTROL
Bip has a backlogging system which will send back parts of the last logs
upon client connection. Depending on your configuration, that may mean a
*lot* of data sent back to your client.
Users' messages will be replayed as if they were being sent at the moment
your client connects to bip, and if not disabled, system messages will
appear as coming from the "-bip" user.
Considering that, you may want to disable your client's anti-flood system,
totally or not, depending on it's flexibility.
Since bip doesn't replay CTCP messages, you can safely let your client's
anti-flood system manage them.
[Xchat]
If you're using Xchat, you can "disable" it by issuing these commands :
/set flood_msg_num = 1000
/set flood_msg_time = 10
In fact you'll tell xchat to activate its anti-flood system when you're
receiving more than 1000 messages in less than 10 seconds.
If you forgot to set these, private messages may not appear in separate
tabs as usual. If so, simply issue a :
/set gui_auto_open_dialog on
C. MULTIPLE USERS AND IDENT ISSUES
When you host many connections to the same IRC network, you might have
more connections than allowed by the network from one host.
Depending on the network and the services it runs, session limits may be
enforced either matching only your ip address/hostname, or matching the
username/ident part too.
To avoid being killed for session limit exceeded, you should define a
default_username in each user {}; block. A user without default_username
would appear as ~bip@yourhost if bip is the system user running bip. With
a default_username set to "myuser", he would appear as ~myuser@yourhost,
which may be sufficient for most networks.
If the network you're on is a bit more requiring, you can set up an
oidentd server on your host, and (if not already) compile bip with
oidentd spoofing support (--enable-oidentd option of the configure
script). Let's say bip is the system user running bip, you should add to
your /etc/oidentd.conf :
user "bip" {
default {
allow spoof_all
allow spoof_privport
allow spoof
}
}
Then reload oidentd and make sure that ~bip is accessible (+rx) by the
user running oidentd (which means most of the time ~bip should be world
readable and browsable +rx).
If you already have a ~bip/.oidentd.conf file, don't worry, bip'll only
add its entries without deleting any of the contents of the file.
This step should remove the "~" character from the username/ident part of
your ircmask, and thus satisfy some networks.
If the network is still killing you for session limit exceeded, you'll
have to contact it's admins and ask them for an exception on your host or
ip address.
Happy ircing!
-- Arnaud Cornet <nohar@t1r.net> and Loïc Gomez <opensource@kyoshiro.org>
|
