forked from pzs-ng/pzs-ng
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathREADME
233 lines (189 loc) · 9.94 KB
/
README
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
225
226
227
228
229
230
231
232
233
PZS-NG (Project-ZS - Next Generation)
--------------------------------------
Introduction:
-------------
PZS-NG is based on Project-ZS by Dark0n3. It is what is commonly known as
a zipscript, or a post check script for file uploads. Its task is, among
others, to check the integrity of the files uploaded, and make sure a
"release" is complete and not corrupted.
Of course, this is not the only thing done by this zipscript ;). Read on to
find out why this zipscript is considered the best of the bunch by most.
Find us on the web:
http://www.pzs-ng.com
http://bugs.pzs-ng.com
History:
--------
PZS-NG is a continuance of the original Project-ZS by Dark0n3, which stopped
development in June(?) 2002, and remained stagnant for a long time. Up until
now various coders/scripters have made patches to fix bugs or make some
enhancements, but the patches have at times been overlapping, or complete
replacements of source-files, making it hard for the siteops to implement
them all.
In April, 2004, daxxar and psxc collected the various patches into packages,
but soon found out it was better to pool resources and make a unified
version. After rounding up/threatening some of the scene's brightest boys, they
got the result - PZS-NG.
The Team:
---------
daxxar (all-round programmer)
psxc (all-round programmer)
iwdisb (C specialist)
js (C specialist)
freezy3k (C specialist)
iono (Tcl guru)
themolester (Tcl guru)
avizion (Tcl guru, webmaster)
juanker (Tcl guru)
dakrer (Tcl guru)
neoxed (Tcl guru)
You can find us in #pzs-ng on EFnet for support and/or bug reporting.
Supported Platforms:
--------------------
PZS-NG should compile fine on the following platforms:
- Linux
- FreeBSD
- OpenBSD
- OSX/Darwin (the zipscript should work, but sitewho etc may need some
makefile options. Contact psxc or one of the devs for help)
- (AIX - untested, but the original docs say it works there)
- (Solaris - soon *g*)
64-bit processors - should work. Since glftpd is pre-compiled on a 32bit
platform (usually) certain bins in pzs-ng will be compiled in 32bit mode.
Make sure you have the 32bit libs installed. For more info, see README.AMD64.
The *BSD platforms currently have no support for the -m32 flag. Ask psxc
or one of the devs if you are stuck on this.
Only the i386 platform is tested, so if you try it on anything else, don't
hesitate to contact us and inform us of the result.
Supported FTP Daemons:
----------------------
- glftpd 1.xx
- glftpd 2.xx
- cuftpd 1.x
Basic description of How Things Work (tm):
------------------------------------------
As mentioned in the Introduction earlier, a zipscript checks the integrity
of the files, and keep tabs on when a release is complete. How it does this
depends on the filetype. 'ZIP' files have an integrity code build within
the file itself, which makes it easy to verify the file. To keep track of
whether or not a release based on zip-files is complete, a file named
file-id.diz is scanned.
The most common method of checking files, however, is by 'SFV'. Unlike zip,
the SFV file is a text file which stores the filenames and a CRC (cyclic
redundancy check) code. The files belonging to/listed in the sfv file can be
of any type, of which the most common are rar and mp3. The CRC code listed
in the file is compared to a CRC code calculated on the fly by either
the FTP daemon, or the program itself (more on this later). It is also quite
easy to find out if a release is complete by counting files in the SFV file.
Features of PZS-NG:
-------------------
PZS-NG would not be considered the best zipscript by most unless it had
features beyond simple file checking. Here's a list of a few things it can do:
- Log information about sfv files (how many files expected etc)
- Log information about mp3 files (genre, year, quality etc)
- Log information about the first uploaded file (who did it, speed etc)
- Log information about halfway (when a release is halfway, who is leading,
speed etc)
- Log information about complete (who won, speed, percent, who raced etc)
- Log information about a race (who takes the lead, who is racing, what
speed, percent etc)
- include information about the release in the release dir (who raced, won,
any information on the media files, speed etc)
- creation of -missing files (to easily spot what files are missing in a
release)
- create (in)complete dirs/files (to show what releases are incomplete,
and info on the release itself when it's complete)
- execute external script based on filetypes, when a file is uploaded, and/
or when a release complete.
- MORE!
Along with the included sitebot (more on this later) we can pass this
information on to an IRC channel, which in turn will make the site
seem alive, and help couriers in their work. Using a bot also has
a high fun-factor :)
Installation:
-------------
See INSTALL for general (and glftpd-specific) instructions, and in addition
INSTALL.cuftpd for cuftpd-specific instructions. sitebot/README (and
INSTALL.cuftpd) has instructions regarding the sitebot (dZSbot).
Compiled Binaries:
------------------
There are a few other binaries compiled, but they are mostly used by 3rd party
scripts. Here's a short description of each compiled binary:
- cleanup - This little bin will clean out dead symlinks. Where it search
you can specify in zsconfig.h in the define of "cleanupdirs". Please note
that this script does *NOT* scan recursively, meaning you really have to
insert the names of dirs to be scanned in this variable. Setting this to
'/site/incoming/' will only search /site/incoming, not /site/incoming/apps/
or any other dir just below.
Please note that dead symlinks in the mp3 genre/group/year/etc will be
scanned automatically - there is no need to add these to 'cleanupdirs'.
This script may be used as a cscript to 'site wipe' or 'site nuke' for
instance, in which case it will only scan the current dir. You may also run
it in 'view' mode, by giving it rootpath to glftpd. This will only list
incomplete dirs, not remove any links.
How to test: chroot /glftpd /bin/cleanup
(in chroot, in a site dir) /bin/glftpd something
/glftpd/bin/cleanup /glftpd
- datacleaner - This one will remove the racedata of dirs no longer found
on your site. Please note that this script may be run in crontab (example
1), as a command from shell (example 2) or as a cscript (example 3).
Please note that if you try to use it as a cscript to anything but RMD,
it will scan recursively, relative to where you are. This means it's possible
to use it as a cscript to 'site wipe' or 'site nuke' for instance, but it
may take some time for it to go thru all the data.
How to test: chroot /glftpd /bin/datacleaner
chroot /glftpd /bin/datacleaner /site/path/to/file
chroot /glftpd /bin/datacleaner "RMD /path/to/file" (no /site
in front!)
chroot /glftpd /bin/datacleaner "NUKE /path/to/file" (no /site
in front!)
- postdel - Should be run after you delete something (as a cscript). Will
re-check the release and update the racedata accordingly.
Please note that this script will *only* work as a cscript to the DELE
command.
How to test: chroot /glftpd /bin/postdel "DELE /site/path/to/filename"
- postunnuke - Should be run after you unnuke something (as a cscript). Will
re-check the full release and update the racedata accordingly.
Please note that this script will *only* work as a cscript to the site
UNNUKE command.
How to test: chroot /glftpd
cd /site/archive/something
/bin/postunnuke "site UNNUKE some.release-here sorry.erroneus.nuke"
- dl_speedtest - used to measure download speeds. It will write the output
to glftpd.log only.
How to test: chroot /glftpd
cd /site/speedtest
export USER=something; export GROUP=something; export SPEED=2011
/bin/dl_speedtest "RETR /site/speedtest/file"
- ng-undupe - Removes entry in dupelog after a file fails sfv check.
How to test: chroot /glftpd /bin/ng-undupe filename
- ng-deldir - Marks a directory as deleted in dirlog when it is removed cause it's banned.
How to test: chroot /glftpd /bin/ng-deldir /site/path/to/dir
- racedebug - Debugging bin that reads the racedata directly and prints
out a report on racers, files, speed, crc etc.
How to test: chroot /glftpd /bin/racedebug /ftp-data/pzs-ng/path/to/racedata
- racestats - Mostly used by 3rd party scripts. Will give raceinfo of a
release in cookie format.
How to test: chroot /glftpd /bin/racestats /site/path/to/dir
- zipscript-c - The zipscript. Should be run from within glftpd after a file
is uploaded. Will do various tests, create stats, run external commands
etc, according to your config.
How to test: chroot /glftpd /bin/zipscript-c <filename> <path> <crc-code>
You can recover (or check) your compiled config by the following syntax:
chroot /glftpd /bin/zipscript-c --config
chroot /glftpd /bin/zipscript-c --fullconfig # Also shows defaulted values
- ng-chown - currently not used. It's a bin designed to chown files/dirs
in your site to a specified used/group. When used it needs the +s bit
set. Take care, though - using this bin with +s may be a security risk.
- rescan - Used to re-check a release. Mostly used as a site command. It
can take the following arguments (only one allowed):
--quick - skips files that are already marked as checked, and crc-checks
the ones that are not.
--normal - check all files regardless if they previously have been checked
and found ok.
--chroot=<DIRNAME> - chroot() to DIRNAME before starting the rescan.
--dir=<DIRNAME> - chdir() to DIRNAME before starting the rescan.
<NAME><*> - only recheck the file named NAME or all files starting with
NAME*. Wildcard can only be at the end, not beginning or in the middle.
How to test: /glftpd/bin/rescan --chroot=/glftpd --dir=/site/linux/suse15 --normal
site rescan --dir=/site/linux/suse15
site rescan --quick