Please wait...
Current jenkins must run on Java 8.
Therefore, if you're hosting it on Ubuntu via openjdk, you'll need Ubuntu >= 16.04.
It's also possible to install Java <=7 on Ubuntu 16.04, but only via the previously-mentioned openjdk PPA (which has a few backport issues with timezones), or via the Oracle released which is EOL'd, or via the extended-support Oracle release.
This Java <=7 is not used for running Jenkins itself, which requires Java 8. But it can be used in a more limited way for building Java projects that are incompatible with Java 8; basically, your Java8 Jenkins is forking a Java7 child process in this case. Jenkins Freestyle projects work fine for this purpose. I think Jenkins Maven-mode projects also have some limited support in this area, but there are definitely issues that may require moving to Freestyle, and I'm having trouble remembering all the details at this point.
Hrm... so pushing a slave.jar out to the client and expecting it to work with Java <= 7 doesn't really sound like an option, which was what I had hoped to do.
I have to instead do the nfs/ssh-script thing.
2018-05-14 14:53 from fleeb @uncnsrd
Hrm... so pushing a slave.jar out to the client and expecting it to
work with Java <= 7 doesn't really sound like an option, which was what
I had hoped to do.
Not sure what you mean by this.
From Jenkins, click on 'Build Executor Status', then 'New Node'. Create a new node as a 'Permanent Agent'. Go to 'Launch method' and select 'Launch slave agents via SSH'.
This pushes a 'slave.jar' file out to the client machine and executes it to establish the slave.
At least, it did in version 2.32.3. Maybe things are different in the current versions.
Can you upgrade your slave to include java 8? I know you might be thinking that you'd need to upgrade your OS distribution to something that includes openjdk8, etc, but an alternative is the Oracle release that should run on some older distributions
I've tried installing Oracle's Java 8 on the machine, but it won't run. I think they built their VM on something a tad more modern than this machine.
Rightfully so, frankly. But frustrating for me, heh.
I also took a look at building OpenJDK on the box, but that looks formidable (in that the build environment has dependencies that also pose problems).
No, you don't want to try to build openjdk as a backport. Supported distributions or nothing.
My suggestion would be that you can continue to use the jenkins master to kick off jobs when something is checked into source control--jobs can run on the master as well. the job should be a small script that just SSHs over to your slave and builds the stuff that you need built on old distros.
Or you can hire a new build monkey.... *runs*
alternate possibility... ensure that all jenkins masters or slaves are running java 8. upgrade distribution if necessary, etc.
do the builds within a Docker environment (or, failing that, a simple chroot jail) that's based on a much older userland.
so that way it's all running locally, no sshing across the network to build hosts that must be maintained on some ancient distribution.
This is probably the more sustainable, long term supportable path since you'll no longer have hardware dependencies related to old distros. All virtual.
Or you can hire a new build monkey.... *runs*
I thought that they already had one.
Hehehehe. Well done LS.
Oy.
As if this cheap-ass company would hire anyone else.
The docker idea is interesting... I don't have much experience reaching out of the docker environment and into the host environment, but it seems like one ought to be able to nfs locally that way or something.
Hmm.
Twisty, but probably sustainable.
I have another subject of bitching, though.
This ODBC thing originated on Windows, I believe, but has a reasonable unix variant in 'unixodbc'. It's good enough that you can write code once and have it work with databases across both operating systems and engines reasonably well (as long as you aren't attempting to do anything particularly fancy).
Unfortunately, back in 2011, unixodbc decided to release a libodbc.so.2 when they added a SQLLEN for 64-bits (if I am reading this correctly). That is to say, they provide a minor ABI change to add a new function, but rather than naming the so libodbc.so.1.1 or something, they jump to libodbc.so.2.
Even on http://www.unixodbc.org/ itself, they say "So if after installing you have apps that can't find libodbc.so, it's likely they are linked to libodbc.so.1, so just create a symlink from libodbc.so.2."
Grrr.
It's funny in some ways. Elsewhere in the internet, you can see some people waxing poetic about how OpenOffice should "Do the right thing" and link to the major version of libodbc instead of libodbc.so, because obviously if the major version changed than they're taking a big risk, yadda yadda yadda... not even realizing that unixodbc themselves kinda did the wrong thing, probably causing OpenOffice to do that.
It's annoying to me, though, because I have to package something that needs to account for this.
I suspect I'm going to do something else. Link to libodbc.so.1, and if I can't find it (but can find libodbc.so.2), symlink in my own lib and hope I find it.
Yeah, so this Java thing that frustrates me...
Speaking of Java ...
The wise oracles at Oracle have decided, in their infinite "wisdom," to drop support for serialization in the Java language.
[ https://tinyurl.com/java-serial-fail ]
Evidently there are security bugs in it, so instead of fixing the bugs, they're just going to drop support for the language feature entirely.
Thoughts about this? It seems you need serialization any time you want to write a complex data object to disk, or to the network, or to a dot matrix printer (ok, strike that last one). I remember thinking, when I learned Java some two decades ago, that it was great that they put serialization right into the language, so that we'd never need to write serialization/deserialization functions for every object we wanted to write to disk/network.
Python doesn't seem to have this problem with its JSON support.
If I remember correctly, Java's serialization includes the methods as well as the state. That's ultimately where they went wrong with it, as it's difficult if not impossible to maintain security while allowing a feature as powerful as that into the language.
JSON can't store methods, so it only stores state. Ergo, Python's safer that way.
I'm pretty sure you can find serialization libraries that stream Java's objects into JSON strings, so while they might kill native serialization, they won't be crippled. You just won't be able to stream the methods across like you used to... and frankly, you probably shouldn't rely upon that in the first place if you seriously care about security.
Although... this does point at a trend I've noticed lately.
Software engineers were expected to be responsible, long ago. You had a lot of power to write your software using all kinds of nifty and fun tools, some with serious risks, but it was expected that you understood the risks, and found them acceptable.
Today, software engineers are thought to not have a sense of responsibility, and to require hand holding, to a certain degree. Features must be removed or shunted into less-accessible locations because of this irresponsibility.
And, frankly, it's deserved... because a lot of them have been irresponsible, and by not following (or even knowing) the best practices for a particularly language or bit of software, exposed their respective environments to Terrible Things that have apparently done Terrible Things to people and companies.
So, yeah... my job gets slightly more difficult all the time, as everything gets further locked down due to security concerns. But, I guess it helps keep me employed. I kind of fear for the generation after me, though, who won't know the history.
we don't know how to do I/O safely. that's not new: C has buffer overruns, XML has external entity issues, JavaScript/JSON will give you grief if you do JSON the lazy way by just sourcing files. I question the idea that the solution is to stop doing I/O
If I remember correctly, Java's serialization includes the methods as
well as the state. That's ultimately where they went wrong with it, as
It doesn't.
If it did, then yes that would be an obvious attack surface a mile wide.
It would be like SQL injection on steroids.
Hrm... then I stand corrected.
I just recall being able to send methods over TCP/IP back in Java's early days, and I thought to myself, "Neato!" Today's me thinks, "Oh no."
But, maybe it wasn't through serialization, but some other mechanism that's similar. I can't recall. It's literally over 20 years ago I did it.