|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
|
|
Yum's repositories a standard way of working with performing updates and install of new packages in RPM-based Linux distributions. Red Hat, CentOs, Academic Linux, Fedora and OpenSuse supports Yum repositories.
|
|
Yum consists of two tools; yum-arch, which is used to construct an (ftp or http) repository on a suitable server, and yum, the general-purpose client. Once a yum repository is prepared any client permitted to access the repository can install, update, or remove one or more rpm-based packages from the repository.
For a particular commercial distribution registration is needed to get access to repositories. Only such distributions as CentOS, Academic Linux, Fedora and OpenSuse provide free access to yum repositories. For example for CentOS:
CentOS has quite a large number of official repositories. This is to ensure that administrators can maintain their servers in a known state. By using the default repositories, only packages that are updated upstream are made available. This ensures binary compatibility with Red Hat Enterprise Linux.
For some people, this may be very important, especially if they are running software that is certified for Red Hat Enterprise Linux. But what if you just want the CentOS core but want to be able to use software that isn't available upstream? What if you want to try a newer version of a piece of software? Chances are you will find what you're looking for in one of the CentOS repositories, but if not, you can always add a third-party repository.
Official CentOS Repositories
The following are the official CentOS repositories.
[base]
This repository contains the RPM packages as they are supplied on the related ISO images. This repository is enabled by default, although the contents of this repository don't update after a given release.
[updates]
This repository, which is also enabled by default, is where all the security, bug fix, and enhancement updates for the [base] repositories are placed. All of the other repositories contain their own updates.
[addons]
This repository (enabled by default) does not contain packages that are released upstream. Instead, it contains additional packages that are needed to build software from the source RPMs (SRPMs). Using this repository doesn't cause CentOS to lose binary compatibility with upstream versions and should remain enabled.
[contrib]
This repository is not enabled by default and contains additional software packages that have been contributed by the CentOS community. The important distinction with this repository is that none of the software will conflict with software in the base distribution. This means that it is generally safe to use these packages and that they won't break binary compatibility with upstream versions. However, they are not tested by the CentOS developers and may not necessarily follow upstream versions of the software all that closely.
[centosplus]
This repository is similar to the [contrib] repository in that it contains contributed software. Like [contrib], these packages are contributed by CentOS users, but packages are also supplied by CentOS developers. The major difference, though, is that the software that this repository provides may very well replace or upgrade packages that are included in the base distribution. This means that use of this repository could break binary compatibility with upstream versions.
Before using this repository, you should be fully aware of what this means to you. If you have no interest in maintaining compatibility with upstream versions or your project desperately needs the software included in [centosplus], then by all means feel free to use it. If you are more conservative and would rather keep your system as close to upstream versions as possible, you'd be better off not enabling this repository.
[extras]
This repository is enabled by default and contains packages that add functionality to the distribution. It's written by the CentOS developers and has undergone reasonable testing. Software versions should track upstream versions fairly closely, and these packages will never conflict or interfere with [base] packages.
[testing]
The testing repository contains packages that are currently being tested and debugged. Unless you have a specific reason for doing so, this repository should not be enabled on a production server.
Third-Party Repositories
Now that you've seen the official repository list, you should also be aware that there are many third-party repositories that you can use. These are not approved by the CentOS Project but often contain many useful packages. For more information on third-party repositories and how to use them, check out the CentOS wiki at http://wiki.centos.org/AdditionalResources/Repositories.
If there is a proxy between client and server you need to configure client configuration file so that it knows about the proxy, in /etc/yum.conf file You do not need quotes around the URL.
proxy=http://192.168.3.1:8080/
In case proxy requires authentication you need to provide those details too:
# The account details for yum connections
proxy_username=yum-user
proxy_password=qwerty
YUM also understands standard environment variable http_proxy.
In this case you need to provide those
variable either in /etc/profile or in particular user .bash_profile. The settings below
enable yum to use the proxy server mycache.mydomain.com, connecting to port
8080.
# The Web proxy server used by this account
http_proxy="http://mycache.mydomain.com:8081"
export http_proxyhttp_proxy="http://yum-user:[email protected]:8080"
The alternative way to provide access to YUM repositories on a local network is to use NFS. You can export (rw,no_root_squash) /var/cache/yum to all the LAN clients. This will speed up operations with the remote repositories as NFS is faster then HTTP protocol. Best of all, there is no setup.
In a typical repository, there are several thousand packages, with a lot of headers. About 700 packages are actually installed on a typical linux system. However, the archive component of each package, which contains the actual binaries and libraries and documentation installed, is much larger -- the complete rpm is thus generally two to four orders of magnitude larger than the header. For example, the header for Open Office (a fairly large package) total about 100 kilobytes in size. The rpm itself, on the other hand, is about 30 megabytes in size. The header can be reliably delivered in a tiny fraction of a second over most networks; the rpm itself requires seconds to be delivered over 100Mbit/sec LAN. Early automated update tools either required a locally mounted repository directory in order to be able to access all of the headers quickly (local disk access even from a relatively slow CD-ROM drive, being fast enough to deliver the rpm's in a timely way so that their headers could be extracted and parsed) or required that each linked rpm be sent in its entirety over a network to an updating client from the repository just so it could read the header. One was locally fast but required a large commitment of local disk resources (in addition to creating a new problem, that of keeping all the local copies of a master repository synchronized). The other was very slow. Both were also network resource intensive.
This is the fundamental problem that yum solves for you. Yum splits off the headers on the repository side (which is the job of its only repository-side tool, yum-arch). The headers themselves are thus available to be downloaded separately, and quickly, to the yum client, where they are typically cached semi-permanently in a small footprint in /var/cache/yum/serverid (recall that serverid is a label for a single repository that might be mirrored on several servers and available on a fallback basis from several URL's). Yum clients also cache (space permitting or according to the requirements and invocation schema selected by the system's administrator) rpm's when they are downloaded for an actual install or update, giving a yum client the best of both the options above -- a local disk image of (just the relevant part of) the repository that is automatically and transparently managed and rapid access to just the headers.
An actual download of all the headers associated with packages found on your system occurs the first time a yum client is invoked and thereafter it adds to or updates the cached headers (and downloads and caches the required rpm's) only if the repository has more recent versions or if the user has deliberately invoke yum's "clean" command to empty all its caches. All of yum's dependency resolution then proceeds from these cached header files, and if for any reason the install or update requires an rpm already in the cache to be reinstalled, it is immediately available.
However, it is probably better in many cases to use rsync or other tools to provide a local mirror of the repository in question and use yum's fallback capability to accomplish the same thing. This gives one a much better capability of standing alone should update access go away on the "server" of the yum cache NFS exported across a LAN.
With the header information (only) handy on high-speed local media, the standard tools used to maintain rpm's are invoked by yum and can quickly proceed to resolve all dependencies, determine if it is safe to proceed, what additional packages need to be installed, and so forth. Note well that yum is designed (by a highly experienced systems administrator, Seth Vidal, with the help of all the other highly experienced systems administrators on the yum list) to be safe. It will generally not proceed if it encounters a dependency loop, a package conflict, or a revision number conflict.
If yum finds that everything is good and the package can be safely installed, removed, or updated, it can either be invoked in such a way that it does so automatically with no further prompts so it can run automagically from cron, or (the general default when invoked from a command line) it can issue a user a single prompt indicating what it is about to do and requesting permission to proceed. If it finds that the requested action is in fact not safe, it will exit with as informative an error message as it can generate, permitting the system's administrator to attempt to resolve the situation by hand before proceeding (which may, for example, involve removing certain conflicting packages from the client system or fixing the repository itself).
From the overview given above, it should be apparent that yum is potentially a powerful tool indeed, using a single clever idea (the splitting off of the rpm headers) to achieve a singular degree of efficiency. One can immediately imagine all sorts of ways to exploit the information now so readily available to a client and wrap them all up in a single interface to eliminate the incredibly arcane and complex commands otherwise required to learn anything about the installed package base on a system and what is still available. The yum developers have been doing just that on the yum list - dreaming up features and literally overnight implementing the most attractive ones in new code. At this point yum is very nearly the last thing you'll ever need to manage packages on any rpm based system once it has gotten past its original, distribution vendor based, install.
rpm doesn't permit one to tell it to "install package X and anything else that it needs, after YOU figure out what that might be". Yum, of course, does.
Even yum, though, can't "fix" a dependency loop, or cope with all the arcane revision numbering schemes or dependency specifications that appear in all the rpm's one might find and rebuild or develop locally for inclusion in a central repository. When one is encountered, a Real Human has to apply a considerable amount of systems expertise to resolve the problem. This suggests that building rpm's from sources in such a way that they "play nice" in a distribution repository, while a critical component of said repository, is not a trivial process. So much so that many rpm developers simply do not succeed.
Also, yum achieves its greatest degree of scalability and efficiency if only rpm-based installation is permitted on all the systems using yum to keep up to date.
Consequently, repository maintainers must willy-nilly become rpm builders to at least some extent. If SuSE releases a lovely new tool in source rpm form that isn't in your current Red Hat based repository, of course you would like to rebuild it and add it. If your University has a site license for e.g. Mathematica and you would like to install it via the (properly secured and license controlling) repository you will need to turn it into an rpm. If nothing else, you'll need to repackage yum itself for client installations so that its configuration files point to your repositories and not the default repositories provided in the installation rpm's /etc/yum.conf.
There are three steps to creating a yum repository:
If you have a special repository which you really like, but which does not support yum, you can use a trick: make a local mirror of the files via rsync or similar utility and then create a local YUM repository. To convert directory with RPMs into YUM repository you need to run a special utility createrepo
yum install createrepo
To create a repository you need to run it with a single parameter, the root of RPM directory tree (you can use subdirectories for various groups of RPMs):
createrepo /var/cache/myrepo
After running the utility you can notice that in the directory /var/cache/yum/myrepo there is a new directory called repodata with data describing RPMs in it.
The last step is to create the file with extension repo, for example, my.repo in /etc/yum.repos.d/:
[myrepo]
name=my cool repo
baseur=file:///var/cache/myrepo
enabled=1
At this point you should be able to install RPM from local repository using yum. You can use
wget and cron-jobs for synchronizing of the local repository. After each synchronization you need
to update the repodata directory using createrepo
Once the repository is constructed, it must be made available by http, ftp, or rsync. If the repository is made in the root document tree of your web server, e.g., /var/www/html/, the following entry should be added to /etc/httpd/conf/httpd.conf:
<Directory /var/www/>
Options +Indexes
</Directory>
in order to allow the directories to be listed. Reload the httpd configuration file with
# /sbin/service httpd reload
or
# /sbin/service apache2 reload
depending of the flavour of Linux you are using and the type of Web server you have.
On invocation yum first checks its configuration file /etc/yum.conf which store all information about the repositories in /etc/yum.repos.d/.
The files in this directory should have an extension repo and format like this:
[base]
name=SUSE LINUX 10.0 - Base
baseurl=ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/suse
enabled=1
gpgcheck=1
gpgkey=ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/pubring.gpg
The first option shows the name - this must be unique because yum uses it to identify the repository and the cached data about it.
The second option, the name field, is for the user to know what he has configured.
baseurl gives the server and the directory where yum can find the packages.
You can use mirrorlists instead. The url to the mirrorlist is part of the field mirrorlist - due to the fact the no server provides them, we have to make our own.
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
/n/n/nAug 27, 2014 | www.unixmen.com
/n /n/nThis tutorial describes how to setup a local Yum repository on CentOS 7 system. Also, the/n same steps should work on RHEL and Scientific Linux 7 systems too.
/n/nIf you have to install software, security updates and fixes often in multiple systems in/n your local network, then having a local repository is an efficient way. Because all required/n packages are downloaded over the fast LAN connection from your local server, so that it will/n save your Internet bandwidth and reduces your annual cost of Internet.
/n/nIn this tutorial, I use two systems as described below:
/n/nYum Server OS : CentOS 7 (Minimal Install)/nYum Server IP Address : 192.168.1.101/nClient OS : CentOS 7 (Minimal Install)/nClient IP Address : 192.168.1.102/nPrerequisites/n/nFirst, mount your CentOS 7 installation DVD. For example, let us mount the installation/n media on /mnt directory.
/n/nmount /dev/cdrom /mnt//n/n/nNow the CentOS installation DVD is mounted under /mnt directory. Next install vsftpd package/n and let the packages available over FTP to your local clients.
/n/nTo do that change to /mnt/Packages directory:
/n/ncd /mnt/Packages//n/n/nNow install vsftpd package:
/n/nrpm -ivh vsftpd-3.0.2-9.el7.x86_64.rpm/n/n/nEnable and start vsftpd service:
/n/nsystemctl enable vsftpd/nsystemctl start vsftpd/n/n/nWe need a package called "createrepo" to create our local repository. So let us install it/n too.
/n/nIf you did a minimal CentOS installation, then you might need to install the following/n dependencies first:
/n/nrpm -ivh libxml2-python-2.9.1-5.el7.x86_64.rpm /nrpm -ivh deltarpm-3.6-3.el7.x86_64.rpm /nrpm -ivh python-deltarpm-3.6-3.el7.x86_64.rpm/n/n/nNow install "createrepo" package:
/n/nrpm -ivh createrepo-0.9.9-23.el7.noarch.rpm/nBuild Local Repository/n/nIt's time to build our local repository. Create a storage directory to store all packages/n from CentOS DVD's.
/n/nAs I noted above, we are going to use a FTP server to serve all packages to client systems./n So let us create a storage location in our FTP server pub directory.
/n/nmkdir /var/ftp/pub/localrepo/n/n/nNow, copy all the files from CentOS DVD(s) i.e from /mnt/Packages/ directory to the/n "localrepo" directory:
/n/ncp -ar /mnt/Packages/*.* /var/ftp/pub/localrepo//n/n/nAgain, mount the CentOS installation DVD 2 and copy all the files to /var/ftp/pub/localrepo/n directory.
/n/nOnce you copied all the files, create a repository file called "localrepo.repo" under/n /etc/yum.repos.d/ directory and add the following lines into the file. You can name this file/n as per your liking:
/n/nvi /etc/yum.repos.d/localrepo.repo/n/n/nAdd the following lines:
/n/n[localrepo]/nname=Unixmen Repository/nbaseurl=file:///var/ftp/pub/localrepo/ngpgcheck=0/nenabled=1/n/n/nNote: Use three slashes(///) in the baseurl.
/n/nNow, start building local repository:
/n/ncreaterepo -v /var/ftp/pub/localrepo//n/n/nNow the repository building process will start.
/n/nSample Output:
/n/n/n/n
Now, list out the repositories using the following command:
/n/nyum repolist/n/n/nSample Output:
/n/nrepo id repo name status/nbase/7/x86_64 CentOS-7 - Base 8,465/nextras/7/x86_64 CentOS-7 - Extras 30/nlocalrepo Unixmen Repository 3,538/nupdates/7/x86_64 CentOS-7 - Updates 726/n/n/nClean the Yum cache and update the repository lists:
/n/nyum clean all/nyum update/n/n/nAfter creating the repository, disable or rename the existing repositories if you only want/n to install packages from the local repository itself.
/n/nAlternatively, you can install packages only from the local repository by mentioning the/n repository as shown below.
/n/nyum install --disablerepo="*" --enablerepo="localrepo" httpd/n/n/nSample Output:
/n/nLoaded plugins: fastestmirror/nLoading mirror speeds from cached hostfile/nResolving Dependencies/n--> Running transaction check/n---> Package httpd.x86_64 0:2.4.6-17.el7.centos.1 will be installed/n--> Processing Dependency: httpd-tools = 2.4.6-17.el7.centos.1 for package: httpd-2.4.6-17.el7.centos.1.x86_64/n--> Processing Dependency: /etc/mime.types for package: httpd-2.4.6-17.el7.centos.1.x86_64/n--> Processing Dependency: libaprutil-1.so.0()(64bit) for package: httpd-2.4.6-17.el7.centos.1.x86_64/n--> Processing Dependency: libapr-1.so.0()(64bit) for package: httpd-2.4.6-17.el7.centos.1.x86_64/n--> Running transaction check/n---> Package apr.x86_64 0:1.4.8-3.el7 will be installed/n---> Package apr-util.x86_64 0:1.5.2-6.el7 will be installed/n---> Package httpd-tools.x86_64 0:2.4.6-17.el7.centos.1 will be installed/n---> Package mailcap.noarch 0:2.1.41-2.el7 will be installed/n--> Finished Dependency Resolution/n/nDependencies Resolved/n/n===============================================================================================================================================================/n Package Arch Version Repository Size/n===============================================================================================================================================================/nInstalling:/n httpd x86_64 2.4.6-17.el7.centos.1 localrepo 2.7 M/nInstalling for dependencies:/n apr x86_64 1.4.8-3.el7 localrepo 103 k/n apr-util x86_64 1.5.2-6.el7 localrepo 92 k/n httpd-tools x86_64 2.4.6-17.el7.centos.1 localrepo 77 k/n mailcap noarch 2.1.41-2.el7 localrepo 31 k/n/nTransaction Summary/n===============================================================================================================================================================/nInstall 1 Package (+4 Dependent packages)/n/nTotal download size: 3.0 M/nInstalled size: 10 M/nIs this ok [y/d/N]:/n/n/nDisable Firewall And SELinux:
/n/nAs we are going to use the local repository only in our local area network, there is no need/n for firewall and SELinux. So, to reduce the complexity, I disabled both Firewalld and/n SELInux.
/n/nTo disable the Firewalld, enter the following commands:
/n/nsystemctl stop firewalld/nsystemctl disable firewalld/n/n/nTo disable SELinux, edit file /etc/sysconfig/selinux ,
/n/nvi /etc/sysconfig/selinux/n/n/nSet SELINUX=disabled.
/n/n[...]/nSELINUX=disabled/n[...]/n/n/nReboot your server to take effect the changes.
Client Side Configuration/n/nNow, go to your client systems. Create a new repository file as shown above under/n /etc/yum.repos.d/ directory.
/n/nvi /etc/yum.repos.d/localrepo.repo/n/n/nand add the following contents:
/n/n[localrepo]/nname=Unixmen Repository/nbaseurl=ftp://192.168.1.101/pub/localrepo/ngpgcheck=0/nenabled=1/n/n/nNote: Use double slashes in the baseurl and 192.168.1.101 is yum server IP Address.
/n/nNow, list out the repositories using the following command:
/n/nyum repolist/n/n/nClean the Yum cache and update the repository lists:
/n/nyum clean all/nyum update/n/n/nDisable or rename the existing repositories if you only want to install packages from the/n server local repository itself.
/n/nAlternatively, you can install packages from the local repository by mentioning the/n repository as shown below.
/n/nyum install --disablerepo="*" --enablerepo="localrepo" httpd/n/n/nSample Output:
/n/nLoaded plugins: fastestmirror/nLoading mirror speeds from cached hostfile/nResolving Dependencies/n--> Running transaction check/n---> Package httpd.x86_64 0:2.4.6-17.el7.centos.1 will be installed/n--> Processing Dependency: httpd-tools = 2.4.6-17.el7.centos.1 for package: httpd-2.4.6-17.el7.centos.1.x86_64/n--> Processing Dependency: /etc/mime.types for package: httpd-2.4.6-17.el7.centos.1.x86_64/n--> Processing Dependency: libaprutil-1.so.0()(64bit) for package: httpd-2.4.6-17.el7.centos.1.x86_64/n--> Processing Dependency: libapr-1.so.0()(64bit) for package: httpd-2.4.6-17.el7.centos.1.x86_64/n--> Running transaction check/n---> Package apr.x86_64 0:1.4.8-3.el7 will be installed/n---> Package apr-util.x86_64 0:1.5.2-6.el7 will be installed/n---> Package httpd-tools.x86_64 0:2.4.6-17.el7.centos.1 will be installed/n---> Package mailcap.noarch 0:2.1.41-2.el7 will be installed/n--> Finished Dependency Resolution/n/nDependencies Resolved/n/n================================================================================/n Package Arch Version Repository Size/n================================================================================/nInstalling:/n httpd x86_64 2.4.6-17.el7.centos.1 localrepo 2.7 M/nInstalling for dependencies:/n apr x86_64 1.4.8-3.el7 localrepo 103 k/n apr-util x86_64 1.5.2-6.el7 localrepo 92 k/n httpd-tools x86_64 2.4.6-17.el7.centos.1 localrepo 77 k/n mailcap noarch 2.1.41-2.el7 localrepo 31 k/n/nTransaction Summary/n================================================================================/nInstall 1 Package (+4 Dependent packages)/n/nTotal download size: 3.0 M/nInstalled size: 10 M/nIs this ok [y/d/N]: y/nDownloading packages:/n(1/5): apr-1.4.8-3.el7.x86_64.rpm | 103 kB 00:01 /n(2/5): apr-util-1.5.2-6.el7.x86_64.rpm | 92 kB 00:01 /n(3/5): httpd-tools-2.4.6-17.el7.centos.1.x86_64.rpm | 77 kB 00:00 /n(4/5): httpd-2.4.6-17.el7.centos.1.x86_64.rpm | 2.7 MB 00:00 /n(5/5): mailcap-2.1.41-2.el7.noarch.rpm | 31 kB 00:01 /n--------------------------------------------------------------------------------/nTotal 1.0 MB/s | 3.0 MB 00:02 /nRunning transaction check/nRunning transaction test/nTransaction test succeeded/nRunning transaction/n Installing : apr-1.4.8-3.el7.x86_64 1/5 /n Installing : apr-util-1.5.2-6.el7.x86_64 2/5 /n Installing : httpd-tools-2.4.6-17.el7.centos.1.x86_64 3/5 /n Installing : mailcap-2.1.41-2.el7.noarch 4/5 /n Installing : httpd-2.4.6-17.el7.centos.1.x86_64 5/5 /n Verifying : mailcap-2.1.41-2.el7.noarch 1/5 /n Verifying : httpd-2.4.6-17.el7.centos.1.x86_64 2/5 /n Verifying : apr-util-1.5.2-6.el7.x86_64 3/5 /n Verifying : apr-1.4.8-3.el7.x86_64 4/5 /n Verifying : httpd-tools-2.4.6-17.el7.centos.1.x86_64 5/5 /n/nInstalled:/n httpd.x86_64 0:2.4.6-17.el7.centos.1 /n/nDependency Installed:/n apr.x86_64 0:1.4.8-3.el7 apr-util.x86_64 0:1.5.2-6.el7 /n httpd-tools.x86_64 0:2.4.6-17.el7.centos.1 mailcap.noarch 0:2.1.41-2.el7 /n/nComplete!/n/n/nThat's it. Now, you will be able to install softwares from your server local repository.
/n/nCheers!
/n /n
|
|
|
/n/n/nApr 12, 2016 | linuxconfig.org
/n /n/n/n
Introduction/n/n- Details
/n/n- admin
/n/n- Redhat
/n/n- /n
If your Redhat server is not connected to the official RHN repositories, you will need to/n configure your own private repository which you can later use to install packages. The/n procedure of creating a Redhat repository is quite simple task. In this article we will show/n you how to create a local file Redhat repository as well as remote HTTP repository.
Using/n Official Redhat DVD as repository/n/nAfter default installation and without registering your server to official RHN repositories/n your are left without any chance to install new packages from redhat repository as your/n repository list will show 0 entries:
/n/n# yum repolist/nLoaded plugins: product-id, refresh-packagekit, security, subscription-manager/nThis system is not registered to Red Hat Subscription Management. You can use subscription-manager to register./nrepolist: 0/n/n/nAt this point the easiest thing to do is to attach your Redhat installation DVD as a local/n repository. To do that, first make sure that your RHEL DVD is mounted:
/n/n# mount | grep iso9660/n/dev/sr0 on /media/RHEL_6.4 x86_64 Disc 1 type iso9660 (ro,nosuid,nodev,uhelper=udisks,uid=500,gid=500,iocharset=utf8,mode=0400,dmode=0500)/n/n/nThe directory which most interests us at the moment is " /media/RHEL_6.4 x86_64 Disc/n 1/repodata " as this is the directory which contains information about all packages found on/n this particular DVD disc.
/n/nNext we need to define our new repository pointing to " /media/RHEL_6.4 x86_64 Disc 1/ " by/n creating a repository entry in /etc/yum.repos.d/. Create a new file called:/n /etc/yum.repos.d/RHEL_6.4_Disc.repo using vi editor and insert a following text:
/n/n[RHEL_6.4_Disc]/nname=RHEL_6.4_x86_64_Disc/nbaseurl="file:///media/RHEL_6.4 x86_64 Disc 1/"/ngpgcheck=0/n/n/nOnce file was created your local Redhat DVD repository should be ready to use:
/n/n# yum repolist/nLoaded plugins: product-id, refresh-packagekit, security, subscription-manager/nThis system is not registered to Red Hat Subscription Management. You can use subscription-manager to register./nrepo id repo name status/nRHEL_6.4_Disc RHEL_6.4_x86_64_Disc 3,648/nrepolist: 3,648/n/n
/n/n/n SUBSCRIBE TO NEWSLETTER /n
/n Subscribe to Linux Career NEWSLETTER and/n receive latest Linux news, jobs, career advice and tutorials./n
/n /n /n
/n Creating a local file Redhat repository/n/nNormally having a Redhat DVD repository will be enough to get you started however, the only/n disadvantage is that you are not able to alter your repository in any way and thus not able to/n insert new/updated packages into it. The resolve this issue we can create a local file/n repository sitting somewhere on the filesystem. To aid us with this plan we will use a/n createrepo utility.
/n/nBy default createrepo may not be installed on your system:
/n/n# yum list installed | grep createrepo/n#/n/n/nNo output indicates that this packages is currently not present in your system. If you have/n followed a previous section on how to attach RHEL official DVD as your system's repository,/n then to install createrepo package simply execute:
/n/n# yum install createrepo/n/n/nThe above command will install createrepo utility along with all prerequisites. In case that/n you do not have your repository defined yet, you can install createrepo manually:
/n/nUsing your mounted RedHat DVD first install prerequisites:
/n/n# rpm -hiv /media/RHEL_6.4\ x86_64\ Disc\ 1/Packages/deltarpm-*/n# rpm -hiv /media/RHEL_6.4\ x86_64\ Disc\ 1/Packages/python-deltarpm-*/n/n/nfollowed by the installation of the actual createrepo package:
/n/n# rpm -hiv /media/RHEL_6.4\ x86_64\ Disc\ 1/Packages/createrepo-*/n/n/nIf all went well you should be able to see createrepo package installed in your system:
/n/n# yum list installed | grep createrepo/ncreaterepo.noarch 0.9.9-17.el6 installed/n/n/nAt this stage we are ready to create our own Redhat local file repository. Create a new/n directory called /rhel_repo:
/n/n# mkdir /rhel_repo/n/n/nNext, copy all packages from your mounted RHEL DVD to your new directory:
/n/n# cp /media/RHEL_6.4\ x86_64\ Disc\ 1/Packages/* /rhel_repo//n/n/nWhen copy is finished execute createrepo command with a single argument which is your new/n local repository directory name:
/n/n# createrepo /rhel_repo//nSpawning worker 0 with 3648 pkgs/nWorkers Finished/nGathering worker results/n/nSaving Primary metadata/nSaving file lists metadata/nSaving other metadata/nGenerating sqlite DBs/nSqlite DBs complete/n/n/nYou are also able to create Redhat repository on any debian-like Linux system such as/n Debian, Ubuntu or mint. The procedure is the same except that installation of createrepo/n utility will be: # apt-get install createrepo
/n
/n /n /n
/n/nAs a last step we will create a new yum repository entry:
/n/n# vi /etc/yum.repos.d/rhel_repo.repo/n/n/n[rhel_repo]/nname=RHEL_6.4_x86_64_Local/nbaseurl="file:///rhel_repo/"/ngpgcheck=0/n/n/nYour new repository should now be accessible:
/n/n# yum repolist/nLoaded plugins: product-id, refresh-packagekit, security, subscription-manager/nThis system is not registered to Red Hat Subscription Management. You can use subscription-manager to register./nrhel_repo | 2.9 kB 00:00 ... /nrhel_repo/primary_db | 367 kB 00:00 ... /nrepo id repo name status/nRHEL_6.4_Disc RHEL_6.4_x86_64_Disc 3,648/nrhel_repo RHEL_6.4_x86_64_Local 3,648/nCreating a remote HTTP Redhat repository/n/nIf you have multiple Redhat servers you may want to create a single Redhat repository/n accessible by all other servers on the network. For this you will need apache web server./n Detailed installation and configuration of Apache web server is beyond the scope of this guide/n therefore, we assume that your httpd daemon ( Apache webserver ) is already configured. In/n order to make your new repository accessible via http configure your apache with /rhel_repo//n directory created in previous section as document root directory or simply copy entire/n directory to: /var/www/html/ ( default document root ).
/n/nThen create a new yum repository entry on your client system by creating a new repo/n configuration file:
/n/nvi /etc/yum.repos.d/rhel_http_repo.repo/n/n/nwith a following content, where my host is a IP address or hostname of your Redhat/n repository server:
/n/n[rhel_repo_http]/nname=RHEL_6.4_x86_64_HTTP/nbaseurl="http://myhost/rhel_repo/"/ngpgcheck=0/n/n/n/nConfirm the correctness of your new repository by:
/n/n# yum repolist/nLoaded plugins: product-id, refresh-packagekit, security, subscription-manager/nThis system is not registered to Red Hat Subscription Management. You can use subscription-manager to register./nrepo id repo name status/nrhel_repo_http RHEL_6.4_x86_64_HTTP 3,648/nrepolist: 3,648/nConclusion/n/nCreating your own package repository gives you more options on how to manage packages on/n your Redhat system even without paid RHN subscription. When using a remote HTTP Redhat/n repository you may also want to configure GPGCHECK as part of your repository to make sure that/n no packages had been tampered to prior their installation.
/n /n
|
|
|
/n/n/n/nFeb 08, 2017 |/n linuxservconf.blogspot.com
/n/nSometimes, especially when you create your own RPMs, it is extremely useful to keep them in a local YUM repository . The advantage /n of this is that, when you install a package, YUM automatically resolves any dependencies, not only by downloading the necessary packages /n from the other repositories you might have in you list, but also by using your local repo as a resource for potential dependencies./n
/n/nSo, when installing a package (eg my_package.rpm ) with YUM, you are supposed to have already created RPM packages for all of /n the my_package.rpm 's dependencies and to have updated the repository's metadata, so that yum is able to resolve all the dependencies. /n If these dependencies do not exist in any of the repositories in your list, then, in short, you cannot install your package with /n yum.
/n/nSo, in order to install an RPM package and all the other packages that it depends on, you only need to run:
/n/n# yum install my_package.rpm
/n/nHow to create a local YUM repo ?
/n/nYou will need an utility, named createrepo . Its RPM package exists in Fedora Extras. To install it, just run as root:
/n/nTerminal
/n/n
/n # yum install createrepoThen, put all your custom RPM packages in a directory. Assuming that this directory is /path/to/repository , you can create all /n the necessary metadata for your local repository by running the following command as root or as the user that owns the directory:/n
/n/nTerminal
/n/n
/n # createrepo -v /path/to/directoryThat's it! Your local YUM repository is ready.
/n/nKeep in mind that every time you put any new RPMs in that directory or remove any old RPMs, you will need to run the above command /n again, so that the repository metadata gets updated.
/n/nAdd your local repo to the list
/n/nThe next thing you need to do is to add your local repository to your list of repos, so that yum knows where to find it. This /n info is kept in the /etc/yum.repos.d/ directory. As root, create a new text file in this directory, name it fedora-local.repo (you /n can use any name you like, but remember to add the extension .repo ), and add the following info in it:
/n/nTerminal
/n/n
/n [[email protected]~]# cat /etc/yum.repos.d/fedora-local.repo
/n [localrepo]
/n name=[give any name you like without the square brackets ofcourse]
/n baseurl=[file:| ftp | http |<path to the repository>]
/n enabled=1
/n gpgcheck=0/n/n
/n In Order to access the repository over ftp or http the urls should be modified as follows
/n baseurl=http://server1.example.com/path/to/repository
/n or
/n baseurl=ftp://server1.example.com/path/to/repositoryAs you can see, we used the protocol file:/// in the baseurl option. This assumes that the local repo exists in the local machine. /n If it exists in another machine of your internal network, feel free to use any other protocol in order to tell yum where to find /n your local repository, For example you can use http:// , ftp:// , smb:// etc.
/n/nIn the above example, the GPG key check is disabled ( gpgcheck=0 ). If you sign your packages, you can set this to " 1 " and uncomment /n the following line ( gpgkey=... ). This contains the path to your public key, so that YUM can verify the package signatures.
/n/nYou can have as many local YUM repositories as you like.
/n/nOther uses of a local repository
/n/nUsing a local repository does not only serve as a place for your custom RPMs. You can perfectly save some bandwidth by downloading /n all the released fedora updates in that repo and use this to update all the systems of your internal network. This will save bandwidth /n and time.
/n/nThe Procedure is the same for all RPM based systems, using YUM Package Manager. So this can be applied to Fedora, Redhat and CentOS /n systems
/n/nCreate your own /n yum repository - TechRepublic
/n The standard RPM package management tool in Fedora, Red Hat Enterprise Linux, and CentOS is the yum package manager. Yum works quite /n well, if a little bit slower than other RPM package managers like apt4rpm and urpmi, but it is solid and handles dependencies extremely /n well. Using it with official and third-party repositories is a breeze to set up, but what if you want to use your own repository? /n Perhaps you manage a large computer lab or network and need to have - or want to have - certain packages available to these systems /n that you maintain in-house. Or perhaps you simply want to set up your own repository to share a few RPM packages with the world or /n just your friends./n/nCreating your own yum repository is very simple, and very straightforward. In order to do it, you need the createrepo /n tool, which can be found in the createrepo package, so to install it, execute as root:
/n/n# yum install createrepo/n/n/nOnce the package is installed, you can begin creating your repository. You will also need some RPM packages to create the repository /n with. Decide where you want to store your repository; let's say, /var/ftp/repo will be the base directory.
/n/nDepending on how particular you want to get, you can dump everything to a single repository or keep things organized. I'm a big /n fan of organization, so let's assume you will be creating a repository for Fedora 10 and have both i386 and x86_64 packages you want /n to be made available with it. I would create an appropriate directory tree using the following commands:
/n/n# mkdir -p /var/ftp/repo/Fedora/10/{SRPMS,i386,x86_64}/n/n/nNow copy your i386 packages to /var/ftp/repo/Fedora/10/i386 , your x86_64 packages to /var/ftp/repo/Fedora/10/x86_64/n , and the SRPMS you have (if wanted) to /var/ftp/repo/Fedora/10/SRPMS . To easily automate the creation of the repository /n metadata, create a shell script called create-my-repo and place it somewhere in your PATH:
/n/n#!/bin/sh/n/n/ndestdir="/var/ftp/repo/Fedora/10"/n/n/nfor arch in i386 x86_64/n/n/ndo/n/n/npushd ${destdir}/${arch} >/dev/null 2>&1/n/n/ncreaterepo ./n/n/npopd >/dev/null 2>&1/n/n/ndone/n/n/nMake the script executable and whenever you run it, it will call the createrepo tool on the two directories: /var/ftp/repo/Fedora/10/i386/n and /var/ftp/repo/Fedora/10/x86_64 . Once this is done, your repository is ready for use.
/n/nIf /var/ftp is the available FTP root, then ftp://internalhost.com/repo/Fedora/10/i386 would be the download /n URL for the i386 packages. To make this available to the other client systems, create a yum repository configuration file called/n /etc/yum.repos.d/my.repo with the following contents:
/n/n[myrepo]/n/n/nname=My Repository/n/n/nbaseurl=ftp://internalhost.com/repo/Fedora/10/$basearch/n/n/nenabled=1/n/n/nThis file can be used on both i386 and x86_64 clients due to the "$basearch" specifier. It will be enabled the next time "yum /n update" is run.
/n/nCreating your own yum repository is very easy and very straightforward, and is a great way for administrators to distribute specialized /n packages within an organization.
/n /n
|
|
|
/n/nFeb 08, 2017 | www.trinix.be
/n /n )/n/n /n/nSometimes it can be handy to set up your own repository to prevent from downloading the remote /n repository over and over again. This tutorial shows how to create a CentOS mirror for your local /n network. If you have to install multiple systems in your local network then all needed packages can /n be downloaded over the fast LAN connection, thus saving your internet bandwidth.
/n/nCreate the Directories:
/n/nmkdir -pv /var/www/html/centos/4/{os,updates}/i386
/n/nReplacing 4 and i386 with your major version and architecture.
/n Quote:/n/n
/n Additionally you'll need some deeper directories. This is the correct location to copy the CD/DVD /n rpms.
/nmkdir -pv /var/www/html/centos/4/os/i386/CentOS/RPMS//n The Base Repository /n/nCopy the RPMs from the CDs/DVD to /var/www/html/centos/base .
/n/nCreate the base repository headers:
/n/ncreaterepo /var/www/html/centos/4/os/i386/
/n/n /n The Updates Repository /n/nSelect an rsync mirror for updates: check out this list of aviable mirrors:/n Centos OS Mirror /n list and these are identified with rsync .
/n/nFor example: rsync://ftp.belnet.be/packages/centos/
/n/nThe mirrors share a common structure for updates. Simply append /updates/<d version>/<base arch> /n .
/n/nRsync to create the updates-released repository:
/n/n/usr/bin/rsync -avrt rsync://ftp.riken.jp/centos/4/updates/i386 --exclude=debug/ /var/www/html/centos/4/updates//n
/n/nThis will create a complete update repository at /var/www/html/centos/4/updates/i386 . The repodata /n directory will be created with all of the headers.
/n/nYou can additionally pipe this into mail to receive an email when updates are available.
/n/n /n/n/n
/n/n /n/n/n /n/usr/bin/rsync -avrt rsync://ftp.riken.jp/centos/4/updates/i386 --exclude=debug /var/www/html/centos/4/updates/ /n | /bin/mail [email protected] -s "New Repo Updates" /nNext I would advise to setup a cron job to run the rsync (above). In this manner your repository /n is kept updated and only new updates and headers will be downloaded to your repository.
/n/n /n Yum Configuration /n/nEdit yum.conf :
/n/nvi /etc/yum.repos.d/CentOS-Base.repo
/n/n[base]/nname=CentOS-$releasever - Base/nbaseurl=http://192.168.*.*/centos/$releasever/os/$basearch//n#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os/n#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch//ngpgcheck=1/ngpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5/n#released updates/n[update]/nname=CentOS-$releasever - Updates/nbaseurl=http://192.168.*.*/centos/$releasever/updates/$basearch//n#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates/n#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch//ngpgcheck=1/ngpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5/n/n/nThat's it.
/n/nSPECIAL THANKS TO kylehase (for sending me corrections)
/n /n/n/n/n
|
|
|
02 May 2007 | ramblings.narrabilis.com
Creating a yum repository is fairly easy, the only command you need is createrepo and some rpms. This is a quick guide to making a repo, I have a more complete example in my howto make an install server.Make a directory to contain your rpms, it's nice to name the directory the same as the repo name. Even better, segregate the rpms by architecture, i386, i686, noarch, SRPMS, etc. Copy the rpms into the appropriate directories and run create repo on that directory. Ensure you sign your rpms with your gpg key.
Example:[user@machine] mkdir -p MyRepo/i386 MyRepo/noarch MyRepo/i686 MyRepo/SRPMS [user@machine] mv myrpm.noarch.rpm MyRepo/noarch [user@machine] mv myrpm.src.rpm MyRepo/SRPMS [user@machine] mv mybinrpm.i386.rpm MyRepo/i386 [user@machine] createrepo MyRepoGroups File (comps.xml)
Now, if you want to install all the rpms in your repo, or a specific subset, you'll need to create a groups file otherwise known as comps.xml. For our example, if we wanted myrpm.noarch.rpm to be installed by default and mybinrpm.i386.rpm to be an optional install, we would create a comps.xml file like this:<comps> <!-- <meta> --> <!-- Meta information will go here eventually --> <!-- </meta> --> <group> <id>mygroup</id> <name>MyGroup</name> <default>true</default> <description>Default RPMS from MyRepo</description> <uservisible>true</uservisible> <packagelist> <packagereq type="default">myrpm</packagereq> <packagereq type="optional">mybinrpm</packagereq> </packagelist> </group> </comps>Now we need to rerun createrepo so that clients will know our group assignments.[user@machine] createrepo -g comps.xml MyRepo/etc/yum.repos.d
Now, if we want to install this group on a machine, we create a .repo file in /etc/yum.repos.d like this:[MyRepo] name=My Repository baseurl=http://path/to/MyRepo gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-MyRepoIf you didn't sign your rpms and do not wish to verify signatures, set gpgcheck=0 in your .repo file. If you did sign your rpms, then you'll need to export your gpg key into a file so yum can import the file into the rpm database.Exporting your GPG-Key for RPM/YUM
First, find the name of your key if you don't already know it.[thomas@host ~] gpg --list-keys /home/thomas/.gnupg/pubring.gpg ------------------------------------------- pub 1024D/79E7E0DB 2007-10-08 uid Repository Owner <[email protected]> sub 2048g/04F5FDBA 2007-10-08Then export the key into a file:[thomas@host ~]$ gpg --export -a "Repository Owner <[email protected]>" >RPM-GPG-KEY-example.org [thomas@host ~]$ cat RPM-GPG-KEY-example.org -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.5 (GNU/Linux) mQGiBEcKQlgRBACLKP/FOWmTf75UjfShH84YkbLFnQqOlfdYKQ7ss57cRYn1v8lj ... ... ...Then move this file to the location specified in the .repo file. Yum will install the key into the rpm database for you. To install the key manually, you can do the following:[root@host thomas]# rpm --import RPM-GPG-KEY-example.org [root@host thomas]# rpm -q gpg-pubkey gpg-pubkey-b2980b13-3c1d0597 gpg-pubkey-f51839ac-46362566 gpg-pubkey-79e7e0db-470a4258We can see that our key (gpg-pubkey-79e7e0db-470a4258) was installed into the rpm database).Now, to install this group.
[user@machine] yum groupinstall mygroupThis will install any default or mandatory rpms as listed in comps.xml, any optional rpms will not be installed.Kickstart
To install our packages via kickstart, we'll need to add the repo to our kickstart filerepo --name=MyRepo --baseurl=http://path/to/MyRepo
|
|
|
Dec 1 2011 | ibm.com/developerworks
So you have Redhat 6.x* Enterprise installed, but now you need to set-up some local repositories from the DVD which the system was created. So here is a quick guide on how to do it -
First install the createrepo command, else we can't create our yum repository.# rpm -ivh --aid /mnt
# rpm -ivh --aid /mnt/Packages/python-deltarpm-3.5-0.5.20090913git.el6.ppc64.rpm/Packages/deltarpm-3.5-0.5.20090913git.el6.ppc64.rpm # rpm -ivh --aid /mnt/Packages/createrepo-0.9.8-4.el6.noarch.rpm
Mount the installation DVD.# mount /dev/dvd /mnt
Copy over the packages to a folder.
# mkdir /etc/yum.repos.d/rhel6.x# cp /mnt/Packages/* /etc/yum.repos.d/rhel6.x
When you copy over the files you will also find a *.xml library file, either in the same dir as the source or in a sub that needs to be copied over for the next command.
# cp /mnt/repodata/repomd.xml /etc/yum.repos.d/rhel6.x
Create the repo with the createrepo command.
# createrepo -g repomd.xml /etc/yum.repos.d/rhel6.x
Create the repo file.
vi /etc/yum.repos.d/rhel6x.repo[RHEL-Repository]
name=RHEL 6.x
baseurl=file:///etc/yum.repos.d/rhel6.x
enabled=1
gpgcheck=0Update yum's repo list.
# yum clean allLoaded plugins: product-id, subscription-manager
Updating Red Hat repositories.
RHEL-Repository | 1.3 kB 00:00 ...
RHEL-Repository/primary | 1.5 MB 00:00 ...
RHEL-Repository 3210/3210
repo id repo name status
RHEL-Repository RHEL 6.x 3,210
repolist: 3,210Then test.
# yum search httpd
Loaded plugins: product-id, subscription-manager
Updating Red Hat repositories.
======================== N/S Matched: httpd =======================================
httpd.ppc64 : Apache HTTP Serverhttpd-devel.ppc : Development interfaces for the Apache HTTP server
httpd-devel.ppc64 : Development interfaces for the Apache HTTP server
httpd-manual.noarch : Documentation for the Apache HTTP server
httpd-tools.ppc64 : Tools for use with the Apache HTTP Server
mod_dav_svn.ppc64 : Apache httpd module for Subversion server
mod_dnssd.ppc64 : An Apache HTTPD module which adds Zeroconf supportName and summary matches only, use "search all" for everything.
* be sure to replace the 'x' with your version of RHEL.
Google matched content |
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: February, 19, 2020
