- 论坛徽章:
- 3
|
Linux操作系统下三种配置环境变量的方法
在linux下做开发首先就是需要配置环境变量,下面以配置java环境变量为例介绍三种配置环境变量的方法。
1.修改/etc/profile文件
如果你的计算机仅仅作为开发使用时推荐使用这种方法,因为所有用户的shell都有权使用这些环境变量,可能会给系统带来安全性问题。
(1)用文本编辑器打开/etc/profile
(2)在profile文件末尾加入:
JAVA_HOME=/usr/share/jdk1.5.0_05
PATH=$JAVA_HOME/bin PATH
CLASSPATH=. JAVA_HOME/lib/dt.jar JAVA_HOME/lib/tools.jar
export JAVA_HOME
export PATH
export CLASSPATH
(3)重新登录
注解:
a. 你要将 /usr/share/jdk1.5.0_05jdk 改为你的jdk安装目录
b. linux下用冒号“:”来分隔路径
c. $PATH / $CLASSPATH / $JAVA_HOME 是用来引用原来的环境变量的值,在设置环境变量时特别要注意不能把原来的值给覆盖掉了,这是一种常见的错误。
d. CLASSPATH中当前目录“.”不能丢,把当前目录丢掉也是常见的错误。
e. export是把这三个变量导出为全局变量。
f. 大小写必须严格区分。
2. 修改.bashrc文件
这种方法更为安全,它可以把使用这些环境变量的权限控制到用户级别,如果你需要给某个用户权限使用这些环境变量,你只需要修改其个人用户主目录下的.bashrc文件就可以了。
(1)用文本编辑器打开用户目录下的.bashrc文件
(2)在.bashrc文件末尾加入:
set JAVA_HOME=/usr/share/jdk1.5.0_05
export JAVA_HOME
set PATH=$JAVA_HOME/bin PATH
export PATH
set CLASSPATH=. JAVA_HOME/lib/dt.jar JAVA_HOME/lib/tools.jar
export CLASSPATH
(3)重新登录
3. 直接在shell下设置变量
不赞成使用这种方法,因为换个shell,你的设置就无效了,因此这种方法仅仅是临时使用,以后要使用的时候又要重新设置,比较麻烦。
只需在shell终端执行下列命令:
export JAVA_HOME=/usr/share/jdk1.5.0_05
export PATH=$JAVA_HOME/bin PATH
export CLASSPATH=. JAVA_HOME/lib/dt.jar JAVA_HOME/lib/tools.jar
git 通过ssh 进行认证连接
首先安装git
emerge -av git 一条命令搞定,如果你使用ubuntu redhat 有相应的yum apt-get 工具,
git麻烦在用户管理及管理上,下面上三种解决办法:
# 如果需要团队里的每个人都对仓库有写权限,又不能给每个人在服务器上建立账户,那么提供 SSH 连接就是唯一的选择了。我们假设用来共享仓库的服务器已经安装了 SSH 服务,而且你通过它访问服务器。
#
# 有好几个办法可以让团队的每个人都有访问权。
第一个办法 是给每个人建立一个账户,直截了当但过于繁琐。反复的运行 adduser 并且给所有人设定临时密码可不是好玩的。
#
# 第二个办法 是在主机上建立一个 git 账户,让每个需要写权限的人发送一个 SSH 公钥,然后将其加入 git 账户的 ~/.ssh /authorized_keys 文件。这样一来,所有人都将通过 git 账户访问主机。这丝毫不会影响提交的数据——访问主机用的身份不会影响 commit的记录。
#
# 另一个办法 是让 SSH 服务器通过某个 LDAP 服务,或者其他已经设定好的集中授权机制,来进行授权。只要每个人都能获得主机的 shell 访问权,任何可用的 SSH 授权机制都能达到相同效 # 如果需要团队里的每个人都对仓库有写权限,又不能给每个人在服务器上建立账户,那么提供 SSH 连接就是唯一的选择了。我们假设用来共享仓库的服务器已经安装了 SSH 服务,而且你通过它访问服务器。
#
为了简便选用了第二种办法 ,这种办法采用SSH公钥认证。
这里为了演示建立user1 user2 两个用户分别模拟两个开发人员,
建立git 用户,源码是通过git 用户进行初始化,可以将 它当作项目经理
并各自修改密码
产生公钥
ssh-keygen -C "你的email地址" -t rsa
后面直接回车直到结束,中间可以不需要任何设置,该命令将生成一对非对称的公/私密钥,默认它们被存储在:
XP/2003用户:c:/Documents and Settings/登陆名/.ssh
Vista用户: c:/Users/登陆名/.ssh
linux :~/.ssh
下面分别为user1 user2 产生公钥,私钥
这样有/home/user1/.ssh 下会产生两个文件,id_rsa 私钥,和id_rsa.pub公钥文件
公钥样子大概如此
该.ssh文件夹下面,私钥放在id_rsa文件里面,不用理会它;
对于user2 ,git 用户作相同处理,然后各自的目录会生成相应的文件
然后需要将user1 user2 各自的公钥文件提供给git 用户,
2、在linux服务器上将公钥加到git用户的authorized_keys文件中。
可以参考:http://github.com/git-on-windows/rookies
git用户的建立及设置参考:http://progit.org/book/zh/ch4-4.html
只要把它们加入 authorized_keys 文件(译注:本例加入到了文件尾部):
这样认证就建好了
然后用git 用户在/home/git目录下建一个库 project_repos.git/
然后启运服务 /etc/init.d/git-daemon restart
当然也要启动sshd
/etc/init.d/sshd start
user1 连接 (这里测试时将porject_repos.git 改为repos.git 了, 此系小节,可忽略)
.git包含的目录含义
UPDATE: I’ve recieved some very helpful comments regarding corrections to the various files and what they do. Thanks for letting me know and keeping me on my toes.
One of the things I like best about Git is that it keeps all of its information in one place: your .git directory in your project’s root. If you haven’t been digging around it yet, don’t fret! There’s plenty of goodies to be had within it. Let’s take a look into the important files and folders and try to get a better sense of what’s going on under the hood.
The basic structure looks like this:
.|-- COMMIT_EDITMSG|-- FETCH_HEAD|-- HEAD|-- ORIG_HEAD|-- branches|-- config|-- description|-- hooks| |-- applypatch-msg| |-- commit-msg| |-- post-commit| |-- post-receive| |-- post-update| |-- pre-applypatch| |-- pre-commit| |-- pre-rebase| |-- prepare-commit-msg| `-- update|-- index|-- info| `-- exclude|-- logs| |-- HEAD| `-- refs|-- objects`-- refs |-- heads |-- remotes |-- stash `-- tagsLet’s go over some of the normal files that you may see living in the base directory:
•COMMIT_EDITMSG: This is the last commit’s message. It’s not actually used by Git at all, but it’s there mostly for your reference after you made a commit.
•config: Contains settings for this repository. Specific configuration variables can be dumped in here (and even aliases!) What this file is most used for is defining where remotes live and some core settings, such as if your repository is bare or not.
•description: If you’re using gitweb or firing up git instaweb, this will show up when you view your repository or the list of all versioned repositories.
•FETCH_HEAD: The SHAs of branch/remote heads that were updated during the last git fetch
•HEAD: The current ref that you’re looking at. In most cases it’s probably refs/heads/master
•index: The staging area with meta-data such as timestamps, file names and also SHAs of the files that are already wrapped up by Git.
•packed-refs: Packs away dormant refs, this is not the definitive list of refs in your repository (the refs folder has the real ones!) Take a look at gitster’s comment to see more information on this.
•ORIG_HEAD: When doing a merge, this is the SHA of the branch you’re merging into.
•MERGE_HEAD: When doing a merge, this is the SHA of the branch you’re merging from.
•MERGE_MODE: Used to communicate constraints that were originally given to git merge to git commit when a merge conflicts, and a separate git commit is needed to conclude it. Currently --no-ff is the only constraints passed this way.
•MERGE_MSG: Enumerates conflicts that happen during your current merge.
•RENAMED-REF: Still trying to track this one down. From a basic grep through the source, it seems like this file is related to errors when saving refs.
There’s plenty of directories as well:
•hooks: A directory that will fast become your best friend: this contains scripts that are executed at certain times when working with Git, such as after a commit or before a rebase. An entire series of articles will be coming about hooks.
•info: Relatively uninteresting except for the exclude file that lives inside of it. We’ve seen this before in the ignoring files article, but as a reminder, you can use this file to ignore files for this project, but beware! It’s not versioned like a .gitignore file would be.
•logs: Contains history for different branches. Seems to be used mostly with the reflog command.
•objects: Git’s internal warehouse of blobs, all indexed by SHAs.
•rebase-apply: The workbench for rebasing and for git am. You can dig into its patch file when it does not apply cleanly if you’re brave.
•refs: The master copy of all refs that live in your repository, be they for stashes, tags, remote tracking branches, or local branches.
Just one word of wisdom when messing around with Git internals: make sure you know what you’re doing, and if not, have a backup! Messing around with the config files or hooks is pretty simple but I wouldn’t go spelunking in the datastore if I didn’t have to. If for some reason you are as part of your normal workflow, you might be doing it wrong.
There’s plenty more about the internals of Git that we haven’t covered yet. One of the best guides is the Git Community Book, and of course, you can just download the source for yourself and take a look. If you have more information about what’s going on in the .git folder, let us know in the comments!
|
|