[Feature] Better CentOS support

I use mostly CentOS while at work (other than my windows host machine) and I've tried to manually build and get code-server to work, which I finally did, but it seemed to be missing a lot of features.

I couldn't get extensions to stay, they would be disabled on restart and i would have to 'reinstall them' to use them. Even when I simply changed what folder I was working out of.

When messing with workspaces, I would often 'cache brick' (thats the only way I could think of describing it) where I would only get a blank screen and not be able to load the page at all. The only way I would be able to use it was through incognito. (Though I didn't try clearing my cache, but assume thats the issue since incognito worked).

From what I could see, there were 0 supported languages by default, so kind of needed an extension to do anything.

As a side, I did try the docker solution, but it would run as root which is not ideal for me since I wouldn't have access to my personal set up and any terminals i open would be root. It did seem to actually run better though since I assume it was running on an ubuntu container.

Master had some extension loading issues. These will be resolved in the latest release.

We'll fix up the docker container ASAP.

@krazyito65

@krazyito65 While you're waiting, would you be able to try RHEL 8 Beta? It's free for developers in RHD, and Coder works in that

I need a license/account for that? The only access I have to RHEL as far as I know are the VMs that are provisioned by our corporate Unix engineering team.

If I'm mistaken, please elaborate more

edit: I see. Theres a 'no-cost' option for the beta. I'll see if i can get a chance to try that out.

Master had some extension loading issues. These will be resolved in the latest release.

Is this fix in 1.32.0-245 ? Can I try to build from source to see if it fixes the extension issue?

Ok, so I tested it a little bit more.

edit: (Ignore this first part, read below)
first, I used the binary in 1.32.0-245: Extensions seemed better, but It would not do any syntax coloring for Python or shell. Even though I had the magic python extension installed. I would expect to normally have some kind of python and shell syntax coloring by default. The Ruby syntax coloring seemed to work fine, but that's probably due to the extension.

Then I tried to build from source, from this commit: (newest from when I'm typing) e3d9716

Python coloring seemed to work, but not shell (and I'm assuming here its becasue I don't have an extension for it). I also noticed that git wasn't working and showing as 'no scm prodivded'

I went back to the 'release' to test some other things to see if it worked or not.... Now everything I mentioned seems to be working, but when i changed folders to my ruby workspace, If I do anything (enable or disable) to the extension the coloring goes away until a reload.

So i guess on the 2nd round, the release binary seems to be working much more as expected, though needs a couple reloads to get it right.. I'll mess with it more through the week as well as getting a RHEL 8 VM going to test it there.

workspaces are still wonky and don't work right, i just get a blank screen when I try to use them and i have to reload / use incognito

messing with python some more, it seems i get the bug where the extension keeps sticking to be 'disabled' and i can't enable it.

Although this only happens on one of my folders and not the other... I think it has something to do with the 'enable workspace' button I've been using (I've only been using it on folders and not workspaces)

@krazyito65

@krazyito65 do you mind sharing the centos Dockerfile you're using?

@krazyito65

@krazyito65 do you mind sharing the centos Dockerfile you're using?

I just used docker run -t -p 127.0.0.1:8443:8443 -v "${PWD}:/root/project" codercom/code-server --allow-http --no-auth (which is on the main README)

but for me, it ran everything as root, so i didn't have my usual setup

I just used docker run -t -p 127.0.0.1:8443:8443 -v "${PWD}:/root/project" codercom/code-server --allow-http --no-auth (which is on the main README)

I think I misunderstood what you originally meant by running it on centos then. I tried two approaches and failed at both.

Build code-server inside a CentOS docker image with the following Dockerfile (just replace the current Dockerfile in the code-server repo). This fails to completely build the extensions.

FROM centos:7
# install Node v8 and build tools
RUN curl --silent --location https://rpm.nodesource.com/setup_8.x | bash - && \
    yum install -y epel-release && yum update -y && \
    yum groupinstall -y "Development Tools" && \
    yum install -y nodejs-8* git python python-pip python-devel libxkbfile-devel libsecret-devel && \
    yum clean all && \
    npm install -g yarn

WORKDIR /src
COPY . .

# In the future, we can use https://github.com/yarnpkg/rfcs/pull/53 to make yarn use the node_modules
# directly which should be fast as it is slow because it populates its own cache every time.
RUN yarn && yarn task build:server:binary

# deploy with centos so that devs have a familiar environment.
FROM centos:7
WORKDIR /root/project
COPY --from=0 /src/packages/server/cli-linux-x64 /usr/local/bin/code-server
EXPOSE 8443
RUN yum groupinstall -y "Development Tools"

# We unfortunately cannot use update-locale because docker will not use the env variables
# configured in /etc/default/locale so we need to set it manually.
ENV LANG=en_US.UTF-8
ENTRYPOINT ["code-server"]

Copy the latest linux release of code-server into a CentOS docker image. This fails because the the page does not load when visiting localhost and the right port. I have not figured out why yet. I think there is an issue with how the release was built.

FROM centos:7
RUN yum install -y epel-release centos-release-scl && yum update -y && \
    yum groupinstall -y "Development Tools" && \
    yum install -y git python python-pip openssl && \
    yum clean all

# deploy with centos so that devs have a familiar environment.
COPY ./code-server-1.32.0-245-linux-x64.tar.gz /
RUN tar -zxf /code-server-1.32.0-245-linux-x64.tar.gz && \
    mv /code-server-1.32.0-245-linux-x64/code-server /usr/local/bin/ && \
    rm -rf /code-server-1.32.0-245-linux-x64 code-server-1.32.0-245-linux-x64.tar.gz

EXPOSE 8443

# We unfortunately cannot use update-locale because docker will not use the env variables
# configured in /etc/default/locale so we need to set it manually.
ENV LANG=en_US.UTF-8
ENTRYPOINT ["code-server"]

I'm directly running the executable on a CentOS Machine (built using yarn from master as well as the release page) not using docker.

When I used docker, I simply used what was on the main page (which I assume builds an Ubuntu image, but i haven't really looked too deep into that)

Question. Does the new vscode extension remote ssh just use this in the background? (https://github.com/Microsoft/vscode-remote-release)
If that's true it works perfectly for me on centos.

If that uses a different code base, then I'm using that instead.

We don't really know how VSCode's new remote features work since it's not open source. However, it's safe to say that it doesn't just run code-server on the remote machine.

Yea, I noticed sshcode and thought it was the same, before I read the updated README. But in general, the new vscode extension does everything I needed.

We already compile in CentOS7 so this is a fix IMO. Let me know if it still doesn't work.

I just tested the latest versions; code-server2.preview.11-vsc1.37.0-linux-x86_64.tar.gz and code-server1.1156-vsc1.33.1-linux-x64.tar.gz, none of them still works, still throws:

./code-server: /lib64/libstdc++.so.6: version GLIBCXX_3.4.20' not found (required by ./code-server)
./code-server: /lib64/libstdc++.so.6: version GLIBCXX_3.4.21' not found (required by ./code-server)
./code-server: /lib64/libstdc++.so.6: version CXXABI_1.3.9' not found (required by ./code-server)

this on centos 7.6.1810

Escalating this right now, I might find a fix for it.

What a coincidence, I was trying out code-server on CentOS 7 and ran into the exact same error!

code-server runs on my CentOS, it's the OS providing very outdated gcc libraries.
All you need is compile them from source.
See #766

@elgandoz

@elgandoz we do compile by CentOS though, the problem is we kept updating gcc (bad idea, I know) so this thing happens.

so just to be clear; the solution provided is to first get the GCC libraries and compile them from source? and then get the code server and compile from source?

We're gonna fix the docker build way in the CI and see if that still persist. I have a repo that makes daily builds so you can test out if that works.

so just to be clear; the solution provided is to first get the GCC libraries and compile them from source? and then get the code server and compile from source?

Yes but you'll need VSCode's build deps installed as well as per v2 documentation.

Based on my investigation the centos:7 image can't go lower with the Glibc versions so this is what you can do for CentOS users:

upgrade your Glibc if possible to be in line with DockerHub's
use Docker

So please make sure your hosts have GLIBCXX 3.4.15 or higher and GLIBC 2.15 or higher. Closing this off as environment dependent and upstream dependent. Please update your CentOS hosts to be in this requirements.

Navigation Menu

Repository navigation

[Feature] Better CentOS support #209

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Feature] Better CentOS support #209

Description

Activity

kylecarbs commented on Mar 12, 2019

kylecarbs commented on Mar 12, 2019

sr229 commented on Mar 13, 2019

krazyito65 commented on Mar 13, 2019

krazyito65 commented on Mar 13, 2019

krazyito65 commented on Mar 13, 2019

jgbradley1 commented on Mar 13, 2019

krazyito65 commented on Mar 14, 2019

jgbradley1 commented on Mar 14, 2019

krazyito65 commented on Mar 15, 2019

krazyito65 commented on Jun 12, 2019

deansheather commented on Jun 12, 2019

krazyito65 commented on Jun 12, 2019

sr229 commented on Sep 12, 2019

polographer commented on Sep 12, 2019

sr229 commented on Sep 12, 2019

MrMoronIV commented on Sep 12, 2019

elgandoz commented on Sep 12, 2019

sr229 commented on Sep 12, 2019

polographer commented on Sep 12, 2019

sr229 commented on Sep 12, 2019

sr229 commented on Sep 14, 2019

sr229 commented on Sep 18, 2019

sr229 commented on Sep 18, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions