Search Results

Search found 3 results on 1 pages for 'tomontime'.

Page 1/1 | 1 

  • A Linux DHCP server that will listen on an non-broadcast (tap) interface?

    - by TomOnTime
    Are there any Linux DHCP servers that will listen to what Cisco calls an "unnumbered" interface, or what others might call a "NBMA" (non-broadcast) interface. I have a Linux system that connects to a number of others using GRE tunnels. The machines on the other end send DHCP requests to this machine, I can see them with tcpdump. However, ISC DHCP 3.0.3 refuses to listen to the interface because it is non-broadcast. The interface I'd like DHCP to listen to is: tap2 Link encap:Ethernet HWaddr removed-for-privacy inet6 addr: removed-for-privacy/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:518 errors:0 dropped:0 overruns:0 frame:0 TX packets:510 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:196242 (191.6 KiB) TX bytes:52425 (51.1 KiB)

    Read the article

  • How to manage a home-grown YUM package repo?

    - by TomOnTime
    There are plenty of websites that explain how to manage a mirror of YUM repos. I want to run a repo for my home-grown packages. Is there a good way to manage such repos? What I need to do: Manage 3 repos: unstable, testing, stable Self-service functions that let users add/remove/promote packages (promote means moving a package unstable?testing or testing-stable). ACLs that control which users/groups may add/remove/promote packages. Automatically re-sign packages as they move repo to repo (since the GPG key for "stable" should be different than "unstable") Automatically run "createrepo" to update repodata when needed. Suggestions?

    Read the article

  • Why does yum index get corrupted?

    - by TomOnTime
    Occasionally yum's cache gets corrupted and we see errors like this: error: db3 error(-30974) from dbenv->failchk: DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db3 - (-30974) error: cannot open Packages database in /var/lib/rpm The workaround is rm -f /var/lib/rpm/__db* and then the next "yum" command regenerates the data. My question is: what is likely to be causing this? Is there some common task that ignores locks or has other problem that causes this? We have hundreds of CentOS machines and there is no pattern to which see this problem. It could be a "one in a million" issue, which at large scale is seen often. NOTE: I realize this is a very "open ended" question, but if an answer finds the cause, I will go back and turn the question into something more canonical that directly relates to the specific issue.

    Read the article

1