[racket] Racket on Centos?

[George Neuner]

Hi all,

I am looking at a possible deployment on a Centos based cloud VM and I
won't have a compiler available to build Racket locally. Is there a
pre-made distribution (preferably 6.0.1) that runs on Centos 6 or 7?

If not, how hard would it be to compile Racket on a separate Centos
machine and then install it to the cloud VPS? [He asks naively never
having built Racket before.]

Thanks,
George

____________________
Racket Users list:
http://lists.racket-lang.org/users

[Alexis King]

I don’t believe there are any prebuilt CentOS Racket distributions available, so I can’t help you there. I will say, however, that I recently built Racket from source for the first time, and I found it remarkably easy. I cloned the repo, ran make, and I was done.

Building from source can take some time, though, mostly since it needs to compile all the packages. You can download the Unix Source + built packages distribution from download.racket-lang.org, though, which contains the package bytecode pre-compiled. The bytecode is platform-independent, so you’ll only have to build the core, not the packages.

Someone else might be more knowledgable in that area than I am, but I’m guessing that’s the best you’re going to get unless there’s a CentOS distribution I’m not aware of.

[Neil Van Dyke]

If you want to do this without the additional work to create CentOS
packages... I suspect you'd get the best results by building Racket on a
different machine/VM that mimics the target VM, then just copy files to
the target VM.

Specifically, set up a beefier CentOS install (on a spare machine or in
a different VM, or even in a temporarily beefier-than-usual server
instance by the provider for your target VM) that mimics the
architecture and distro version (6.0.1) of your target VM closely, and
build Racket on that. I recommend building to put Racket in its own
install tree, with `--prefix=/usr/local/racket-6.1.1` or at least
`--prefix=/usr/local/racket`.

In the course of getting it to build, you'll probably install on your
builder a bunch of libraries/packages that are not on your target VM,
and write down each one for later. (Ideally, all of these can be
installed as CentOS packages on target VM. If not, you'll probably end
up with the non-ideal practice of building against CentOS package shared
libraries, and then copying shared libraries to target VM, where they
will unfortunately be outside management of the package system.)

Then, once built and tested, make a script that copies to your target VM
both the the Racket install tree and any necessary libraries and such
(from packages that cannot otherwise be installed on your target VM).
(Script is because you'll usually do this many times (to get it to work,
then for different Racket versions or different VMs), and want
time-saving and repeatability.) Another script to install any CentOS
packages on target VM that *can* be installed that way.

Finally, cross your fingers, and test it on target VM.

Neil V.

[George Neuner]

Alexis and Neil,

Thanks both for your advice.

On 1/17/2015 12:56 AM, Alexis King wrote:
> I will say, however, that I recently built Racket from source for the
> first time, and I found it remarkably easy. I cloned the repo, ran
> make, and I was done.

I assume it was on a familiar platform, but I'm happy to hear it was easy.

On 1/17/2015 1:26 AM, Neil Van Dyke wrote:
> Finally, cross your fingers, and test it on target VM.

It's the "cross you fingers" part that worries me. I'd be happier if I
knew others already had done it successfully. I've never worked with
CentOS and it's been a long while since Redhat. I work with Ubuntu and
occasionally with SUSE. Very different admin environments.

My problem is the client's provider: they will give me any Linux I want
but they only provide management services for CentOS. The client has no
management capability as yet and and I don't really want be their sysop
indefinitely.

I guess I'm going to have to set up a CentOS machine and try it out.

Thanks,
George

[Neil Van Dyke]

George Neuner wrote on 01/17/2015 04:58 PM:
>
> On 1/17/2015 1:26 AM, Neil Van Dyke wrote:
>> Finally, cross your fingers, and test it on target VM.
>
> It's the "cross you fingers" part that worries me. I'd be happier if
> I knew others already had done it successfully. I've never worked
> with CentOS and it's been a long while since Redhat. I work with
> Ubuntu and occasionally with SUSE. Very different admin environments.
>

Two more important things I forgot to mention last night:

* Being CentOS, your target VM might require SELinux labeling. If so,
you *might* want to figure that out on your build machine rather than on
the target VM.

* You might need make sure Linux address space layout randomization is
not enabled, or face bizarre intermittent failures of your app. (This is
a general OS issue for some GC'd language runtimes, and might still be
with Racket, regardless of how Racket is built and packaged.)

Other than those two, if it's done the way I said, and the initial test
on the target VM is good, that's a reasonable approach, and you're
probably golden. (The alternative to copying install tree from a
mimicing system would be to make a good CentOS package, including
getting the version dependencies proper in face of future automatic
security updates and such, but that alternative might be significantly
more learning and work. You don't want a poorly-done CentOS package,
regardless of whether you or someone else made it. But if this is a
small intranet app or similar, client might not want to invest in making
sure they have a good CentOS package, rather than just having a solid
way of copying over a normal install tree from mimic system.)

RHEL (CentOS) is the most solid enterprise server distro, so no worries
there. It's just (last time I looked) more intimidating than other
popular distros, if you just want to do a naive, one-off install.

> My problem is the client's provider: they will give me any Linux I
> want but they only provide management services for CentOS.

(Just noting this in general for the email list...) Since client has
people who maintain the CentOS VMs, depending on how much control they
exercise, and how much they want to know or be responsible for, it might
be a courtesy/obligation to touch bases with sys-admins on what you're
doing. They also might be able to help you out (e.g., they make sure
that the CentOS library packages you need are installed, make sure that
things like address space randomization won't get turned on later,
inform you of any VM provisioning considerations, etc.), and they might
have requests (e.g., provide SELinux labeling, don't copy libraries into
standard directories, put Racket somewhere other than /usr/local/, don't
store your persistent data on a particular filesystem, etc.). Sys-admin
is often misunderstood and under-appreciated, but the quality of its
decisions and practices can have a huge impact on the success of your
project/organization, similar to the quality of the software
developers. (Also, touching base might tell you whether the sys-admin
is actually more a reactive-only type, which info might affect how you
advise client on how to manage an important app's hosting.)

Neil V.

[Neil Toronto]

On 01/17/2015 06:59 PM, Neil Van Dyke wrote:
>
> George Neuner wrote on 01/17/2015 04:58 PM:
>>
>> On 1/17/2015 1:26 AM, Neil Van Dyke wrote:
>>> Finally, cross your fingers, and test it on target VM.
>>
>> It's the "cross you fingers" part that worries me. I'd be happier if
>> I knew others already had done it successfully. I've never worked
>> with CentOS and it's been a long while since Redhat. I work with
>> Ubuntu and occasionally with SUSE. Very different admin environments.
>>
>
> Two more important things I forgot to mention last night:
>
> * Being CentOS, your target VM might require SELinux labeling. If so,
> you *might* want to figure that out on your build machine rather than on
> the target VM.
>
> * You might need make sure Linux address space layout randomization is
> not enabled, or face bizarre intermittent failures of your app. (This is
> a general OS issue for some GC'd language runtimes, and might still be
> with Racket, regardless of how Racket is built and packaged.)

Ubuntu has had ASLR enabled by default since 10.04 (about five years).
During that time, in my experience, it's never affected Racket.

I do have to use "setarch i686 -R" to disable ASLR to run Maxima, which
is written in Common Lisp. So it's a problem for some GC'd runtimes, but
apparently not our favorite one. :D

Neil ⊥

[Neil Van Dyke]

Neil Toronto wrote on 01/17/2015 07:57 PM:
>
> Ubuntu has had ASLR enabled by default since 10.04 (about five years).
> During that time, in my experience, it's never affected Racket.
>
> I do have to use "setarch i686 -R" to disable ASLR to run Maxima,
> which is written in Common Lisp. So it's a problem for some GC'd
> runtimes, but apparently not our favorite one. :D

You could be right; I'm fuzzy on this, due to one experience. A few
years ago, one of my clients ran into a problem with long-running Racket
server processes on Ubuntu that (in native stack trace) looked like
ASLR. Problem disappeared once ASLR was disabled. They were probably
still using the `cgc` (not `3m`) collector at that time, and it was
probably around the time they migrated to Ubuntu Server 10.04.

(Then again, they might've still had some C extensions in their Racket
app at that time, so all bets are off. The C code quality was good, as
C code quality goes, but still. I eventually replaced all the C code in
that app with pure Racket and external native processes, for various
other reasons. A lot of uncontrolled variables here, but I recall no
problems like the ones we thought were ASLR, since we disabled ASLR. If
it turns out that ASLR is a problem, it's a bad enough and
hard-to-diagnose problem that everyone putting apps into production
needs to know about it.)

[Greg Hendershott]

Up through version 5.3.6 there was a Fedora build of Racket, and as of
a couple years ago I used it on "Amazon Linux" (which IIUC is ~=
CentOS). I vaguely recall needing to symlink one .so to the name
Racket expected, but otherwise I don't remember any problems.

(Although I'm not sure why Racket dropped the Fedora build after
5.3.6, it's been n/a for me because more recently, when I've made an
Amazon EC2 instance or Digital Ocean droplet, it's been fine for my
simple purposes to use Ubuntu.)

[Juan Francisco Cantero Hurtado]

ASLR is not a problem with racket, unless you build the libs as non-PIC
and the binaries as non-PIE (i.e. changing the defaults).

The problem with the GCs and JITs are related to the mixing of
executable and writable pages [1][2]. Linux allows partially this type
of operations but some security-focused extensions like SELinux or
grsecurity follow the opposite approach.

Fortunately, SELinux will notify which rule is violating racket.


1.
https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Restrict_mprotect.28.29
2.
https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Emulate_trampolines

[Juan Francisco Cantero Hurtado]

On 01/18/2015 06:21 AM, Greg Hendershott wrote:
> Up through version 5.3.6 there was a Fedora build of Racket, and as of
> a couple years ago I used it on "Amazon Linux" (which IIUC is ~=
> CentOS). I vaguely recall needing to symlink one .so to the name
> Racket expected, but otherwise I don't remember any problems.
>
> (Although I'm not sure why Racket dropped the Fedora build after
> 5.3.6, it's been n/a for me because more recently, when I've made an
> Amazon EC2 instance or Digital Ocean droplet, it's been fine for my
> simple purposes to use Ubuntu.)

Apparently, there is a repo with racket for CentOS and Fedora:
https://copr.fedoraproject.org/coprs/mordae/racket/

[Robby Findler]

For now, I've added a Fedora snapshot build here:

http://plt.eecs.northwestern.edu/snapshots/

Robby

[George Neuner]

Hi all,

Maybe not the right place for this, but I'm not in the developer list.

I've built racket for CentOS 6.6 from the latest snapshot. It's working
fine, but now I need to transport it to a different machine. I can't
find any installation scripts or templates to follow. Are there scripts
available? Or a list of links and environment variables to create and set?


To Robby Findler:
I tried the Fedora snapshot, but on CentOS 6 several libraries were the
wrong versions. Updating them broke all kinds of things, so I had to
build a native version. Thanks anyway.

[Neil Van Dyke]

I always build it to put all of Racket into a single directory tree, by
adding an argument like `--prefix=/usr/local/racket-6.1.1` when I do the
"./configure" part of the build.

One of my clients simply copies one of these install trees around to
many servers (running the same GNU/Linux distro version), and that's
worked perfectly for years.

If you do it this way, there's not much else to do (if the target
machine otherwise has the shared libraries on which Racket depends but
does not include).
On servers, I just have the application-specific stuff set an
application-specific environment variable for the path to Racket version
install to use, and everything else about the app uses that variable.
(This is also used when running the app on a workstation.)
On your workstation, for convenience on command lines that you type
manually, you can add the path to the desired Racket installation, to
your shell's `PATH` or `path` environment variable, but I suggest *not*
doing that on server.

Neil V.

[George Neuner]

Hi Neil,

On 2/4/2015 7:34 PM, Neil Van Dyke wrote:
> I always build it to put all of Racket into a single directory tree,
> by adding an argument like `--prefix=/usr/local/racket-6.1.1` when I
> do the "./configure" part of the build.
>
> One of my clients simply copies one of these install trees around to
> many servers (running the same GNU/Linux distro version), and that's
> worked perfectly for years.

Do you just 'make install' and tar the /usr/... directory or do you
use DESTDIR=<something> and tar that? I don't suppose it really makes a
difference.

> If you do it this way, there's not much else to do (if the target
> machine otherwise has the shared libraries on which Racket depends but
> does not include).

Crossing my fingers there. CentOS 6 is still using GCC 4.4.7 so that's
what I'm building with.

> On servers, I just have the application-specific stuff set an
> application-specific environment variable for the path to Racket
> version install to use, and everything else about the app uses that
> variable. (This is also used when running the app on a workstation.)
> On your workstation, for convenience on command lines that you type
> manually, you can add the path to the desired Racket installation, to
> your shell's `PATH` or `path` environment variable, but I suggest
> *not* doing that on server.

Good advice re: the server.

Thanks,
George

[Neil Van Dyke]

George Neuner wrote on 02/04/2015 10:28 PM:
>
> Do you just 'make install' and tar the /usr/... directory or do you
> use DESTDIR=<something> and tar that? I don't suppose it really makes
> a difference.

Just the `--prefix`; no `DESTDIR`.

[Steve Graham]

Neil,

   Out of curiosity, what kind of application have you developed for your client?  Did you have to justify your use of Racket?  Why did you choose Racket?

Steve

---

From: Neil Van Dyke <ne...@neilvandyke.org>
To: George Neuner <gneu...@comcast.net>; users <us...@racket-lang.org>
Sent: Wednesday, February 4, 2015 4:34 PM
Subject: Re: [racket] Racket on Centos?

[Neil Van Dyke]

Steve Graham wrote on 02/05/2015 02:24 PM:
> Out of curiosity, what kind of application have you developed for
> your client? Did you have to justify your use of Racket? Why did you
> choose Racket?

That particular system was originally developed by others, I've been
consulting to help them evolve it, and... NDA.

There are a various anecdotes and perspectives you'll hear from people
who developed systems using atypical languages/platforms. For example,
there are public comments by someone at ITA (since acquired by Google),
who developed a large system in CL, and who said something like they
thought doing it without some of the CL features was impossible.
(Racket happens to share those features, and overall I much prefer
Racket to CL.) I think the best reason to choose an atypical
language/platform is because it gives you a strategic advantage. (For
Racket, a likely strategic advantage is its metalanguage strength.)

There is also a funny side benefit in that, if you choose an atypical
language that some of the sharpest and most knowledgeable people
gravitate towards disproportionately, this seems to result in you being
able to hire a caliber talent that you probably couldn't otherwise. For
example, it's public knowledge that ITA hired a dream team of noteworthy
Lisp and CS people, for a project that I suspect didn't otherwise sound
attractive to most people. I suspect the attraction for many was the
chance to do big things with Lisp, or to work with other noteworthy
people. If this is sounding similar to some of the attraction of, say,
Google, I think it is -- only, unlike the "Google" household word, it
just usually doesn't impress your family and friends (unless they are CS
people).

If you're trying to get some kind of approval for your platform choices,
such as from established-company executives or startup investors... that
can be hard. You really have to bring the goods, so that the unfamiliar
seems a worthwhile risk. And, if you're successful thus far, you might
have to renew that faith periodically, whenever it's time for another
dose of architecture investment.

In a different situation, if you're doing moonlighting projects, like
apps and Web sites, without investors&executives&managers... you can
have reasons that would be harder sells than obvious strategic
advantage, like "I feel more productive with it", "it's more fun",
"parentheses are aesthetically pleasing (though pound-colon is not)",
and "I can search/ask a question about the platform, and get a high
signal:noise ratio."