gjp 0.32.0 → 0.33.0
Sign up to get free protection for your applications and to get access to all the features.
- data/MOTIVATION.md +27 -0
- data/README.md +27 -163
- data/SPECIAL_CASES.md +126 -0
- data/lib/gjp.rb +0 -1
- data/lib/gjp/cli.rb +2 -30
- data/lib/gjp/version.rb +1 -1
- data/utils/delete_nonet_user.sh +8 -0
- data/utils/setup_nonet_user.sh +8 -0
- metadata +6 -5
- data/lib/gjp/limited_network_user.rb +0 -64
- data/spec/lib/limited_network_user_spec_interactive.rb +0 -39
data/MOTIVATION.md
ADDED
@@ -0,0 +1,27 @@
|
|
1
|
+
# Motivation
|
2
|
+
|
3
|
+
The Java developer world has packages (jars, wars, ears...), tools ([ant](http://ant.apache.org/), [Maven](http://maven.apache.org/), [Ivy](http://ant.apache.org/ivy/), [Gradle](http://www.gradle.org/)...) and established workflows to handle software distribution while Linux distros have their own ([zypper](http://en.opensuse.org/Portal:Zypper), [yum](http://en.wikipedia.org/wiki/Yellowdog_Updater,_Modified), [apt](http://en.wikipedia.org/wiki/Advanced_Packaging_Tool)...). Since the two communities have different goals and requirements, Linux distros typically want to repackage Java software with their own format, tools and workflows. Reasons range from ease of installation, predictable rebuildability, support to (security) patching, management tools, legal issues, etc.
|
4
|
+
|
5
|
+
Unfortunately those two "schemes" became very different over time, so automatic translation/repackaging is not possible except in very simple cases. This leads to a lot of tedious, error-prone manual work that Linux packagers have to do in order to fit the "alien" Java model into distro packaging rules that were thought and optimized with a different ecosystem in mind.
|
6
|
+
|
7
|
+
A typical example is packaging any software built by Maven on SUSE distros. A number of pain points arise:
|
8
|
+
|
9
|
+
* Maven requires Internet access and downloads precompiled code as part of the build. RPMs have to be built on a standalone machine in [OBS](http://en.opensuse.org/openSUSE:Build_Service), and they should build code from sources they are provided beforehands exclusively;
|
10
|
+
* [Maven is basically a plugin container](http://maven.apache.org/plugins/), so hundreds of different plugins have to be installed to build real-life projects (the exact plugin set and their dependencies is determined at build time). While this is no big deal for Java developers, since they get the corresponding jars prebuilt from public Intenet Maven repositories, it is a nightmare for distros, because all shipping code is supposed to be built from scratch and packaged!
|
11
|
+
* Maven often uses multiple versions of a same library or plugin during the same build. Usually distros do not accept more than one version of any given library to reduce maintenance work;
|
12
|
+
* Maven requires itself in order to build. To be more exact, Maven needs Nexus, which in turn needs Maven and Nexus. To be more exact, its build dependency graph is a very complicated mess with lots of cycles that have to be broken manually.
|
13
|
+
|
14
|
+
The current solution in openSUSE is having the packager handle those differences, but this limits the amount of software the community is able to package due to the high effort required to overcome them.
|
15
|
+
|
16
|
+
The Fedora community is experimenting with another set of tools, [XMvn](http://mizdebsk.fedorapeople.org/xmvn/site/), which goals are similar to `gjp`'s.
|
17
|
+
|
18
|
+
## Kit rationale
|
19
|
+
|
20
|
+
`gjp` simplifies the packaging process mostly because of its use of a binary blob package that contains all build time dependencies for a set of packages called a **kit**.
|
21
|
+
|
22
|
+
Building software from a binary blob is unusual for Linux distros, and it surely has some drawbacks. It is anyway believed that benefits outweigh them, in fact using prebuilt software:
|
23
|
+
|
24
|
+
* drastically reduces packaging efforts. A very basic and relatively simple package like [commons-collections](http://commons.apache.org/proper/commons-collections/) needs about [150 jars](https://build.opensuse.org/package/show/home:SilvioMoioli/myproject-kit) just to be compiled and tested. Those should be packaged, roughly, one-by-one!
|
25
|
+
* is just the way all Java developers out there build, test and use their software — this is how they expect it to work. Any different approach is necessarily error-prone and could result in unexpected bugs;
|
26
|
+
* does not affect the ability of providing patches to Java projects, as only build time requirements are in the kit. In virtually all cases patching a piece of software does not require to patch its build toolchain;
|
27
|
+
* does not affect the ability of complying to software licenses like the GPL. In fact those licenses only require to redistribute a project's source code - not the whole toolchain needed to build it. Sources can be added and shipped together with binaries when licenses require it.
|
data/README.md
CHANGED
@@ -1,39 +1,39 @@
|
|
1
|
-
# gjp –
|
1
|
+
# gjp – builds RPMs for Java software
|
2
2
|
|
3
|
-
`gjp` is a set of tools to
|
4
|
-
|
5
|
-
## Why?
|
3
|
+
`gjp` is a set of tools to help you build RPM packages for Java projects.
|
6
4
|
|
7
5
|
Packaging of Java projects is sometimes hard because build tools like Maven partially overlap with distro tools like RPM in functionality.
|
8
6
|
|
9
7
|
We are trying to come up with **a tool that drastically simplifies packaging**.
|
10
8
|
|
11
|
-
##
|
9
|
+
## Installation
|
12
10
|
|
13
|
-
|
11
|
+
You need:
|
14
12
|
|
15
13
|
* [Ruby 1.9](https://www.ruby-lang.org/en/);
|
16
14
|
* [git](http://git-scm.com/);
|
17
15
|
* a JDK that can compile whatever software you need to package;
|
18
|
-
* only for the optional `set-up-nonet-user` subcommand, `sudo` and `iptables`.
|
19
16
|
|
20
|
-
|
17
|
+
Install `gjp` via RubyGems:
|
21
18
|
|
22
|
-
|
19
|
+
gem install gjp
|
23
20
|
|
24
21
|
## Workflow
|
25
22
|
|
26
|
-
Building a package with `gjp` is quite unusual — this is a
|
23
|
+
Building a package with `gjp` is quite unusual — this is a deliberate choice, so don't worry. Basic steps are:
|
27
24
|
|
28
25
|
* `gjp init` a new project;
|
29
|
-
* add sources to `src/<package name>` and
|
30
|
-
* execute `gjp dry-run`, any command needed to compile your software
|
31
|
-
* execute `gjp generate-all
|
32
|
-
|
26
|
+
* add sources to `src/<package name>` and anything else needed for the build in `kit/` in binary form (typically a copy of Maven and maybe some other dependency jars);
|
27
|
+
* execute `gjp dry-run`, then any command needed to compile your software, then `gjp finish`;
|
28
|
+
* execute `gjp generate-all`: gjp will look at changed files and Bash history to scaffold spec files and tarballs.
|
29
|
+
|
30
|
+
Done!
|
33
31
|
|
34
|
-
|
32
|
+
### How can that possibly work?
|
35
33
|
|
36
|
-
|
34
|
+
With `gjp` you are not building all dependencies from source, just your package. Everything else is shipped already compiled with attached source files, which is much easier to implement and automate. Yet, it is sufficient to fulfill open source licenses and to have a repeatable, networkless build. See [MOTIVATION.md](MOTIVATION.md) for further information.
|
35
|
+
|
36
|
+
## A commons-collections walkthrough
|
37
37
|
|
38
38
|
First, ceate a new `gjp` project, in this example named "myproject":
|
39
39
|
|
@@ -41,9 +41,7 @@ First, ceate a new `gjp` project, in this example named "myproject":
|
|
41
41
|
cd myproject
|
42
42
|
gjp init
|
43
43
|
|
44
|
-
|
45
|
-
|
46
|
-
Second, place all your projects' source files in `src/`. Every `src/` subfolder will become a separate package named after the folder itself, so use the following commands to create a `commons-collections` folders and populate it:
|
44
|
+
Second, place commons-collections source files in the `src/` folder. Specifically, every `src/` subfolder will become a separate package named after the folder itself, so you can use the following:
|
47
45
|
|
48
46
|
cd src
|
49
47
|
mkdir commons-collections
|
@@ -52,167 +50,34 @@ Second, place all your projects' source files in `src/`. Every `src/` subfolder
|
|
52
50
|
unzip commons-collections-3.2.1-src.zip
|
53
51
|
rm commons-collections-3.2.1-src.zip
|
54
52
|
|
55
|
-
Third, all non-source files needed for the build
|
53
|
+
Third, put all non-source files needed for the build in `kit/`. This means all build dependencies and tools excluding the JDK: in this case it is just Maven:
|
56
54
|
|
57
55
|
cd ../../kit
|
58
56
|
wget http://www.eu.apache.org/dist/maven/binaries/apache-maven-3.1.1-bin.zip
|
59
57
|
unzip apache-maven-3.1.1-bin.zip
|
60
58
|
rm apache-maven-3.1.1-bin.zip
|
61
59
|
|
62
|
-
Fourth, you need to show `gjp` how to build your package by
|
60
|
+
Fourth, you need to show `gjp` how to build your package by running appropriate commands between `gjp dry-run` and `gjp finish`. Bash history will be recorded to generate a "starting-point" build script (that will be sufficient in simple cases like this):
|
63
61
|
|
62
|
+
cd ../src/commons-collections/commons-collections-3.2.1-src/
|
64
63
|
gjp dry-run
|
65
|
-
cd src/commons-collections/commons-collections-3.2.1-src/
|
66
64
|
gjp mvn package
|
67
65
|
gjp finish
|
68
66
|
|
69
|
-
Note that we used `gjp mvn package` instead of `mvn package
|
67
|
+
Note that we used `gjp mvn package` instead of `mvn package`: this will use of the Maven copy we put in `kit/` and the repository in `kit/m2`.
|
68
|
+
Also note that this being a dry-run build, sources will be brought back to their original state after `gjp finish`, as this ensures build repeatability.
|
70
69
|
|
71
|
-
Finally,
|
70
|
+
Finally, generate build scripts, spec files and tarballs in the `output/` directory:
|
72
71
|
|
73
72
|
gjp generate-all
|
74
73
|
|
75
|
-
Note that gjp will
|
76
|
-
|
77
|
-
## Special cases
|
78
|
-
|
79
|
-
### Failing builds
|
80
|
-
|
81
|
-
If youyr build fails for whatever reason, abort it with `gjp finish --abort`. `gjp` will restore all project files as they were before build.
|
82
|
-
|
83
|
-
### Manual changes
|
84
|
-
|
85
|
-
You can do any manual changes to spec and build.sh files and regenerate them later, `gjp` will reconcile changes with a [three-way merge](http://en.wikipedia.org/wiki/Three-way_merge#Three-way_merge) and alert about any conflicts. You can generate single files with the following commands:
|
86
|
-
|
87
|
-
* `gjp generate-kit-archive`: (re)generates the kit tarball;
|
88
|
-
* `gjp generate-kit-spec`: (re)generates the kit spec;
|
89
|
-
* `gjp generate-package-script`: (re)generates the `build.sh` file from the latest bash history (assumes `gjp dry-run` and `gjp finish`have been used). Assumes your current working directory is in a package folder (that is, a subdirectory of `src/<package name>/`);
|
90
|
-
* `gjp generate-package-archive`: (re)generates a package tarball;
|
91
|
-
* `gjp generate-package-spec`: (re)generates a package spec;
|
92
|
-
|
93
|
-
Note that, by default, `generate-kit-archive` will generate additional "diff" tar.xz files instead of rewriting the whole archive - this will result in faster uploads if you use OBS (see below). You can use the `--full` option to regenerate a single complete archive.
|
94
|
-
|
95
|
-
### [OBS](build.opensuse.org)
|
96
|
-
|
97
|
-
If you want to submit packages to OBS, you can do so by replacing the `output/` directory in your `gjp` project with a symlink to your OBS project directory.
|
98
|
-
|
99
|
-
Packages will rebuild cleanly in OBS because no Internet access is needed - all files were already downloaded during dry-run and are included in the kit.
|
100
|
-
|
101
|
-
Note that the kit package is needed at build time only by OBS, no end user should ever install it.
|
102
|
-
|
103
|
-
### Kit sources
|
104
|
-
|
105
|
-
Your kit is basically a binary blob. If its sources are needed for proper packaging, for example to comply with the GPL, some extra steps are needed.
|
106
|
-
|
107
|
-
If you use Maven, most (~90%) sources can be automatically downloaded:
|
108
|
-
|
109
|
-
gjp get-maven-source-jars
|
110
|
-
|
111
|
-
The remaining (mostly very outdated) jars will be listed by `gjp` when the download ends. You need to manually find corresponding sources for them, you can use:
|
112
|
-
|
113
|
-
gjp get-source /path/to/<jar name>.pom
|
114
|
-
|
115
|
-
to get pointers to relevant sites if available in the pom itself.
|
116
|
-
|
117
|
-
A list of commonly used jars can be found [below](#frequently-used-sources).
|
118
|
-
|
119
|
-
You can also use:
|
120
|
-
|
121
|
-
gjp list-kit-missing-sources
|
122
|
-
|
123
|
-
To get a list of jars that have one or more `.class` file which does not have a corresponding `.java` file in `kit/` (or zip files in `kit/`).
|
124
|
-
|
125
|
-
### Ant builds
|
126
|
-
|
127
|
-
`gjp` is currently optimized for Maven as it is the most common build tool, but it can work with any other. In particular, support for Ant has already been implemented and `gjp ant` works like `gjp mvn`.
|
74
|
+
Note that `gjp` will generate files for the commons-collections package and for the binary-only myproject-kit package, which is a special container of all build-time dependencies (basically, the `kit/` folder). This will be shared among all packages you might add to your `gjp` project.
|
128
75
|
|
129
|
-
|
76
|
+
## In-depth information
|
130
77
|
|
131
|
-
|
78
|
+
In more complex cases building a package will require some special tweaks. We are trying to cover the most common in the [SPECIAL_CASES.md](SPECIAL_CASES.md) file.
|
132
79
|
|
133
|
-
|
134
|
-
|
135
|
-
When generating spec files, be sure to have a `pom.xml` in your package directory even if you are not using Maven: `gjp` will automatically take advantage of information from it to compile many fields.
|
136
|
-
|
137
|
-
You can also ask `gjp` to find one via `gjp get-pom <filename>.jar` (be sure to have Maven in your kit).
|
138
|
-
|
139
|
-
### Other builds
|
140
|
-
|
141
|
-
Other build tools are currently unsupported but will be added in the future. You can nevertheless use them - the only rule is that you have to keep all of their files in `kit`.
|
142
|
-
|
143
|
-
### Optional: networkless dry-run builds
|
144
|
-
|
145
|
-
If you want to be 100% sure your package builds without network access, you can use a special `gjp` subcommand to setup a `nonet` user that cannot use the Internet. Then you can simply retry the build using that user to see if it works. Note that the following commands will alter group permissions to allow both your current user and `nonet` to work on the same files.
|
146
|
-
|
147
|
-
gjp set-up-nonet-user
|
148
|
-
chmod -R g+rw ../../..
|
149
|
-
gjp dry-run
|
150
|
-
su nonet
|
151
|
-
ping www.google.com #this should fail!
|
152
|
-
gjp mvn package
|
153
|
-
chmod -R g+rw .
|
154
|
-
exit
|
155
|
-
gjp finish
|
156
|
-
|
157
|
-
### Gotchas
|
158
|
-
|
159
|
-
* `gjp` internally uses `git` to keep track of files, any gjp project is actually also a `git` repo. Feel free to navigate it, you can commit, push and pull as long as the `gjp` tags are preserved. You can also delete commits and tags, effectively rewinding gjp history (just make sure to delete all tags pointing to a certain commit when you discard it);
|
160
|
-
* if your sources come from a Git repo, be sure to remove any `.git`/`.gitignore` files, otherwise `gjp` might get confused;
|
161
|
-
* if OBS complains that jars in your kit or package are compiled for a JDK version higher than 1.5, add the following line after `%install` to squelch the error:
|
162
|
-
|
163
|
-
export NO_BRP_CHECK_BYTECODE_VERSION=true
|
164
|
-
|
165
|
-
* if packages build at first but then fail after a few days because Maven tries to connect to the Internet, add the `--option` flag to the `mvn` line in `build.sh`;
|
166
|
-
|
167
|
-
### Frequently used sources
|
168
|
-
|
169
|
-
* antlr-2.7.7: `wget http://www.antlr2.org/download/antlr-2.7.7.tar.gz -O kit/m2/antlr/antlr/2.7.7/antlr-2.7.7-sources.tar.gz`;
|
170
|
-
* ant-launcher-1.6.5: sources included in ant-1.6.5;
|
171
|
-
* asm-3.3.1: `wget http://download.forge.ow2.org/asm/asm-3.3.1.tar.gz -O kit/m2/asm/asm/3.3.1/asm-3.3.1-sources.tar.gz`;
|
172
|
-
* jsr305-1.3.9: sources included in jar;
|
173
|
-
* jsr305-2.0.1: sources included in jar;
|
174
|
-
* commons-lang-1.0: `wget http://archive.apache.org/dist/commons/lang/source/lang-1.0-src.tar.gz -O kit/m2/commons-lang/commons-lang/1.0/commons-lang-1.0-sources.tar.gz`;
|
175
|
-
* commons-logging-api-1.1: `wget http://archive.apache.org/dist/commons/logging/source/commons-logging-1.1-src.tar.gz -O kit/m2/commons-logging/commons-logging/1.1/commons-logging-1.1-sources.tar.gz` (included in commons-logging-1.1);
|
176
|
-
* commons-logging-1.0: `wget http://archive.apache.org/dist/commons/logging/source/commons-logging-1.0-src.tar.gz -O kit/m2/commons-logging/commons-logging/1.0/commons-logging-1.0-sources.tar.gz`;
|
177
|
-
* dom4j-1.1: `wget http://dom4j.cvs.sourceforge.net/viewvc/dom4j/dom4j/?view=tar&pathrev=dom4j-1-1 -O kit/m2/dom4j/dom4j/1.1/dom4j-1.1-sources.tar.gz`;
|
178
|
-
* doxia-sink-api-1.0-alpha-4: use `svn export http://svn.apache.org/repos/asf/maven/doxia/doxia/tags/doxia-sink-api-1.0-alpha-4/ kit/m2/doxia/doxia-sink-api/1.0-alpha-4/doxia-sink-api-1.0-alpha-4-sources`;
|
179
|
-
* kxml2-2.2.2: use `wget http://sourceforge.net/projects/kxml/files/kxml2/2.2.2/kxml2-src-2.2.2.zip/download -O kit/m2/net/sf/kxml/kxml2/2.2.2/kxml2-2.2.2-sources.zip`;
|
180
|
-
* log4j-1.2.12: `wget http://archive.apache.org/dist/logging/log4j/1.2.12/logging-log4j-1.2.12.tar.gz -O kit/m2/log4j/log4j/1.2.12/log4j-1.2.12-sources.tar.gz`;
|
181
|
-
* stringtemplate-3.2: `wget http://www.stringtemplate.org/download/stringtemplate-3.2.tar.gz -O kit/m2/org/antlr/stringtemplate/3.2/stringtemplate-3.2-sources.tar.gz`;
|
182
|
-
* velocity-tools-2.0: `wget http://archive.apache.org/dist/velocity/tools/2.0/velocity-tools-2.0-src.tar.gz -O kit/m2/org/apache/velocity/velocity-tools/2.0/velocity-tools-2.0-sources.tar.gz`;
|
183
|
-
* velocity-1.5: `wget http://archive.apache.org/dist/velocity/engine/1.5/velocity-1.5.tar.gz -O kit/m2/org/apache/velocity/velocity/1.5/velocity-1.5-sources.tar.gz`;
|
184
|
-
* trilead-ssh2-build213-svnkit-1.3: `svn export http://svn.svnkit.com/repos/svnkit/tags/1.3.5/ kit/m2/org/tmatesoft/svnkit/svnkit/1.3.5/svnkit-1.3.5-sources` (included in svnkit 1.3.5 full sources because of custom patch);
|
185
|
-
* xercesImpl-2.9.1: `wget http://archive.apache.org/dist/xerces/j/source/Xerces-J-src.2.9.1.tar.gz -O kit/m2/xerces/xercesImpl/2.9.1/xercesImpl-2.9.1-sources.tar.gz`;
|
186
|
-
* xmlpull-1.1.3.1: wget `http://www.extreme.indiana.edu/xmlpull-website/v1/download/xmlpull_1_1_3_4c_src.tgz -O kit/m2/xmlpull/xmlpull/1.1.3.1/xmlpull-1.1.3.1-sources.tar.gz`
|
187
|
-
* xmlunit-1.3: `wget http://sourceforge.net/projects/xmlunit/files/xmlunit%20for%20Java/XMLUnit%20for%20Java%201.3/xmlunit-1.3-src.zip/download -O kit/m2/xmlunit/xmlunit/1.3/xmlunit-1.3-sources.zip`;
|
188
|
-
|
189
|
-
## Motivation
|
190
|
-
|
191
|
-
The Java developer world has packages (jars, wars, ears...), tools ([ant](http://ant.apache.org/), [Maven](http://maven.apache.org/), [Ivy](http://ant.apache.org/ivy/), [Gradle](http://www.gradle.org/)...) and established workflows to handle software distribution while Linux distros have their own ([zypper](http://en.opensuse.org/Portal:Zypper), [yum](http://en.wikipedia.org/wiki/Yellowdog_Updater,_Modified), [apt](http://en.wikipedia.org/wiki/Advanced_Packaging_Tool)...). Since the two communities have different goals and requirements, Linux distros typically want to repackage Java software with their own format, tools and workflows. Reasons range from ease of installation, predictable rebuildability, support to (security) patching, management tools, legal issues, etc.
|
192
|
-
|
193
|
-
Unfortunately those two "schemes" became very different over time, so automatic translation/repackaging is not possible except in very simple cases. This leads to a lot of tedious, error-prone manual work that Linux packagers have to do in order to fit the "alien" Java model into distro packaging rules that were thought and optimized with a different ecosystem in mind.
|
194
|
-
|
195
|
-
A typical example is packaging any software built by Maven on SUSE distros. A number of pain points arise:
|
196
|
-
|
197
|
-
* Maven requires Internet access and downloads precompiled code as part of the build. RPMs have to be built on a standalone machine in [OBS](http://en.opensuse.org/openSUSE:Build_Service), and they should build code from sources they are provided beforehands exclusively;
|
198
|
-
* [Maven is basically a plugin container](http://maven.apache.org/plugins/), so hundreds of different plugins have to be installed to build real-life projects (the exact plugin set and their dependencies is determined at build time). While this is no big deal for Java developers, since they get the corresponding jars prebuilt from Maven itself, it is a nightmare for distros, because all shipping code is supposed to be built from scratch and packaged!
|
199
|
-
* Maven often uses multiple versions of a same library or plugin during the same build. Usually distros do not maintain more than one version of any given library to reduce maintenance;
|
200
|
-
* Maven requires itself in order to build. To be more exact, Maven needs Nexus, which in turn needs Maven and Nexus. To be more exact, its build dependency graph is a very complicated mess with lots of cycles that have to be broken manually.
|
201
|
-
|
202
|
-
The current solution in openSUSE is having the packager handle those differences, but this limits the amount of software the community is able to package due to the high effort required to overcome them.
|
203
|
-
|
204
|
-
The Fedora community is experimenting with another set of tools, [XMvn](http://mizdebsk.fedorapeople.org/xmvn/site/), which goals are similar to `gjp`'s.
|
205
|
-
|
206
|
-
## Kit rationale
|
207
|
-
|
208
|
-
`gjp` simplifies the packaging process mostly because of its use of a binary blob package that contains all build time dependencies for a set of packages called a **kit**.
|
209
|
-
|
210
|
-
Building software from a binary blob is unusual for Linux distros, and it surely has some drawbacks. It is anyway believed that benefits outweigh them, in fact using prebuilt software:
|
211
|
-
|
212
|
-
* drastically reduces packaging efforts. A very basic and relatively simple package like [commons-collections](http://commons.apache.org/proper/commons-collections/) needs about [150 jars](https://build.opensuse.org/package/show/home:SilvioMoioli/myproject-kit) just to be compiled and tested. Those should be packaged, roughly, one-by-one!
|
213
|
-
* is just the way all Java developers out there build, test and use their software — this is how they expect it to work. Any different approach is necessarily error-prone and could result in unexpected bugs;
|
214
|
-
* does not affect the ability of providing patches to Java projects, as only build time requirements are in the kit. In virtually all cases patching a piece of software does not require to patch its build toolchain;
|
215
|
-
* does not affect the ability of complying to software licenses like the GPL. In fact those licenses only require to redistribute a project's source code - not the whole toolchain needed to build it. [Sources can be added](#kit-sources) for GPL'd parts of the kit, if any.
|
80
|
+
An in-depth discussion of this project's motivation is available in the [MOTIVATION.md](MOTIVATION.md) file.
|
216
81
|
|
217
82
|
## Status
|
218
83
|
|
@@ -220,7 +85,6 @@ Building software from a binary blob is unusual for Linux distros, and it surely
|
|
220
85
|
|
221
86
|
At the moment `gjp` is tested on openSUSE.
|
222
87
|
|
223
|
-
|
224
88
|
## Sources
|
225
89
|
|
226
90
|
`gjp`'s Git repo is available on GitHub, which can be browsed at:
|
data/SPECIAL_CASES.md
ADDED
@@ -0,0 +1,126 @@
|
|
1
|
+
# Special cases
|
2
|
+
|
3
|
+
## Failing builds
|
4
|
+
|
5
|
+
If your build fails for whatever reason, abort it with `gjp finish --abort`. `gjp` will restore all project files as they were before build.
|
6
|
+
|
7
|
+
## Manual changes to generated files
|
8
|
+
|
9
|
+
You can do any manual changes to spec and build.sh files and regenerate them later, `gjp` will reconcile changes with a [three-way merge](http://en.wikipedia.org/wiki/Three-way_merge#Three-way_merge) and alert about any conflicts. You can generate single files with the following commands:
|
10
|
+
|
11
|
+
* `gjp generate-kit-archive`: (re)generates the kit tarball;
|
12
|
+
* `gjp generate-kit-spec`: (re)generates the kit spec;
|
13
|
+
* `gjp generate-package-script`: (re)generates the `build.sh` file from the latest bash history (assumes `gjp dry-run` and `gjp finish`have been used). Assumes your current working directory is in a package folder (that is, a subdirectory of `src/<package name>/`);
|
14
|
+
* `gjp generate-package-archive`: (re)generates a package tarball;
|
15
|
+
* `gjp generate-package-spec`: (re)generates a package spec;
|
16
|
+
|
17
|
+
Note that, by default, `generate-kit-archive` will generate additional "diff" tar.xz files instead of rewriting the whole archive - this will result in faster uploads if you use OBS (see below). You can use the `--full` option to regenerate a single complete archive.
|
18
|
+
|
19
|
+
## Kit sources
|
20
|
+
|
21
|
+
Your kit is basically a binary blob. If its sources are needed for proper packaging, for example to comply with the GPL, some extra steps are needed.
|
22
|
+
|
23
|
+
If you use Maven, most (~90%) sources can be automatically downloaded:
|
24
|
+
|
25
|
+
gjp download-maven-source-jars
|
26
|
+
|
27
|
+
The remaining (mostly very outdated) jars will be listed by `gjp` when the download ends. You need to manually find corresponding sources for them, you can use:
|
28
|
+
|
29
|
+
gjp get-source /path/to/<jar name>.pom
|
30
|
+
|
31
|
+
to get pointers to relevant sites if available in the pom itself.
|
32
|
+
|
33
|
+
A list of commonly used jars can be found [below](#frequently-used-sources).
|
34
|
+
|
35
|
+
You can also use:
|
36
|
+
|
37
|
+
gjp list-kit-missing-sources
|
38
|
+
|
39
|
+
To get a list of jars that have one or more `.class` file which does not have a corresponding `.java` file in `kit/` (or zip files in `kit/`).
|
40
|
+
|
41
|
+
## Ant builds
|
42
|
+
|
43
|
+
`gjp` is currently optimized for Maven as it is the most common build tool, but it can work with any other. In particular, support for Ant has already been implemented and `gjp ant` works like `gjp mvn`.
|
44
|
+
|
45
|
+
Sometimes you will have jar files distributed along with the source archive that will end up in `src/`: you don't want that! Run
|
46
|
+
|
47
|
+
gjp move-jars-to-kit
|
48
|
+
|
49
|
+
to have them moved to `kit/jars`. The command will generate a symlink back to the original, so builds will work as expected.
|
50
|
+
|
51
|
+
When generating spec files, be sure to have a `pom.xml` in your package directory even if you are not using Maven: `gjp` will automatically take advantage of information from it to compile many fields.
|
52
|
+
|
53
|
+
You can also ask `gjp` to find one via `gjp get-pom <filename>.jar` (be sure to have Maven in your kit).
|
54
|
+
|
55
|
+
## Other build tools
|
56
|
+
|
57
|
+
Other build tools are currently unsupported but will be added in the future. You can nevertheless use them - the only rule is that you have to keep all of their files in `kit`.
|
58
|
+
|
59
|
+
## [OBS](build.opensuse.org) integration
|
60
|
+
|
61
|
+
If you want to submit packages to OBS, you can do so by replacing the `output/` directory in your `gjp` project with a symlink to your OBS project directory.
|
62
|
+
|
63
|
+
Packages will rebuild cleanly in OBS because no Internet access is needed - all files were already downloaded during dry-run and are included in the kit.
|
64
|
+
|
65
|
+
Note that the kit package is needed at build time only by OBS, no end user should ever install it.
|
66
|
+
|
67
|
+
|
68
|
+
## Gotchas
|
69
|
+
|
70
|
+
* `gjp` internally uses `git` to keep track of files, any gjp project is actually also a `git` repo. Feel free to navigate it, you can commit, push and pull as long as the `gjp` tags are preserved. You can also delete commits and tags, effectively rewinding gjp history (just make sure to delete all tags pointing to a certain commit when you discard it);
|
71
|
+
* if your sources come from a Git repo, be sure to remove any `.git`/`.gitignore` files, otherwise `gjp` might get confused;
|
72
|
+
* if OBS complains that jars in your kit or package are compiled for a JDK version higher than 1.5, add the following line after `%install` to squelch the error:
|
73
|
+
|
74
|
+
export NO_BRP_CHECK_BYTECODE_VERSION=true
|
75
|
+
|
76
|
+
* if packages build at first but then fail after a few days because Maven tries to connect to the Internet, add the `--option` flag to the `mvn` line in `build.sh`;
|
77
|
+
* if you want to be 100% sure your package builds without network access, you can use scripts in the `utils/` folder to create a special `nonet` user that cannot use the Internet and retry the build from that user.
|
78
|
+
|
79
|
+
## Frequently used sources
|
80
|
+
|
81
|
+
* ant-1.8.1: `wget http://archive.apache.org/dist/ant/source/apache-ant-1.8.1-src.tar.gz -O kit/m2/org/apache/ant/ant/1.8.1/ant-1.8.1-sources.tar.gz`;
|
82
|
+
* ant-1.8.2: `wget http://archive.apache.org/dist/ant/source/apache-ant-1.8.2-src.tar.gz -O kit/m2/org/apache/ant/ant/1.8.2/ant-1.8.2-sources.tar.gz`;
|
83
|
+
* ant-launcher-<version>: sources included in ant-<version>;
|
84
|
+
* ant-nodeps-<version>: sources included in ant-<version>;
|
85
|
+
* antlr-2.7.7: `wget http://www.antlr2.org/download/antlr-2.7.7.tar.gz -O kit/m2/antlr/antlr/2.7.7/antlr-2.7.7-sources.tar.gz`;
|
86
|
+
* asm-3.3.1, asm-commons-3.3.1, asm-tree-3.3.1: `wget http://download.forge.ow2.org/asm/asm-3.3.1.tar.gz -O kit/m2/asm/asm/3.3.1/asm-3.3.1-sources.tar.gz`;
|
87
|
+
* aspectjrt-1.5.3: `wget http://git.eclipse.org/c/aspectj/org.aspectj.git/snapshot/org.aspectj-1_5_3_final.tar.gz -O kit/m2/aspectj/aspectjrt/1.5.3/aspectjrt-1.5.3-sources.tar.gz` (you can remove tests, lib, docs and org.eclipse.jdt.core);
|
88
|
+
* avalon-framework-4.1.5: `wget http://archive.apache.org/dist/avalon/avalon-framework/v4.1.5/avalon-framework-4.1.5.src.tar.gz -O kit/m2/avalon-framework/avalon-framework/4.1.5//4.1.5--sources.tar.gz`;
|
89
|
+
* batik-<subartifact>-1.7: `mkdir kit/m2/org/apache/xmlgraphics/batik/; wget http://archive.apache.org/dist/xmlgraphics/batik/batik-src-1.7.zip -O kit/m2/org/apache/xmlgraphics/batik/batik-sources.zip`
|
90
|
+
* bndlib-0.0.238, bndlib-0.0.255: these are used by apache-felix-1.4.x, which is in turn used by commons-parent < 22 to provide JDK 1.4 compatibility. Unfortunately no source before 1.1 is available, if possible update your dependencies to commons-parent >= 22;
|
91
|
+
* bsh-2.0b4: `wget http://beanshell2.googlecode.com/files/bsh-2.0b4-src.jar -O kit/m2/org/beanshell/bsh/2.0b4/bsh-2.0b4-sources.zip`;
|
92
|
+
* commons-beanutils-core-1.8.0: `wget http://archive.apache.org/dist/commons/beanutils/source/commons-beanutils-1.8.0-src.tar.gz -O kit/m2/commons-beanutils/commons-beanutils-core/1.8.0/commons-beanutils-core-1.8.0-sources.tar.gz`;
|
93
|
+
* commons-beanutils-core-1.8.3: `wget http://archive.apache.org/dist/commons/beanutils/source/commons-beanutils-1.8.3-src.tar.gz -O kit/m2/commons-beanutils/commons-beanutils-core/1.8.3/commons-beanutils-core-1.8.3-sources.tar.gz`;
|
94
|
+
* commons-codec-1.2: `wget http://archive.apache.org/dist/commons/codec/source/commons-codec-1.2-src.tar.gz -O kit/m2/commons-codec/commons-codec/1.2/commons-codec-1.2-sources.tar.gz`;
|
95
|
+
* commons-collections-testframework-3.2.1: included in commons-collections-3.2.1;
|
96
|
+
* commons-collections-2.0: `wget http://archive.apache.org/dist/commons/collections/source/collections-2.0-src.tar.gz -O kit/m2/commons-collections/commons-collections/2.0/commons-collections-2.0-sources.tar.gz`;
|
97
|
+
* commons-jexl-1.1: `wget http://archive.apache.org/dist/commons/jexl/source/commons-jexl-1.1-src.tar.gz -O kit/m2/commons-jexl/commons-jexl/1.1/commons-jexl-1.1-sources.tar.gz`;
|
98
|
+
* commons-lang-1.0: `wget http://archive.apache.org/dist/commons/lang/source/lang-1.0-src.tar.gz -O kit/m2/commons-lang/commons-lang/1.0/commons-lang-1.0-sources.tar.gz`;
|
99
|
+
* commons-logging-api-1.1: `wget http://archive.apache.org/dist/commons/logging/source/commons-logging-1.1-src.tar.gz -O kit/m2/commons-logging/commons-logging/1.1/commons-logging-1.1-sources.tar.gz` (included in commons-logging-1.1);
|
100
|
+
* commons-logging-1.0: `wget http://archive.apache.org/dist/commons/logging/source/logging-1.0-src.tar.gz -O kit/m2/commons-logging/commons-logging/1.0/commons-logging-1.0-sources.tar.gz`;
|
101
|
+
* derby-10.9.1.0: `wget http://archive.apache.org/dist/db/derby/db-derby-10.9.1.0/db-derby-10.9.1.0-src.tar.gz -O kit/m2/org/apache/derby/derby/10.9.1.0/derby-10.9.1.0-sources.tar.gz`;
|
102
|
+
* dom4j-1.1: `wget http://dom4j.cvs.sourceforge.net/viewvc/dom4j/dom4j/?view=tar\&pathrev=dom4j-1-1 -O kit/m2/dom4j/dom4j/1.1/dom4j-1.1-sources.tar.gz`;
|
103
|
+
* doxia-sink-api-1.0-alpha-4: use `svn export http://svn.apache.org/repos/asf/maven/doxia/doxia/tags/doxia-sink-api-1.0-alpha-4/ kit/m2/doxia/doxia-sink-api/1.0-alpha-4/doxia-sink-api-1.0-alpha-4-sources`;
|
104
|
+
* fop-0.95: `wget http://archive.apache.org/dist/xmlgraphics/fop/source/fop-0.95-src.tar.gz -O kit/m2/org/apache/xmlgraphics/fop/0.95/fop-0.95-sources.tar.gz`;
|
105
|
+
* hc-stylecheck-1: contains only metadata, no sources to be compiled in this artifact;
|
106
|
+
* jsr305-1.3.9, jsr305-2.0.1: sources included in jar;
|
107
|
+
* jsch-0.1.38: `wget http://sourceforge.net/projects/jsch/files/jsch/0.1.38/jsch-0.1.38.zip/download -O kit/m2/com/jcraft/jsch/0.1.38/jsch-0.1.38-sources.zip`;
|
108
|
+
* kxml2-2.2.2: use `wget http://sourceforge.net/projects/kxml/files/kxml2/2.2.2/kxml2-src-2.2.2.zip/download -O kit/m2/net/sf/kxml/kxml2/2.2.2/kxml2-2.2.2-sources.zip`;
|
109
|
+
* log4j-1.2.12: `wget http://archive.apache.org/dist/logging/log4j/1.2.12/logging-log4j-1.2.12.tar.gz -O kit/m2/log4j/log4j/1.2.12/log4j-1.2.12-sources.tar.gz`;
|
110
|
+
* naming-common-5.0.28, naming-java-5.0.28: `mkdir -p kit/m2/tomcat/tomcat/5.0.28/; wget http://archive.apache.org/dist/tomcat/tomcat-5/v5.0.28/src/jakarta-tomcat-5.0.28-src.tar.gz -O kit/m2/tomcat/tomcat/5.0.28/tomcat-5.0.28-sources.tar.gz` (part of tomcat);
|
111
|
+
* org.osgi.core-1.0.0: `wget http://archive.apache.org/dist/felix/org.osgi.core-1.0.0.tar.gz -O kit/m2/org/apache/felix/org.osgi.core/1.0.0/org.osgi.core-1.0.0-sources.tar.gz`;
|
112
|
+
* org.osgi.core-4.1.0: sources included in jar;
|
113
|
+
* org.osgi.service.obr-1.0.1: `wget http://archive.apache.org/dist/felix/org.osgi.service.obr-1.0.1-project.tar.gz -O kit/m2/org/apache/felix/org.osgi.service.obr/1.0.1/org.osgi.service.obr-1.0.1-sources.tar.gz`;
|
114
|
+
* plexus-utils-1.4.9: `wget https://github.com/sonatype/plexus-utils/archive/plexus-utils-1.4.9.tar.gz -O kit/m2/org/codehaus/plexus/plexus-utils/1.4.9/plexus-utils-1.4.9-sources.tar.gz`;
|
115
|
+
* spymemcached-2.6: `wget http://spymemcached.googlecode.com/files/memcached-2.4.2-sources.zip -O kit/m2/spy/spymemcached/2.6/spymemcached-2.6-sources.zip`;
|
116
|
+
* stringtemplate-3.2: `wget http://www.stringtemplate.org/download/stringtemplate-3.2.tar.gz -O kit/m2/org/antlr/stringtemplate/3.2/stringtemplate-3.2-sources.tar.gz`;
|
117
|
+
* velocity-tools-2.0: `wget http://archive.apache.org/dist/velocity/tools/2.0/velocity-tools-2.0-src.tar.gz -O kit/m2/org/apache/velocity/velocity-tools/2.0/velocity-tools-2.0-sources.tar.gz`;
|
118
|
+
* velocity-1.5: `wget http://archive.apache.org/dist/velocity/engine/1.5/velocity-1.5.tar.gz -O kit/m2/org/apache/velocity/velocity/1.5/velocity-1.5-sources.tar.gz`;
|
119
|
+
* trilead-ssh2-build213-svnkit-1.3: `svn export http://svn.svnkit.com/repos/svnkit/tags/1.3.5/ kit/m2/org/tmatesoft/svnkit/svnkit/1.3.5/svnkit-1.3.5-sources` (included in svnkit 1.3.5 full sources because of custom patch);
|
120
|
+
* xercesImpl-2.9.1: `wget http://archive.apache.org/dist/xerces/j/source/Xerces-J-src.2.9.1.tar.gz -O kit/m2/xerces/xercesImpl/2.9.1/xercesImpl-2.9.1-sources.tar.gz`;
|
121
|
+
* xercesMinimal-1.9.6.2: included in any xercesImpl >= 2 source package;
|
122
|
+
* xml-apis-ext-1.3.04: `wget http://archive.apache.org/dist/xml/commons/xml-commons-external-1.3.04-src.tar.gz -O kit/m2/xml-apis/xml-apis-ext/1.3.04/xml-apis-ext-1.3.04-sources.tar.gz`;
|
123
|
+
* xmlgraphics-commons-1.3.1: `wget http://archive.apache.org/dist/xmlgraphics/commons/source/xmlgraphics-commons-1.3.1-src.tar.gz -O kit/m2/org/apache/xmlgraphics/xmlgraphics-commons/1.3.1/xmlgraphics-commons-1.3.1-sources.tar.gz`;
|
124
|
+
* xmlpull-1.1.3.1: `wget http://www.extreme.indiana.edu/xmlpull-website/v1/download/xmlpull_1_1_3_4c_src.tgz -O kit/m2/xmlpull/xmlpull/1.1.3.1/xmlpull-1.1.3.1-sources.tar.gz`;
|
125
|
+
* xpp3-1.1.3.3: `wget http://www.extreme.indiana.edu/dist/java-repository/xpp3/distributions/xpp3-1.1.3.4.C_src.tgz -O kit/m2/xpp3/xpp3/1.1.3.3/xpp3-1.1.3.3-sources.tar.gz`;
|
126
|
+
* xmlunit-1.3: `wget http://sourceforge.net/projects/xmlunit/files/xmlunit%20for%20Java/XMLUnit%20for%20Java%201.3/xmlunit-1.3-src.zip/download -O kit/m2/xmlunit/xmlunit/1.3/xmlunit-1.3-sources.zip`;
|
data/lib/gjp.rb
CHANGED
data/lib/gjp/cli.rb
CHANGED
@@ -215,7 +215,7 @@ module Gjp
|
|
215
215
|
end
|
216
216
|
end
|
217
217
|
|
218
|
-
subcommand "
|
218
|
+
subcommand "move-jars-to-kit", "Locates jars in src/ and moves them to kit/" do
|
219
219
|
def execute
|
220
220
|
checking_exceptions do
|
221
221
|
project = Gjp::Project.new(".")
|
@@ -229,7 +229,7 @@ module Gjp
|
|
229
229
|
end
|
230
230
|
end
|
231
231
|
|
232
|
-
subcommand "
|
232
|
+
subcommand "download-maven-source-jars", "Attempts to download Maven kit/ sources" do
|
233
233
|
def execute
|
234
234
|
checking_exceptions do
|
235
235
|
project = Gjp::Project.new(".")
|
@@ -254,34 +254,6 @@ module Gjp
|
|
254
254
|
end
|
255
255
|
end
|
256
256
|
|
257
|
-
subcommand "set-up-nonet-user", "Sets up a \"nonet\" user that cannot access the network" do
|
258
|
-
def execute
|
259
|
-
checking_exceptions do
|
260
|
-
user = Gjp::LimitedNetworkUser.new("nonet")
|
261
|
-
user.set_up
|
262
|
-
|
263
|
-
"sudo #{user.get_path("useradd")} nonet\n" +
|
264
|
-
"sudo #{user.get_path("iptables")} -A OUTPUT -m owner --uid-owner nonet -j DROP\n" +
|
265
|
-
"User \"nonet\" set up, you can use \"sudo nonet\" to dry-run your build with no network access.\n" +
|
266
|
-
"Note that the above iptables rule will be cleared at next reboot, you can use your distribution " +
|
267
|
-
"tools to make it persistent or run \"gjp set-up-limited-nertwork-user\" again next time."
|
268
|
-
end
|
269
|
-
end
|
270
|
-
end
|
271
|
-
|
272
|
-
subcommand "tear-down-nonet-user", "Deletes a user previously created by gjp" do
|
273
|
-
def execute
|
274
|
-
checking_exceptions do
|
275
|
-
user = Gjp::LimitedNetworkUser.new("nonet")
|
276
|
-
|
277
|
-
user.tear_down
|
278
|
-
|
279
|
-
"sudo #{user.get_path("iptables")} -D OUTPUT -m owner --uid-owner nonet -j DROP\n" +
|
280
|
-
"sudo #{user.get_path("userdel")} nonet\n"
|
281
|
-
end
|
282
|
-
end
|
283
|
-
end
|
284
|
-
|
285
257
|
subcommand "get-pom", "Retrieves a pom file" do
|
286
258
|
parameter "NAME", "a jar file name or a `name-version` string (heuristic)"
|
287
259
|
def execute
|
data/lib/gjp/version.rb
CHANGED
metadata
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: gjp
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 0.
|
4
|
+
version: 0.33.0
|
5
5
|
prerelease:
|
6
6
|
platform: ruby
|
7
7
|
authors:
|
@@ -9,7 +9,7 @@ authors:
|
|
9
9
|
autorequire:
|
10
10
|
bindir: bin
|
11
11
|
cert_chain: []
|
12
|
-
date:
|
12
|
+
date: 2014-01-07 00:00:00.000000000 Z
|
13
13
|
dependencies:
|
14
14
|
- !ruby/object:Gem::Dependency
|
15
15
|
name: rake
|
@@ -151,8 +151,10 @@ files:
|
|
151
151
|
- Gemfile
|
152
152
|
- Gemfile.lock
|
153
153
|
- LICENSE
|
154
|
+
- MOTIVATION.md
|
154
155
|
- README.md
|
155
156
|
- Rakefile
|
157
|
+
- SPECIAL_CASES.md
|
156
158
|
- bin/gjp
|
157
159
|
- gjp.gemspec
|
158
160
|
- integration-tests/commons.sh
|
@@ -164,7 +166,6 @@ files:
|
|
164
166
|
- lib/gjp/kit_checker.rb
|
165
167
|
- lib/gjp/kit_runner.rb
|
166
168
|
- lib/gjp/kit_spec_adapter.rb
|
167
|
-
- lib/gjp/limited_network_user.rb
|
168
169
|
- lib/gjp/logger.rb
|
169
170
|
- lib/gjp/maven_runner.rb
|
170
171
|
- lib/gjp/maven_website.rb
|
@@ -207,7 +208,6 @@ files:
|
|
207
208
|
- spec/lib/git_spec.rb
|
208
209
|
- spec/lib/kit_checker_spec.rb
|
209
210
|
- spec/lib/kit_runner_spec.rb
|
210
|
-
- spec/lib/limited_network_user_spec_interactive.rb
|
211
211
|
- spec/lib/maven_runner_spec.rb
|
212
212
|
- spec/lib/maven_website_spec.rb
|
213
213
|
- spec/lib/pom_getter_spec.rb
|
@@ -219,6 +219,8 @@ files:
|
|
219
219
|
- spec/lib/template_manager_spec.rb
|
220
220
|
- spec/lib/version_matcher_spec.rb
|
221
221
|
- spec/spec_helper.rb
|
222
|
+
- utils/delete_nonet_user.sh
|
223
|
+
- utils/setup_nonet_user.sh
|
222
224
|
homepage: https://github.com/SilvioMoioli/gjp
|
223
225
|
licenses:
|
224
226
|
- MIT
|
@@ -266,7 +268,6 @@ test_files:
|
|
266
268
|
- spec/lib/git_spec.rb
|
267
269
|
- spec/lib/kit_checker_spec.rb
|
268
270
|
- spec/lib/kit_runner_spec.rb
|
269
|
-
- spec/lib/limited_network_user_spec_interactive.rb
|
270
271
|
- spec/lib/maven_runner_spec.rb
|
271
272
|
- spec/lib/maven_website_spec.rb
|
272
273
|
- spec/lib/pom_getter_spec.rb
|
@@ -1,64 +0,0 @@
|
|
1
|
-
# encoding: UTF-8
|
2
|
-
|
3
|
-
require 'find'
|
4
|
-
|
5
|
-
module Gjp
|
6
|
-
# encapsulates a Linux user that cannot access the Internet
|
7
|
-
# assumes root access (sudo) and iptables are available
|
8
|
-
class LimitedNetworkUser
|
9
|
-
include Logger
|
10
|
-
|
11
|
-
def initialize(name)
|
12
|
-
@name = name
|
13
|
-
end
|
14
|
-
|
15
|
-
# creates a new Linux user without Internet access,
|
16
|
-
# if it does not exists
|
17
|
-
def set_up
|
18
|
-
log.debug "checking #{@name} user existence..."
|
19
|
-
if not user_exists?
|
20
|
-
log.debug "...not found. Setting up..."
|
21
|
-
`sudo #{get_path("useradd")} #{@name}`
|
22
|
-
`sudo #{get_path("passwd")} #{@name}`
|
23
|
-
log.debug "...set up"
|
24
|
-
end
|
25
|
-
|
26
|
-
if not firewall_rule_exists?
|
27
|
-
log.debug "...not found. Setting up..."
|
28
|
-
`sudo #{get_path("iptables")} -A OUTPUT -m owner --uid-owner #{@name} -j DROP`
|
29
|
-
log.debug "...set up"
|
30
|
-
end
|
31
|
-
end
|
32
|
-
|
33
|
-
# deletes a Linux user previously created by this class
|
34
|
-
def tear_down
|
35
|
-
if firewall_rule_exists?
|
36
|
-
`sudo #{get_path("iptables")} -D OUTPUT -m owner --uid-owner #{@name} -j DROP`
|
37
|
-
end
|
38
|
-
|
39
|
-
if user_exists?
|
40
|
-
`sudo #{get_path("userdel")} #{@name}`
|
41
|
-
end
|
42
|
-
end
|
43
|
-
|
44
|
-
# determines if a user without Internet access exists
|
45
|
-
def set_up?
|
46
|
-
user_exists? && firewall_rule_exists?
|
47
|
-
end
|
48
|
-
|
49
|
-
# checks user existence
|
50
|
-
def user_exists?
|
51
|
-
`id #{@name} 2>&1`.match(/no such user$/) == nil
|
52
|
-
end
|
53
|
-
|
54
|
-
# checks firewall rule existence
|
55
|
-
def firewall_rule_exists?
|
56
|
-
`sudo #{get_path("iptables")} -L`.match(/owner UID match #{@name}/) != nil
|
57
|
-
end
|
58
|
-
|
59
|
-
# returns a command's full path
|
60
|
-
def get_path(command)
|
61
|
-
`sudo which #{command}`.strip
|
62
|
-
end
|
63
|
-
end
|
64
|
-
end
|
@@ -1,39 +0,0 @@
|
|
1
|
-
# encoding: UTF-8
|
2
|
-
|
3
|
-
require 'spec_helper'
|
4
|
-
|
5
|
-
describe Gjp::LimitedNetworkUser do
|
6
|
-
let(:user) { Gjp::LimitedNetworkUser.new("nonet_test") }
|
7
|
-
|
8
|
-
before(:each) do
|
9
|
-
user.set_up
|
10
|
-
end
|
11
|
-
|
12
|
-
after(:each) do
|
13
|
-
if user.set_up?
|
14
|
-
user.tear_down
|
15
|
-
end
|
16
|
-
end
|
17
|
-
|
18
|
-
describe "#set_up" do
|
19
|
-
it "set_ups a limited network user" do
|
20
|
-
user.set_up?.should be_true
|
21
|
-
end
|
22
|
-
end
|
23
|
-
|
24
|
-
describe "#tear_down" do
|
25
|
-
it "tears down a limited network user" do
|
26
|
-
user.tear_down
|
27
|
-
user.set_up?.should be_false
|
28
|
-
end
|
29
|
-
end
|
30
|
-
|
31
|
-
describe "#set_up?" do
|
32
|
-
it "checks if a limited network user has been set up" do
|
33
|
-
user.set_up?.should be_true
|
34
|
-
|
35
|
-
user.tear_down
|
36
|
-
user.set_up?.should be_false
|
37
|
-
end
|
38
|
-
end
|
39
|
-
end
|