I want to help develop a personal web server project and I'm running into an issue with the project lead.
I thought I finally figured out the problem of the project needing root privileges by adding 'gksu' to every shell command I encountered.
However, the project lead has explained to me that the personal web server project needs heaps more root privileges than just the couple I altered, so that it's best I simply run the project(s) as root.
But I have read time and time again here that running eclipse in root is ill advised.
I've tried running the PyDev project as an external tool, putting gksu in front of the python command, but it immediately stops at the first import that references to one of the sub projects.
So my question is what my best option is.
Starting eclipse in root? I've had problems with that. It's been a while, but I think the problem was something like if you would add files it would be owned by root and thus inaccessible or unuploadable to the repo or something, though if this really is the only option, I'm willing to try again and will come back with the real issue again.
I think one option would be just making the interpreter run as root, while not actually running Eclipse as root.
The trick here is that the Python interpreter can be any shell script, not only the actual Python executable, so, you can create a bash script as:
#!/bin/bash
source $HOME/.config_pydev.bash
python "$#"
and specify that bash script as the Python interpreter (and create a $HOME/.config_pydev.bash to make whatever you need to be able to run your service, such as becoming root).
Note that this requires you to become root without any prompt at .config_pydev.bash -- or you can put gksu before the python "$#" call.
As for running eclipse as root, it should also be possible, but then, you have to do everything as root (including setting your git user credentials in the root account -- and I'd suggest re-cloning all the repositories under that account too, the problems arise when you mix things with your account and the root account).
Still, as noted, being root all the time isn't really advised, but sometimes, practicality beats purity (I'd say that running a webserver as root is much more dangerous than running Eclipse as root, so, I think in your use case, you already have something worse anyways).
Related
This is my first stack overflow question. Normally I don't have to ask because it's already been addressed elsewhere, but I've been trying to figure this out for nearly a week and can't do it.
I have maven.
Since the guide on the mahout website basically say "Installing mahout: step 1 - you should install mahout", I had to look elsewhere for a guide. I followed the guide here because it seemed simple enough and made sense:
http:// harish11g.blogspot.co.uk/2012/02/configuring-mahout-clustering-hadoop.html
However, if I don't run
svn co http://svn.apache.org/repos/asf/mahout/trunk as sudo, it won't work.
Similarly, if I don't use sudo for
mvn install
It won't work, failing at the mahout-core stage of the build.
Using sudo, the build succeeds, but because my useraccount did not do the build (root did it) when I import the project to eclipse there are errors. Here is a screenshot:
http://i.imgur.com/MEp3lA0.png
Can I proceed with using mahout despite these errors, or how can I fix them? If I have done something wrong and should reinstall mahout in a different way, I'm happy to but I need to know exactly what I've done wrong.
I tried using maven to install mahout in my home directory and it didn't work there either. My thinking was that I wouldn't need superuser permissions to use the directory, so I didn't use sudo. I also tried changing the permissions of /opt to allow my useraccount to make changes. It still failed, and I've had to use sudo again and the eclipse errors are still showing.
I don't understand why in every guide I've seen online this hasn't been a problem. What could be so different about my user account that means I can't simply use
mvn install
to get mahout downloaded and installed?
If anyone could explain this is in a simple step-by-step way that would be amazing, because I really don't know why I'm having such trouble with this. Also, I've only been using Ubuntu in earnest for the past few weeks (although I had some experience with it over the past year, never really used it for anything serious) for this project, so you'll understand if I'm not immediately aware of some terminal commands or other linux tricks that to others may seem obvious.
Thanks for reading.
Do a ls -l on that directory in the terminal. Does the listed username match the one you are logged in (and running eclipse), or even the username in the terminal prompt?
This is bad: I am logged in as jj and I am trying to edit files owned by hduser:
jj#jj-ThinkPad-T420 ~/dev/crap $ ls -l
total 0
-rw-rw-r-- 1 hduser audio 0 Jun 16 23:37 afile
So we change the ownership of directory to jj:
jj#jj-ThinkPad-T420 ~/dev $ sudo chown -R jj:jj crap
All-clear to compile into this directory:
jj#jj-ThinkPad-T420 ~/dev/crap $ ls -l
total 0
-rw-rw-r-- 1 jj jj 0 Jun 16 23:37 afile
Image depicts Eclipse unable to write compiled classes to a directory owned by somebody else; while Eclipse (and rest of desktop) is owned by you. Root user can do anything on any directory, hence sudo works.
I recently started a new job, where all development is done on a remote dev server. I really like Eclipse as a centralized development environment for all the different stuff I'm working on, and am not a particularly big fan of emacs or vi. I'll use emacs if I have to change something quickly, but after really trying to like it for normal development, I'm really starting to miss Eclipse.
That said, is there any way I can use Eclipse with EPIC for Perl development on a remote server? I can live without debugging functionality, but proper syntax highlighting, and the ability to create projects would be really, really nice. So far, I've tried using a remote browser plugin for Eclipse to peruse the remote dev server and open stuff into Eclipse that way, but it is far from ideal. Anyone have any better ideas?
Answering my own question (which no one seems to have looked at or care about, but what the hell-- maybe someone will have the same issue):
Grab Remote Systems Explorer from here.
Setup RSE to ssh into your remote server.
Create a new empty EPIC project (or using whatever plugin/ language you want).
Right click the project, select "New Folder," then
Advanced >> Link to alternate location (Linked Folder)
Switch file system to RSE, then just browse to some folder on your remote system you'd like to become a project, and add it.
That's it, you're done. Now when you open your project in Eclipse, you'll see that folder with all the code you wanted, and you can use it just like you would locally.
The main problem I'm seeing with this right now is that currently I can't get it to do any error checking, which is too bad. I'll work on finding a work around for that and update here if I do.
If you're on linux, you can also mount the remote drive/folder with sshfs and use the same "linked folder technique". I do this all the time for Java EE development. sshfs is also very reliable, unlike Windows network shares mounted on linux with Samba-Client. (Sometimes the Windows sharing service gets confused. And needs to be restarted on the remote server. I use a powershell one liner for this "restart-service -name 'sharing service' " or something like´that.)
I have downloaded a project which uses sbt as its build system and I want to build it. You'd think it would be as simple as typing "sbt" or something, but no.
I thought I'd add a question for this because it can take literally hours to figure this out on your own. I'm not joking.
tl;dr:
sbt compile
If you want to run it:
sbt run
To see what other targets are available:
sbt tasks
To get some (other) help, but mostly targeted at commands typed from the sbt console (ie, running sbt without parameters):
sbt help
This all assumes sbt version >= 0.10.0. To see what version of sbt is in use, do:
grep sbt.version project/build.properties
If there's no such file, and there's a file with extension ".sbt" on the base directory (not the project directory), then it's >= 0.10.0. Of course, if the grep works, it should tell you the version.
First, you'll want to use sbt-extras, because that automatically downloads and uses the right version of sbt. Trying to use the wrong version of sbt (newer or older than what the project you're trying to build says it requires) won't necessarily work, and may cause strange errors.
Run it:
~/path/to/sbt-extras/sbt
Wait for it to start up and download everything. If you need to use an authenticated proxy, you'll need to edit the script to specify the username and password for the proxy.
Check the version of Scala that sbt thinks it needs to build against (at the end of the output, if everything worked). If this is OK, fine, you don't need to do anything. If it isn't, you can temporarily specify a version explicitly with ++, e.g.:
++2.8.1
(If you want to make this permanent, you can edit the build definition files, but as that involves making a change to files under version control, that might not be what you want to do.)
Now, if you are using an older version of sbt, don't skip the next step! You could get strange errors if you do.
update
Now you can build and test what you've built:
test
If you get an error "Filename too long", this is not an sbt-specific problem, it's a scala problem, which most frequently affects Ubuntu users (technically, for Unbuntu users it's generally related to home directories encrypted with encfs). If you are using Scala >= 2.9, edit the build to use the scalac command-line option that allows you to specify a maximum filename length. Otherwise, if you are on Linux, you can redirect the build to /dev/shm or /tmp, by running these commands in a shell prompt (don't background sbt with CTRL+Z on Unix, because it may appear to stop working properly):
rm -rf target
ln -s /dev/shm target
(you may have to execute these commands in project/build instead or as well.)
Actually, it's probably better, and may even be more secure, to create a subdirectory of /dev/shm or /tmp and use that instead.
The compilation result should appear in target. You might then want to run it, if it's something you can run:
run
If everything looks OK, you can optionally publish the result locally so that the result can then be picked up automatically by other sbt builds:
publish-local
I don't think I could explain it better that the Getting Started Guide could. Please read the first 6 parts of it, which shouldn't too long time, to get it up and running.
Ok, so if I create a brand new virtualenv, then hop into that environment, go into a python shell within that environment, and run 'import logging', for instance, it imports absolutely fine. I can then start up eclipse, create a new interpreter based on the /bin/python in my virtualenv and if I open up a python console within eclipse, based on this new interpreter, I can run 'import logging' again without any problems. I can create a project, with this new interpreter and create a sample file with nothing but
import logging
print asdf
I'll get an 'unresolved import' error with the line 'import logging'. This can be resolved by adding in the system lib/pythonX.X directory (in my case /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6) to the interpreter configuration, but I'd be under the impression that this is counter-intuitive for what you'd want to be doing with eclipse and virtualenv.
I know the stuff that's in that lib/pythonX.X directory are pretty much nothing but the base classes, but if they should always be included, should they not just be included anyway? Is this not against the way virtualenv setting up links to these very classes within it's own lib/pythonX.X directory? Is adding the base python lib/pythonX.X directory to the eclipse interpreter the correct way to do this, or is there problems with doing this?
Am I getting confused by the whole setup, or is it actually confusing and I'm right to ask the question? Thanks for anyone who can help.
I think it's just confusing... You really have to add the paths of the base interpreter when configuring the virtualenv interpreter in PyDev (i.e.: in the command line, when you start that interpreter and do an import sys;print(sys.path), the folders of the base interpreter will probably be there, so, they also need to be in PyDev).
I am using ubuntu 8.04 and windows xp. I mount the fat32 disk which contains eclipse workspace to ubuntu. but I find I could not use the workspace, maybe I have no right to use it.
the fat32 disk I mounted has the 755 right,I try to use chmod to change it to 777 but failed. I try to mount it to 777 mode, but I find there is nothing about mode in vfat option.
How should I do next ? how could I share the workspace? Help me. thanks.
Instead of trying to share the raw workspace data between two different systems, I suggest to do it like in typical big software development projects. Use a version control system to store your code and commit/update to and from that version control system instead of sharing files.
This may not be the answer you were originally interested in, but rest assured, you will notice many advantages of that version control system after some time, including:
Easily get back to the code version before todays "genius" changes which didn't really work at the end
There is a backup of your project in case your workstation dies
You may even access your project from a completely different machine/location.
If your project is going to be open source, you can even use public services like Sourceforge.net.
I believe that the fat32 doesn't support the same kind of permissions as the linux ones you are familiar with. Once you have sorted out the rw option in /etc/mtab then I think you will have a better time.
However, the step after that is to have two different installations of Eclipse working on the same workspace.
I haven't had a lot of success with this (though haven't tried you're exact scenario), but I would be careful to:
keep the Eclipse versions in synch
only use relative paths, and relative to the workspace. This is probably good practice any way, but is worth repeating.
If all goes well, then you should be sharing everything, including preferences across both installations.
There are two refinements I can think of, which may be useful to reason about, if not actually do:
you could probably share most of the installation of eclipse (the plugins and features directory, if not the config.ini and eclipse.ini files). If you can't put both executables in the same directory, consider the -install and -configuration runtime options.
if you can't do any of these things, then you may need to work on two parallel workspaces. You can keep them in synch with tools such as rsync or even a distributed source control like Mercurial.
I agree with bananeweizen.myopenid, and have the following tip to add:
When creating your build path entries, reference all outside resources (eg, jarfiles) using classpath variables. This will allow you to move the .classpath file between environments (or even check it into source control, if you're the sole developer) without running into problems with pathnames.
To reference a JARFile via variable, go into the "Libraries" tab of the Build Path, remove any existing reference to the library, and click "Add Variable...". You will need to define common variables, such as M2_REPO or LOCAL_LIBS, and you will need to make sure that those definitions are available in all your environments.
Perhaps the problem you're having is with capitalization. Be sure to create the workspace in Ubuntu first. This should rule out any filename capitalization issues.