Skip to main content

Joel Liu's Library tagged Sysadmin →  View Popular, Search in Google

Jul
10
2011

  • Since upstream has a 6.1 version already released, we will be using a  Continous Release repository for 6.0 to bring all 6.1 and post 6.1  security updates to all 6.0 users, till such time as CentOS-6.1 is  released itself. There will be more details about this posted within the  next 48 hours.
  • Upgrading from CentOS-4 or CentOS-5:  We recommend everyone run through a reinstall rather than attempt an  inplace upgrade from CentOS-4 or CentOS-5
  • 1 more annotation(s)...
Jul
11
2011

  • I have about the same time in Linux as you but how I found out about SL was due to the delays CentOS has been having. Previously, the CentOS releases were not far behind RHEL releases as far as timing. But when 6.0 failed to show up I visited the CentOS forum.

    For whatever reason that only the internal developers know, announced milestone after milestone were delayed. The chief complaint about CentOS has been the lack of openness or transparency with the devs. Numerous offers to help and contribute to the project have not been accepted. With little feedback or request for help, users became antsy if the CentOS project was dead in the water. That's where Scientific Linux seemed to have found some new users when they were the first out of the gate with a version 6 based on RHEL.

    While it's great that CentOS 6.0 is out, maybe the better question is to ask why not 6.1 which was already released by RHEL some time ago (May 19th) that addresses some security issues.

    I used CentOS quite a bit but have moved off to distributions as I'm happy to pay for some software and contribute to other ecosystems where there is an openness to them.

  • The "lag" you speak of actually can be thought of as a feature. For example, you don't want doing a 'yum upgrade' to upgrade PHP from 5.2 to 5.3 and break software you are running. You want your core operating system to actually be fairly stable, and not have to worry about upgrades randomly breaking things.

    When it comes down to it, you really don't need the latest and greatest software on a server. Aside from security fixes, there's very little reason to upgrade software on a server just because a new version was released.

  • 2 more annotation(s)...
Jul
10
2011

  • We have decided not to follow the UOP's usage of Installation Codes. All 'channels' are available to the System Administrator at time of installation.

    • 4. Known Issues

       
      • The installer needs at least 392MB of memory to work. Text mode will automatically be used if the system has less than 652MB of memory.

      • The text installer has limited capabilities compared to the GUI installer. Most notably there is no support for configuring partition layout, storage methods or package selection. Please refer to the official documentation for details.

      • The message "Insufficient memory to configure kdump!" appears during install. This is a known upstream bug which appears on systems with less than 4 GB RAM and solved by updating to kexec-tools-2_0_0-153_el6 or newer.

      • Content for x86_64 is split into two DVDs. The second disk contains only packages from upstream's "Optional" channel. Installs not requiring any of the packages from the "Optional" category should run using only DVD#1.
      • The i386 DVD is just a bit too large to fit on normal single layer DVD+R media. It can be burnt succesfully on DVD-R.
Jun
22
2011

  • The first reason is that system itself might just break down because it is the wrong way to do it. Sam Saffron put this perfectly when he was interviewed at MIX: “By adding more servers all we would really be doing is distributing the slow”. (Why is turning non-nouns into nouns so catchy?). The other reason is that the cost to throw more hardware at the problem starts to become untenable.

    • Do more with less

        

      You can start to become scalable very early on, even with only a few servers. There are lots of ways we generally practice scalability, a few examples are:

        
      • Code and script management tasks. When you have 3 servers you may not need to do this, you can probably do it by hand. However, when you have 100 you will have no choice.
      • Use algorithms and data structures that are efficient.
      • Use caching effectively.
      • Document tasks so you are not a single point of failure and so you don’t have to relearn things every time.
      • Use centralized authentication, configuration management, updates, etc.
      • Use automated building and deployment processes.

  • Why disgusting? Personality is the antithesis of scalability. With a large number of servers, each with their own personality, you will need more administrators, and a chaotic management structure. The Borg are the good guys. This is because of some of the distinct advantages of being more like the Borg:
  • At Stack Exchange, we have done a good job at achieving this with our web tier. We do have 1 staging web server, but for our other 9 web servers, the seventh is just seven of nine. George has made a deployment process which includes everything we need, making any web server disposible, and a new one ready for assimilation. Should one of them be destroyed, the others will automatically take over without concern. However, in some areas we are still more like the Federation. We have 4 database servers, and we have noticed areas where our db01/db02 pair is unlike our db03/db04 pair. If one of our primary servers fail, we will mourn the loss as we carry out a manual fail over process. If we were more like the Borg in this area, we could initiate self destruct on one of these servers without a care as the Borg queen would do.

  • We now keep all the web server configs the same so adding another server for a site is just a load balancer change. So currently stackoverflow.com runs on 6 servers (3 servers dedicated for stackoverflow only).
  • 3 more annotation(s)...

    • 95 Million Page Views a Month
    • 800 HTTP requests a second
    • 180 DNS requests a second
    • 55 Megabits per second
  • 1 more annotation(s)...

  • By default cron jobs sends a email to the user account executing the cronjob.  If this is not needed put the following command At the end of the cron job line  .
     
     >/dev/null 2>&1

  • cat /dev/null > filename
     <!-- /Title -->   <!-- Overview --> Zero's out the file without breaking pipe <!-- /Overview -->   

    Description:  <!-- Description --> Some applications keep an open pipe to a file and if that file is removed the application will no longer write to that file.
     By using this command it will zero out the file without breaking this open pipe. 

1 - 20 of 27 Next ›
Showing 20▼ items per page

Selected Tags

Related Tags

Highlighter, Sticky notes, Tagging, Groups and Network: integrated suite dramatically boosting research productivity. Learn more »

Join Diigo
Move to top