· KLDP.org · KLDP.net · KLDP Wiki · KLDP BBS ·
Yum-HOWTO



Yum (Yellowdog Updater, Modified) HOWTO

Robert G. Brown, rgb at phy.duke.edu

Jonathan Pickard,fatboy at techno.co.za

0.3, 2003-09-24

ÀÌ°ÍÀº Yum: Yellowdog Updater, Modified¿¡ ´ëÇÑ HOWTOÀÔ´Ï´Ù. YumÀº rpm±â¹ÝÀÇ ½Ã½ºÅÛÀ» À§ÇÑ ÀÚµ¿ ¾÷µ¥ÀÌÅÍÀÌÀÚ ÆÐÅ°Áö ¼³Ä¡/»èÁ¦µµ±¸ÀÔ´Ï´Ù. YumÀº ÀÚµ¿ÀûÀ¸·Î ÀÇÁ¸¼ºÀ» ó¸®ÇØÁÖ¸ç rpm ÆÐÅ°ÁöµéÀ» ¾ÈÀüÇÏ°Ô ¼³Ä¡, »èÁ¦ ¹× ¾÷µ¥ÀÌÆ®Çϱâ À§ÇØ ¹Ýµå½Ã ÇؾßÇÒ ÀϵéÀ» ½º½º·Î ÇØ°áÇÕ´Ï´Ù. ¶ÇÇÑ YumÀº ÀÌ¹Ì ¼³Ä¡µÇ¾ú°Å³ª ȤÀº ÀúÀå¼Ò¿¡ ¼³Ä¡°¡´ÉÇÑ ÆÐÅ°Áö¿¡ °üÇÑ Á¤º¸¸¦ È¿À²ÀûÀÌ°í ½±°Ô °Ë»öÇØ¿É´Ï´Ù. YumÀº rpmÀ̳ª ´Ù¸¥ µµ±¸µéó·³ ÀÏÀÏÀÌ ¼öµ¿À¸·Î ¾÷µ¥ÀÌÆ®ÇÒ ÇÊ¿ä°¡ ¾øÀ¸¹Ç·Î ¼ö ¸¹Àº ½Ã½ºÅÛµéÀ» ´õ¿í °ü¸®Çϱ⠽±°Ô ÇØÁÝ´Ï´Ù. ÇÑ Á¶Á÷ Àüü¸¦ Åë°ýÇÏ´Â ±Ô¸ð¸¦ ´ÜÁö ÇÑ µÎ ¸í¸¸À¸·Î Áß¾ÓÁýÁßÀûÀÎ ÆÐÅ°Áö °ü¸®¸¦ ÇÒ ¼ö ÀÖµµ·Ï, ÆÐÅ°Áö ±×·ì, ´Ù¼öÀÇ ÀúÀå¼Ò, ´ëü ÀúÀå¼Ò ¹× ±× ÀÌ»óÀ» YumÀÌ °ü¸®ÇØÁÝ´Ï´Ù. ²À ±â¾ïÇØ µÎ¼¼¿ä! ÀÌ HOWTO´Â YumÀÇ Ãʱâ pre-release °³¹ß µ¿¾ÈÀº ÀüÀûÀ¸·Î À¯µ¿ÀûÀÎ »óÅ¿¡ ÀÖ½À´Ï´Ù. ¸¹Àº ¼½¼ÇµéÀÌ ºñ¾îÀÖÀ¸¸ç, ¾î¶² °ÍµéÀº Ʋ¸®±âµµÇϸç, ¸ðµÎ°¡ °úµµ±âÀû ±¸¼º »óÅ¿¡ ÀÖ½À´Ï´Ù. ±×·³¿¡µµ ºÒ±¸ÇÏ°í, Àú´Â ÀÌ ¹®¼­ÀÇ ¾î¶² ½º³À¼¦ÀÌµç °Å±â¿¡ ±â¹ÝÇÑ ¾î´À ´©±¸·ÎºÎÅÍÀÇ ÀÇ°ßµµ ¼ÒÁßÈ÷ ÇÕ´Ï´Ù.



1. ¼Ò°³

[http]YumÀº Åø ¹× ÀÀ¿ëÇÁ·Î±×·¥ ÆÐÅ°ÁöµéÀ» ºÐ»ê½Ãų ¸ñÀûÀ¸·Î ¸¸µé¾îÁ³À¸¸ç, [http]Red Hat ÆÐÅ°Áö °ü¸® (RPM) ½Ã½ºÅÛÀ» »ç¿ëÇÏ´Â ¿î¿µÃ¼Á¦°¡ žÀçµÈ ¿öÅ©½ºÅ×ÀÌ¼Ç ³×Æ®¿öÅ©¸¦ À§ÇÑ ÆÐÅ°Áö °ü¸® ÀÚµ¿È­ µµ±¸ÀÌ´Ù. ¿ø·¡ [http]Yellowdog Linux¸¦ À§ÇØ °³¹ßµÈ ÀÚµ¿ ÆÐÅ°Áö ¾÷µ¥ÀÌÅÍÀÎ YupÀ¸·ÎºÎÅÍ À¯·¡ÇßÀ¸¸ç, µû¶ó¼­ À̸§: yumÀº "Yellowdog Updater, Modified"¸¦ ¶æÇÑ´Ù.

YupÀº óÀ½¿¡ Yellowdog Linux (´Ù¾çÇÑ ¼¼´ëÀÇ ¾ÖÇà ¸ÅŲÅä½Ã¸¦ ±¸µ¿ÇÏ´Â RPM ±â¹ÝÀÇ Linux ¹èÆ÷º»)ÀÇ Dan Burcaw, Bryan Stillwell, Stephen Edie, ±×¸®°í Troy Bengegerdes°¡ Á¦ÀÛÇÏ°í °ü¸®Çß´Ù. YumÀº Duke UniversityÀÇ Seth Vidal¿Í Michael Stenner°¡ Á¦ÀÛÇß°í Áö±Ýµµ °ü¸®ÇÏ°í ÀÖÁö¸¸, ¿ÀÇ ¼Ò½º GPL ÇÁ·ÎÁ§Æ®·Î¼­ ¸¹Àº »ç¶÷µéÀÌ (¹®¼­ÀÛ¼ºÀº ¸»ÇÒ °Íµµ ¾øÀÌ:-) ÄÚµå, ¾ÆÀ̵ð¾î ¹× ¹ö±× ¼öÁ¤¿¡ °øÇåÇß´Ù. À§ÀÇ Yum¸µÅ©¿¡´Â ¹èÆ÷ tarball¼ÓÀÇ AUTHORS°¡ ±×·¯ÇϵíÀÌ, (°ÅÀÇ) ¸ðµç °øÇåÀÚµéÀÇ ¸ñ·ÏÀÌ ³ª¿Í ÀÖ´Ù.

YumÀº Gnu Public License (GPL) µµ±¸ÀÌ´Ù; ÇØ´ç ¶óÀ̼¾½º Ç׸ñµéÀ» ÁöÅ°´Â ÇÑ ¾î¶°ÇÑ ºñ¿ëÀ̳ª »ç¿ë·á ¾øÀÌ ÀÚÀ¯·Ó°Ô ¾òÀ» ¼ö ÀÖ°í »ç¿ë, °³ÀÛ ¹× Àç¹èÆ÷°¡ °¡´ÉÇÏ´Ù.

1.1. YumÀ¸·Î ÇÒ ¼ö ÀÖ´Â °Í

(ÇöÀç) YumÀº µÎ °¡Áö Åø·Î ±¸¼ºµÇ¾î ÀÖ´Ù; ù°, yum-arch´Â Àû´çÇÑ ¼­¹ö¿¡ (ftp³ª http) ÀúÀå¼Ò¸¦ ±¸¼ºÇÏ´Â µ¥¿¡ »ç¿ëµÈ´Ù, µÑ°·Î YumÀº ÀϹÝÀûÀÎ ¿ëµµÀÇ Å¬¶óÀ̾ðÆ®ÀÌ´Ù. Yum ÀúÀå¼Ò°¡ Áغñ(¾Æ·¡¿¡ ¼­¼úµÈ °£´ÜÇÑ °úÁ¤)µÇ¸é ¾î¶² Ŭ¶óÀ̾ðÆ®µµ ÀúÀå¼ÒÀÇ rpm ±â¹ÝÀÇ ÆÐÅ°Áö¸¦ ¼³Ä¡, ¾÷µ¥ÀÌÆ®, ¶Ç´Â Á¦°ÅÇÒ ¼ö ÀÖ´Ù.

¾÷µ¥ÀÌÆ®¿¡ À־ÀÇ YumÀÇ ¿µ¸®ÇÔÀº °ü·ÃµÈ Åøµé Áß °¡Àå ¶Ù¾î³ª´Ù; YumÀº ·¹µåÇÞ 7.1 ½Ã½ºÅÛÀ» Á÷Á¢ 7.3À¸·Î ½Ç½Ã°£ ¾÷±×·¹À̵åÇÏ´Â µ¥¿¡ ±²ÀåÈ÷ ¼º°øÀûÀ¸·Î ÀÌ¿ëµÇ¾ú´Ù(¹°·Ð ¾÷±×·¹À̵åÀÇ ¼º°ø È®·üÀº ±Ùº»ÀûÀ¸·Î Ÿ°Ù ½Ã½ºÅÛÀÌ ¾ó¸¶³ª ƯȭµÇ¾ú´À³Ä¿Í Áß¿äÇÑ ¼³Á¤ ÆÄÀÏÀÇ Æ÷¸ËÀÌ Ãʱ⠸®ºñÀü°ú ÃÖÁ¾ ¸®ºñÀü »çÀÌ¿¡ ¾ó¸¶³ª ¹Ù²î¾ú´À³Ä¿¡ µû¶ó¼­ ´Þ¶óÁø´Ù. -YMMV: Your Mileage May Vary).

°Ô´Ù°¡, Yum Ŭ¶óÀ̾ðÆ®´Â ´Ù¾çÇÑ Á¤º¸Ã³¸® µµ±¸¸¦ ³»Æ÷ÇÏ°í À־, ÀÌ¹Ì ¼³Ä¡µÇ¾î Àְųª ¼³Ä¡ °¡´ÉÇÑ rpmµé ¸ðµÎ¸¦ ¸ñ·ÏÀ¸·Î ¸¸µé ¼ö ÀÖ°í, Å°¿öµå³ª globs¿¡ ±â¹ÝÇÑ rpm Çì´õ·Î ºÎÅÍ Á¤º¸¸¦ »Ì¾Æ³»°í Ç¥½ÃÇÒ ¼ö ÀÖÀ¸¸ç, ƯÁ¤ÇÑ ÆÄÀÏÀ» Á¦°øÇÏ´Â ÆÐÅ°Áö¸¦ ãÀ» ¼öµµ ÀÖ´Ù. ±×·¯¹Ç·Î YumÀº »ç¼³ ȤÀº LAN ȯ°æÀÇ ¿öÅ©½ºÅ×ÀÌ¼Ç »ç¿ëÀÚ¿¡°Ô ´ë´ÜÈ÷ À¯¿ëÇÏ´Ù; YumÀ» ÅëÇØ "°ü½ÉÀÖ´Â" ÆÐÅ°Áö°¡ ÀÖ´Â Áö ¼³Ä¡ °¡´ÉÇÑ ÆÐÅ°ÁöÀÇ ¸ñ·ÏÀ» È®ÀÎÇÒ ¼ö ÀÖÀ¸¸ç, ƯÁ¤ µµ±¸¸¦ Æ÷ÇÔÇÑ ÆÐÅ°Áö¸¦ ã°Å³ª ƯÁ¤ÇÑ ¾÷¹«¿¡ Àû¿ë½ÃÅ°´Â µî, ±× ÀÌ»óÀÇ ÀϵéÀ» ÇÒ ¼ö ÀÖ´Ù.

YumÀº ½ÉÁö¾î ¿ÜºÎÀÇ ºÐ»êµÈ °ü¸® ¿µ¿ª±îÁöµµ º¸¾È°ú »óÈ£Àۿ뼺ÀÇ º¸ÀåÀÌ ¿ä±¸µÇ´Â ÇÑ "Áß¾ÓÁýÁßÀûÀÎ" ÆÐÅ°Áö °ü¸®¸¦ °¡´ÉÇÏ°Ô ÇØÁÖ´Â, client-pull µµ±¸·Î ¼³°èµÇ¾ú´Ù. Yum Ŭ¶óÀ̾ðÆ®¿¡´Â ¾Æ¹«·± root ±ÇÇѵµ ÇÊ¿äÇÏÁö ¾Ê´Ù -- YumÀº ±â²¯ÇØ¾ß Å¬¶óÀ̾ðÆ®·ÎºÎÅÍ ÀúÀå¼Ò ¼­¹ö(´ë°³ Áß¾ÓÀÇ -- ±×¸®°í ±× ¸¸ÇÑ ÀÚ°ÝÀÌ ÀÖ´Â -- ±ÇÀ§ÀÚ¿¡ ÀÇÇØ °ü¸®µÇ´Â °÷)·ÎÀÇ À͸í Á¢±Ù(Á¦ÇÑÀÌ ÀÖµç ¾øµç)À» ¿ä±¸ÇÑ´Ù. ÀÌ »ç½ÇÀº ÇÑ ¹«¸®ÀÇ ±â°èµéÀÌ ±× ¼ÒÀ¯ÀÚ¿Í ÀÚ¿¬ÀûÀ¸·Î »ý±â´Â ¼ö¸¹Àº ³×Æ®¿öÅ© °ü¸®Àڵ鿡ÀÇÇØ À¯ÁöµÇ´Â (À̸¦Å×¸é ´ëÇаú °°Àº), ºÐ»êµÈ ³×Æ®¿öÅ© °ü¸® ȯ°æÇÏ¿¡¼­ ¸®´ª½º ½Ã½ºÅÛµéÀÇ "Áß¾ÓÁýÁßÀû" È®Àå °ü¸®¸¦ À§Çؼ­ YumÀÌ °¡Àå ¸Å·ÂÀûÀÎ µµ±¸°¡ µÇ°Ô ÇÑ´Ù.

¾î¶² LAN ȯ°æ¿¡¼­µç °¡Àå º¸ÆíÀûÀÎ Yum »ç¿ë¹ý Áß Çϳª´Â ½Ã½ºÅÛÀÇ ¸ðµç rpm ÆÐÅ°Áö¸¦ , ¸ðµç º¸¾ÈÀ̳ª ±â´É ÆÐÄ¡¸¦ ÇÑ ¾÷µ¥ÀÌÆ®¸¦ Æ÷ÇÔÇÏ¿©, ÀúÀå¼Ò¿¡¼­ ¼³Ä¡°¡´ÉÇÑ ÃֽŠ¹öÀüÀ¸·Î ¾ÈÀüÇÏ°Ô ¾÷µ¥ÀÌÆ®Çϵµ·Ï °¢°¢ÀÇ YumÀ¸·Î °ü¸®ÇÏ´Â ½Ã½ºÅÛ¿¡¼­ nightly cron ½ºÅ©¸³Æ®¸¦ ½ÇÇà½ÃÅ°´Â °ÍÀÌ´Ù. ¸¸¾à ÀÌ·¯ÇÑ nightly ¾÷µ¥ÀÌÆ®¸¦ ¼öÇàÇϵµ·Ï ¹Ì¸® ¼³Á¤µÈ rpm ¹öÀüÀ¸·Î YumÀ» ¼³Ä¡ÇÑ´Ù¸é, ÇϳªÀÇ °øÅëÀûÀÎ ÀúÀå¼Ò¿¡ ±â¹ÝÇÏ¿© ½Ã½ºÅÛµéÀ» ¼³Ä¡ÇÏ´Â Àüü Ä·ÆÛ½º´Â ¹èÆ÷¿Í ¸®ºñÀü ¹× º¸¾È¿¡ À־ ¿Ïº®ÇÑ ÅëÀϼºÀ» ÀÌ·ê ¼ö ÀÖ´Ù. º¸¾È ¹× ±âŸ ¾÷µ¥ÀÌÆ®´Â ¾î¶² Ŭ¶óÀ̾ðÆ®µé¿¡ ´ëÇؼ­µµ root±ÇÇÑÀÌ ÇÊ¿ä¾ø´Â (¹ÏÀ» ¼ö ÀÖ´Â) °ü¸®ÀÚ°¡ ÀúÀå¼Ò¿¡ ¾÷µ¥ÀÌÆ®µÈ rpmÀ» ¿Ã¸°Áö 24½Ã°£ÀÌ Ã¤ ³ÑÁö ¾Ê¾Æ ¸ðµç ³×Æ®¿öÅ©·Î ¿¬°áµÈ Ŭ¶óÀ̾ðÆ®»ó¿¡ ³ªÅ¸³¯ °ÍÀÌ´Ù.

°á°úÀûÀ¸·Î ÇÑ ¸íÀÇ ¹ÏÀ» ¼ö ÀÖ´Â °ü¸®ÀÚ°¡ YumÀ¸·Î ´ëÇÐ Ä·ÆÛ½º, ±â¾÷, Á¤ºÎ ÇùÀÇȸ³ª ¿¬±¸±â°ü Àüü¿¡ ´ëÇؼ­ ½Å·ÚÇÒ ¸¸ÇÑ ÇϳªÀÇ rpm ÀúÀå¼Ò(ÁýÇÕ)¸¦ À¯ÁöÇÒ ¼ö ÀÖ´Ù. ÇÑ ¹èÆ÷º»ÀÇ ¼­·Î ´Ù¸¥ ºÎºÐ¿¡ ´ëÇÑ Ã¥ÀÓÀ» ±¸ºÐµÈ ÀúÀå¼ÒÀÇ ½Å·ÚÇÒ ¼ö ÀÖ´Â ¿©·¯ °ü¸®ÀÚµé »çÀÌ¿¡ ¾ÈÀüÇÏ°Ô ³ª´­ ¼ö ÀÖ°í, ÇÑ ¸íÀÇ Áö¿ª °ü¸®ÀÚ°¡ Ä·ÆÛ½º ¼öÁØÀÇ ¿©·¯ ÀúÀå¼Ò·ÎºÎÅÍÀÇ Á¦°øÀ» Ãß°¡Çϰųª µ¤¾î¾µ ¼ö ÀÖ´Â ÇϳªÀÇ ½Å·ÚÇÒ ¼ö ÀÖ´Â Áö¿ª ÀúÀå¼Ò¸¦ Ãß°¡ÇÒ ¼ö ÀÖ´Ù. °°Àº ¸®ºñÀü ¼öÁØÀÇ ¸ðµç ½Ã½ºÅÛµéÀº ¼³Ä¡µÈ ÆÐÅ°Áö (Áö¿ª °ü¸®ÀÚÀÌ µ¤¾î ¾´ °Í±îÁö Æ÷ÇÔ)°¡ Çã¶ôÇÏ´Â ÇÑ ÀÏÄ¡¼º°ú »óÈ£¿î¿ë¼ºÀÌ º¸ÀåµÈ´Ù. ±×·¯¹Ç·Î YumÀº ÇÑ ¸íÀÇ °³ÀÎÀÌ ÇÑ ÀÛ¾÷À» ¼ö õ´ëÀÇ ±â°è¸¦ Æ÷°ýÇÏ´Â ±Ô¸ð·Î È®Àå½Ãų ¼ö ÀÖ´Â, ÀúÀå¼Ò ±â¹ÝÀÇ ÆÐÅ°Áö ¹èÆ÷ ¹× ½Ã½ºÅÛ °ü¸®¸¦ À§ÇÑ ³î¶ó¿ï Á¤µµ·Î °­·ÂÇÑ µµ±¸ÀÌ´Ù.

±×¸®°í YumÀº freeÀÌ´Ù. ÀÌ º¸´Ù ´õ ÁÁÀ» ¼ö´Â ¾ø´Ù...

1.2. YumÀÇ ÀÛµ¿ ¹æ½Ä

YumÀÌ ¾î¶»°Ô ÀÛµ¿ÇÏ´ÂÁö ÀÌÇØÇϱâ À§ÇØ ¸î¸î ¿ë¾î¸¦ Á¤ÀÇÇÏ´Â°Ô µµ¿òÀÌ µÈ´Ù.
  • ¼­¹ö: ¼­¹ö¶ó´Â ¿ë¾î´Â ´ë°³ ÀúÀå¼Ò¿¡ Á¢±ÙÀ» Á¦°øÇÏ´Â ¹°¸®Àû ½Ã½ºÅÛÀ» ÀÏÄ´´Ù.±×·¯³ª YumÀÌ Ã³À½ °³¹ßµÇ¾úÀ» ¶§´Â ´ë°³ ÀúÀå¼Ò´ç ¿ÀÁ÷ ÇϳªÀÇ ¼­¹ö°¡ ÀÖ°í ¼­¹ö´Â ¶§¶§·Î ÀúÀå¼ÒÀÇ µ¿ÀǾî·Î ¾²¿´´Ù. ¾Æ·¡¿¡¼­´Â ÀüÀÚÀÇ ÀÇ¹Ì -- ÀúÀå¼Ò ÀÚü°¡ ¾Æ´Ï¶ó ÀúÀå¼Ò¿¡ Á¢±ÙÀ» Á¦°øÇϴ ƯÁ¤ÇÑ À¥, ftp, nfs ¼­¹ö -- ·Î¸¸ ¾µ °ÍÀÌ´Ù.
  • ÀúÀå¼Ò: ÀúÀå¼Ò´Â ¾î¶² ÆÄÀϽýºÅÛ Æ®¸® ¾Æ·¡¿¡ ÀÖ´Â rpmÀÇ ¸ðÀÓÀÌ´Ù. Yum°ú °ü·ÃµÈ ´ë°³ÀÇ ¸ñÀûÀ» À§ÇØ, ÀúÀå¼Ò´Â µÎ°¡Áö Áß¿äÇÑ Ãß°¡ÀûÀΠƯ¼ºÀ» °¡Áø´Ù. Æ®¸®¾Æ·¡¿¡¼­ ½ÇÇàÇÏ´Â ¸í·É¾îÀÎ yum-arch°¡ ÀÖÀ¸¸ç, ÀÌ°ÍÀº ±× Æ®¸®¾Æ·¡ÀÇ ¸ðµç rpm¿¡ ´ëÇÑ Çì´õ¹× °æ·Î Á¤º¸¸¦ Æ÷ÇÔÇÏ´Â "headers"¶ó´Â µð·ºÅ丮¸¦ ¸¸µé¾î ³½´Ù. ÇÑÆí, ÀúÀå¼Ò´Â URL (±× ÀúÀå¼Ò Æ®¸®¿¡ ´ëÇØ Çϳª ¶Ç´Â ±× ÀÌ»óÀÇ http://my.webserver.ext/path, ftp://my.ftp.server.ext/path, file://full/file/path)À» ÅëÇØ Á¢±ÙÀÌ °¡´ÉÇÏ´Ù.
  • serverid: À§¿¡ ÀûÀº °Íó·³, YumÀÇ Ãʱ⠹öÀü¿¡¼­´Â ¼­¹ö¿Í ÀúÀå¼Ò °£¿¡ ÀÏ´ëÀÏ ´ëÀÀÀÌ Á¸ÀçÇß´Ù. ±×·¯³ª, ÀÌ ´ëÀÀÀº ´Ù´ë´Ù°¡ ¾Æ´Ï´Ù. ÇϳªÀÇ ÀúÀå¼Ò°¡ ¸¹Àº ¼­¹ö¿¡ ¹Ì·¯µÉ ¼ö ÀÖ°í, ÇϳªÀÇ ¼­¹ö°¡ ¸¹Àº ÀúÀå¼Ò¸¦ °¡Áú ¼ö ÀÖ´Ù. ÀúÀå¼Ò¿¡ "È®°íÇÑ" Á¢±ÙÀ» ±¸¼ºÇÒ ¶§ (ÀÌ°ÍÀº ¾î¶² ÀúÀå¼ÒÀÇ ÁÖ¼­¹ö°¡ Á×¾úÀ» ¶§ °°Àº ÀúÀå¼Ò¿¡ ´ëü ¼­¹ö·ÎÀÇ URLÀ» Á¦°øÇÏ´Â °ÍÀ» ¶æÇÑ´Ù) ¼­¹ö³ª ÀúÀå¼Ò ÀÚü¸¸À¸·Î´Â ¸í¹éÈ÷ ºÒ°¡´ÉÇÑ ÀÏÀÎ, ÀÏÁ¾ÀÇ °íÀ¯ÇÑ id¸¦ ÀúÀå¼Ò¿¡ ºÙÀÌ´Â °ÍÀÌ ÇÊ¿äÇÏ°Ô µÇ¾ú´Ù. ±×·¡¼­ serverid´Â ÁÖ¾îÁø ÇϳªÀÇ baseurl ¾Æ·¡¿¡ ÀÖ´Â ¸ðµç ÀúÀå¼ÒµéÀÌ ¼­·Î°£ÀÇ (±×·²µí ÇÑ) ¹Ì·¯¶ó´Â °ÍÀ» °¡¸®Å°±â À§ÇØ yum.conf ¿¡¼­ »ç¿ëµÇ´Â °íÀ¯ÇÑ ¶óº§ÀÌ´Ù.
  • RPM: "Red Hat Package Manager"¸¦ ¶æÇϸç, linux ¹èÆ÷º»À» À§ÇÑ µµ±¸, ¶óÀ̺귯¸®, ¹ÙÀ̳ʸ® ¹× µ¥ÀÌÅÍÀÇ "ÆÐÅ°Áöµé"À» ¹èÆ÷ÇÏ°í °ü¸®ÇϱâÀ§ÇØ Red HatÀÌ °³¹ßÇÑ Åø¼ÂÀÌ´Ù. ¿ÏÀüÇÑ ¿ÀÇ ¼Ò½ºÀ̸ç Red Hat »Ó¸¸ ¾Æ´Ï¶ó ¼ö ¸¹Àº linux ¹èÆ÷º»ÀÇ ±â¹ÝÀÌ µÇ°í ÀÖ´Ù. ¾Æ·¡ ¹®¼­¿¡¼­ "rpm"À» ¸»ÇÒ ¶©, ´ë°³ ÆÐÅ°ÁöÀ̸§-¹öÀü.rpmÀ¸·Î ¸í¸íµÇ´Â ´ÜÀÏ ÆÐÅ°Áö¸¦ ÀÏÄ´´Ù. YumÀÌ ¾î¶»°Ô ÀÛµ¿ÇÏ´ÂÁö ÀÌÇØÇÏ·Á¸é, rpmÀÇ ±¸Á¶¿¡ ´ëÇÑ ¾à°£ÀÇ ÀÌÇØ°¡ ÇÊ¿äÇÏ´Ù.

RPMÀº ±âº»ÀûÀ¸·Î ¼¼ ºÎºÐ: Çì´õ, ¼­¸í ¹× (´ë°³ ¾ÐÃàµÈ) ÆÄÀÏ ±× ÀÚü·Î ±¸¼ºµÈ´Ù. Çì´õ´Â ¿Ïº®ÇÑ ÆÄÀÏ ¸ñ·Ï, ÆÐÅ°ÁöÀÇ ¼³¸í, Á¦°øÇÏ´Â ±â´É ¹× ¶óÀ̺귯¸®µéÀÇ ¸ñ·Ï, Á¦´ë·Î ÀÛµ¿Çϱâ À§ÇØ (´Ù¸¥ ÆÐÅ°Áö·ÎºÎÅÍ) ÇÊ¿ä·Î ÇÏ´Â µµ±¸µéÀÇ ¸ñ·Ï, Ãæµ¹À» ÀÏÀ¸Å°´Â (¾Ë·ÁÁø) ´Ù¸¥ ÆÐÅ°ÁöµéÀÇ Á¸Àç, ±×¸®°í ±×¿Ü ¿©·¯°¡Áö¸¦ Æ÷ÇÔÇÑ´Ù. ±âº»ÀûÀÎ rpm µµ±¸´Â ´ÙÀ½°ú °°Àº ¹æ½ÄÀ¸·Î ÇϳªÀÇ ÆÐÅ°Áö¸¦ ¼³Ä¡(ȤÀº »èÁ¦!)ÇϱâÀ§ÇØ Çì´õ ¼ÓÀÇ Á¤º¸¸¦ ¿ä±¸ÇÑ´Ù.:

  • ÀÌ ÆÐÅ°Áö¸¦ ¼³Ä¡ÇÏ´Â °ÍÀÌ ÀÌ¹Ì ¼³Ä¡µÈ ÆÐÅ°ÁöµéÀ» ¸Á°¡¶ß¸®Áö ¾Ê´Â´Ù. (Àç±ÍÀûÀ¸·Î, ±âÁ¸ÀÇ ÆÐÅ°ÁöµéÀº ÀÚ½ÅÀÇ ÆÐÅ°ÁöµéÀÌ ¼³Ä¡µÇ±â¸¦ ¿ä±¸ÇϹǷÎ)
  • ÀÌ ÆÐÅ°Áö°¡ Á¦´ë·Î µ¿ÀÛÇϱâ À§ÇØ ÇÊ¿äÇÑ ¸ðµç ÆÐÅ°ÁöµéÀÌ ¼±ÅÃµÈ ÆÐÅ°Áö¿Í ÇÔ²² Àç±ÍÀûÀ¸·Î (ÀÌ¹Ì ¼³Ä¡µÇ¾î Àְųª) ¼³Ä¡µÈ´Ù.
  • ÀÌ ÆÐÅ°ÁöÀÇ ÃֽŹöÀüÀÌ (À߸øÇÏ¿©) ±× ÆÐÅ°ÁöÀÇ ±âÁ¸¹öÀüÀ» ±³Ã¼ÇÏÁö ¾Ê´Â´Ù.

À¯»çÇÑ ¹æ¹ýµéÀÌ »èÁ¦¿¡µµ Àû¿ëµÊÀ» ¸í½ÉÇ϶ó; À̸¦Å׸é, ¾î¶² ÆÐÅ°Áö¸¦ »èÁ¦ÇÏ´Â °ÍÀÌ ³²¾ÆÀÖ´Â ´Ù¸¥ ÆÐÅ°ÁöµéÀ» ¸Á°¡¶ß·Á¼­´Â ¾ÈµÈ´Ù µî.

ÀÌ °úÁ¤Àº ÀϹÝÀûÀ¸·Î "ÆÐÅ°Áö ÀÇÁ¸¼º ÇØ°á"·Î ¾Ë·ÁÁ® ÀÖÀ¸¸ç ÆÐÅ°Áö °ü¸®¿¡¼­ °¡Àå ¾î·Á¿î ºÎºÐ ÁßÀÇ ÇϳªÀÌ´Ù. µÎ ¼¼°³ÀÇ ¶óÀ̺귯¸® ¹× ÅøÀ» ¿ä±¸ÇÏ´Â ¾î¶² ÆÐÅ°Áö¸¦ ¼³Ä¡ÇÏ°í ½ÍÀ» ¶§°¡ ÀÖ´Ù. °è¼ÓÇؼ­ ¶óÀ̺귯¸®µéÀÌ ´Ù¸¥ ¶óÀ̺귯¸®¸¦, ÅøÀÌ ´Ù¸¥ ÅøÀ» ¿ä±¸ÇÒ Áöµµ ¸ð¸¥´Ù. ¼³Ä¡°¡ ¿Ï·áµÉ ¹«·Æ¿¡´Â, ±× ÆÐÅ°ÁöÀÇ ¼³Ä¡°¡ ±âÁ¸¿¡ ¼³Ä¡µÈ ÆÐÅ°Áöµé Áß ¾î¶² °Í°úµµ Ãæµ¹ÇÏÁö ¾Ê°Å³ª ³²¾ÆÀÖ´Â ¾î¶² ÆÐÅ°Áöµéµµ ¸Á°¡¶ß¸®Áö ¾Ê´Â, ¿©¼¸°³ ȤÀº ¿©´ü°³ÀÇ ´Ù¸¥ ÆÐÅ°ÁöµéÀ» ¿ä±¸ÇßÀ» °ÍÀÌ´Ù.

¸¸¾à Áö±Ý±îÁö rpmµéÀ» ¼öµ¿À¸·Î °ü¸®Çϱ⸦ ½ÃµµÇØ¿Ô´Ù¸é, ¸ðµç Çì´õµé°ú ÀÇÁ¸¼ºÀ» ÃßÀûÇس»°í ¸ðµç Ãæµ¹À» ÇØ°áÇÏ´Â °ÍÀÌ ½±Áö ¾Ê´Ù´Â °Í°ú ½Ã½ºÅÛ °ü¸®Àڷμ­ ¾î¶² ½Ã½ºÅÛ¿¡¼­´Â ÀÌ°ÍÀ» ¾÷µ¥ÀÌÆ®ÇÏ°í, ´Ù¸¥ ½Ã½ºÅÛ¿¡¼­´Â Àú°ÍÀ», ¿©±â¼­ ¾î¶² ÆÐÅ°Áö¸¦ ¸®ºôµåÇÏ°í, Àú±â¼­´Â Áö¿ªÀûÀ¸·Î /usr/local¿¡ ¼³Ä¡ÇÏ´Â µîÀÇ Ã³Áö¶ó¸é ½ÇÁ¦·Î »óȲÀÌ ´õ¿í ¾î·Á¿ö Áø´Ù´Â »ç½ÇÀ» ¾Ë °ÍÀÌ´Ù. °á±¹¿¡´Â (¶§·Î´Â ¿ÏÀüÇÑ ÁÂÀý°¨À¸·Î) ¾î¶² rpmÀ» --force ¿É¼ÇÀ¸·Î ¼³Ä¡ÇÏ°Ô µÇ°í, ±× ÈÄ¿¡´Â ½Ã½ºÅÛÀÇ rpm µ¥ÀÌÅͺ£À̽º ÀÚü°¡ ºÒÀÏÄ¡¼ºÀ» °®°ÔµÇ¸ç ¾î¶² rpmÀÇ ¼³Ä¡µµ ½ÇÆÐÇÏ°Ô µÇ¾î °è¼ÓÇؼ­ --force¸¦ ÇÏ°Ô µÉ ¼öµµ ÀÖ´Ù. ³×Æ®¿öÅ©°¡ Á¡Á¡ ¹«Áú¼­ÇØÁö°í, ±× ¶§¹®¿¡ º¸¾ÈÀÇ À§Çè°ú ¿Àµ¿ÀÛÀ» ¾ß±âÇÏ°Ô µÈ´Ù.

±×·¸´Ù°í ÆÐÅ°Áö¸¦ ¾÷µ¥ÀÌÆ®ÇÏÁö ¾Ê´Â °Í ¶ÇÇÑ ³­Ã³ÇÑ »óȲÀÌ´Ù. ¸¸¾à ¹èÆ÷º» ±â¹ÝÀÇ ¼³Ä¡¸¦ ¼Õ´ëÁö ¾Ê°í µÐ´Ù¸é ±ò²ûÇÑ »óÅ·ΠÀÖ°Ô µÈ´Ù. ±×·¯³ª, ±× ÀϺδ ¼³Ä¡½Ã¿¡ ¸Á°¡Á³À» ¼öµµ ÀÖ´Ù. -- °¡Àå ÁÖÀǸ¦ ±â¿ïÀÌ´Â ÁÖ¿ä ¹èÆ÷º»µéÀÇ °æ¿ì¿¡µµ Ç×»ó ¹ö±×°¡ ÀÖ°Ô ¸¶·ÃÀÌ´Ù. ±×·¯ÇÑ ¹ö±× ÁßÀÇ ¸î¸îÀº º¸¾È ¹ö±×À̸ç, Å©·¡Ä¿°¡ ±×°ÍÀ» ¹ß°ßÇÏ°í Ãë¾àÁ¡ÀÌ ºü¸£°Ô Àü°³µÈµÇ¸é "½Ã½ºÅÛÀ» ÆÐÄ¡ÇÏÁö ¾ÊÀ¸¸é ±â»ýÃæÀ» ¾î¼­ ¿À¶ó°í ³»¹ö·Á µÎ´Â °Ý"ÀÌ µÇ°í ¸¸´Ù. ÀÌ°ÍÀº ¸ðµç ¿î¿µÃ¼Á¦ÀÇ ÀüüÀûÀÎ ¹®Á¦ÀÌ´Ù; ½ÉÁö¾î (¹ÙÀÌ·¯½º¿Í Å©·¡Ä¿¿¡°Ô Ãë¾àÇϱâ·Î ¾Ç¸í³ôÀº) Windows ±â¹ÝÀÇ ½Ã½ºÅ۵鵵 öÀúÇÏ°Ô ÃÖ½ÅÀÇ »óÅ·ΠÀ¯ÁöÇÑ´Ù¸é »ó´çÈ÷ ¾ÈÀüÇÏ°Ô ¸¸µé ¼ö ÀÖ´Ù. °á±¹, »ç¿ëÀÚµéÀº ÀÛ¾÷¿¡ Áß´ëÇÑ ¿µÇâÀ» ¹ÌÄ¡´Â -- ¿ø·¡ÀÇ ±ú²ýÇÏ°í ÀÏ°üµÈ ¼³Ä¡°¡ ¾Æ´Ñ -- ÀÌ ÆÐÅ°Áö Àú ÆÐÅ°Áö¸¦ ¿ä±¸ÇÏ°í ã°Ô µÈ´Ù.

°í·ÁÇغ¸¸é, ¾î¶² Àü¹®ÀûÀÎ LAN °ü¸®ÀÚµµ (ȤÀº ½ÉÁö¾î Á¶ÀâÇÑ ´ÜÀÏ ¸®´ª½º ¿öÅ©½ºÅ×ÀÌ¼Ç ¼ÒÀ¯ÀÚÁ¶Â÷µµ) °ÅÀÇ ¼±ÅÃÀÇ ¿©Áö°¡ ¾ø´Ù; ½Ã½ºÅÛ¿¡ ÀÌ¹Ì ¼³Ä¡ÇÑ ÆÐÅ°ÁöµéÀ» ÃÖ½ÅÀÇ, ÆÐÄ¡µÈ, ¾ÈÀüÇÑ, ¹ö±×°¡ ÇØ°áµÈ ¹öÀüÀ¸·Î ¾÷µ¥ÀÌÆ®ÇÏ´Â °Í°ú, óÀ½ÀÇ ±âº» ¼³Ä¡·Î ÀÇÁ¸ÇÏ´Â ¹èÆ÷º»¿¡ ¾ø¾ú´ø °ÍµéÀ» Æ÷ÇÔÇÑ »õ·Î¿î ÆÐÅ°ÁöµéÀ» ¼³Ä¡ÇÏ´Â °Í¿¡ À־ ÀÏÁ¾ÀÇ ¸ÞÄ¿´ÏÁòÀ» °¡Áö°í ÀÖ¾î¾ß¸¸ ÇÑ´Ù. ´Ù¸¸ ¹®Á¦´Â: ¾î¶°ÇÑ ¸ÞÄ¿´ÏÁòÀ» »ç¿ëÇØ¾ß ÇÏ¸ç ±×¿¡ µû¶ó¼­ ¾î¶² (±ÝÀüÀûÀÎ ¸é »Ó¸¸ ¾Æ´Ï¶ó ½Ã°£, ³ë·Â, ÇнÀ ¹× ½Å·Ú¼º¿¡ À־ÀÇ) ºñ¿ëÀÌ µå´Â ÁöÀÏ °ÍÀÌ´Ù. ÀÌÁ¦ ÀÌ ¹®Á¦¸¦ °í·ÁÇغ¸ÀÚ.:

Åë»óÀûÀÎ ÀúÀå¼Ò(repository)¿¡´Â ¼ö¸¹Àº ÆÐÅ°Áöµé(´ë·« ¼öõ °³)ÀÌ µé¾î ÀÖÀ¸¸ç, ¿©±â¿¡´Â ¼ö¸¹Àº Çì´õ(header)µéÀÌ Æ÷ÇԵǾî ÀÖ´Ù. ³»°¡ Áö±Ý ÀÛ¾÷À» ÁøÇàÇÏ°í ÀÖ´Â ½Ã½ºÅÛ¿¡´Â ´ë·« 700°³ÀÇ ÆÐÅ°ÁöµéÀÌ ¼³Ä¡µÇ¾î ÀÖ´Ù. ¾î·µç, °¢°¢ÀÇ ÆÐÅ°Áö ±¸¼º¿¡¼­ {¾ÐÃà ÆÄÀÏ}(archive) ºÎºÐÀº, ÀÌ ºÎºÐÀº ½ÇÁúÀûÀÎ ¹ÙÀ̳ʸ®(binary)µé°ú ¶óÀ̺귯¸®(library)µé°ú ¼³Ä¡µÇ´Â ¹®¼­ µîµîÀ» Æ÷ÇÔÇϴµ¥, °ÅÀÇ ´ëºÎºÐÀ» Â÷ÁöÇÑ´Ù. -- ±×·¡¼­ ÀϹÝÀûÀÎ °æ¿ì¿¡ rpm Àüü Å©±â´Â °Å±â¿¡ Æ÷ÇÔµÈ Çì´õº¸´Ù ´ë·« 10ÀÇ 2 Á¦°ö ¹è¿¡¼­ 4 Á¦°ö ¹è Á¤µµ[1] Á¤µµ ´õ Å©´Ù. ¿¹¸¦ µé¸é, `¿ÀÇ ¿ÀÇǽº'(¸Å¿ì Å« ÆÐÅ°Áö ÁßÀÇ ÇϳªÀÓ)ÀÇ Çì´õ´Â ÀüºÎ ÇÕÇؼ­ 100 ų·Î¹ÙÀÌÆ® Á¤µµÀÇ Å©±âÀÌ´Ù. ¹Ý¸é¿¡, ±× rpm ÀÚ½ÅÀÇ Å©±â´Â ¾à 30 ¸Þ°¡¹ÙÀÌÆ®ÀÌ´Ù. ±×°ÍÀÇ Çì´õ´Â ÀÏ ÃÊÀÇ ¸î ºÐÀÇ ÀÏ Á¤µµÀÇ ÂªÀº ½Ã°£ µ¿¾ÈÀÌ¸é ´ëºÎºÐÀÇ ³×Æ®¿öÅ©µé¿¡¼­ ÃæºÐÈ÷ Àü¼ÛÀÌ °¡´ÉÇÏ´Ù. ¹Ý¸é, ±× rpm ÀÚ½ÅÀº 100BT[2]ÀÎ ³×Æ®¿öÅ©¸¦ ÅëÇؼ­ Àü¼ÛÇصµ ¼ö ÃÊ ÀÌ»óÀÌ °É¸®¸ç, ¿¹¸¦ µé¾î, DSL, ÄÉÀ̺í, ¶Ç´Â »ó´ëÀûÀ¸·Î ´À¸° Æí¿¡ ¼ÓÇÏ´Â ¾î¶² Á¾·ùÀÇ ³×Æ®¿öÅ©¸¦ ÅëÇؼ­µµ ¼ö ºÐ Á¤µµ°¡ °É¸°´Ù. ÀüÀÚ(îñíº)[3]´Â ÀúÀå¼ÒÀÇ ¹°¸®Àû ¼­¹ö¿¡¼­ ¹Ì¼ÒÇÑ ½Ã°£¸¸À» Á¡À¯ÇÏÁö¸¸, ÈÄÀÚ(ý­íº)[4]´Â ÇØ´ç ¼­¹ö¿¡ ¹«½Ã ¸øÇÒ, Áöü¸¦ À¯¹ßÇÏ´Â ºÎÇÏ(ݶùÃ)[5]¸¦ ÀÏÀ¸Å²´Ù. ÀÌ ¸ðµç °ÍÀº, ´ëÃæ ¼öõ ´ëÀÇ Å¬¶óÀ̾ðÆ®(client)¿Í ÇÑ ´ëÀÇ ¹°¸®Àû ¼­¹ö¿¡ ¿©·¯ °³ÀÇ °¢±â ´Ù¸¥ ÀúÀå¼Ò¸¦ µÎ·Á°í °èȹÇÏ´Â ±Ô¸ð¸¦ °¡Áø °»½Å(update) ¼³ºñ¸¦ ¼³°èÇϰųª °ñ¶ó ÀâÀ¸·Á ÇÒ ¶§¿¡´Â ½É°¢ÇÏ°Ô °í·ÁµÇ¾î¾ß ÇÒ »çÇ×ÀÌ´Ù.

ÃÊâ±âÀÇ ÀÚµ¿È­µÈ °»½Å µµ±¸µéÀº ·ÎÄÃ[6]¿¡ ¸¶¿îÆ®(mount)µÈ ÀúÀå¼Ò µð·ºÅ丮¸¦ ¿ä±¸ÇÏ¸ç ±×·Î ÀÎÇØ ¸ðµç Çì´õµéÀ» ºü¸£°Ô Á¢±ÙÇÒ ¼ö ÀÖµµ·Ï ¸¸µé¾ú°Å³ª (ºñ·Ï »ó´ëÀûÀ¸·Î ´À¸° ÆíÀÎ CD-ROM µå¶óÀ̺ê¶ó°í ÇÒÁö¶óµµ ÀûÀýÇÑ ¼Óµµ·Î rpmµéÀ» Àü¼ÛÇÏ¿© °Å±â¿¡ µé¾î ÀÖ´Â Çì´õ¸¦ »Ì¾Æ³»¼­ ó¸®ÇÏ´Â µ¥¿¡ ÁöÀåÀÌ ¾øÀ» Á¤µµ·Î ºü¸£±â ¶§¹®ÀÌ´Ù.) ¶Ç ´Ù¸¥ ¹æ½ÄÀ¸·Î´Â, °»½Å½ÃÅ°·Á´Â client·Î °¢°¢ÀÇ ¿¬°áµÈ rpmÀ» Åë°·Î ³×Æ®¿öÅ©¸¦ ÅëÇØ Àü¼ÛµÇµµ·Ï ¿ä±¸Çߴµ¥, ÀÌ´Â ´ÜÁö Çì´õ¸¦ Àо·Á´Â ¸ñÀû¶§¹®À̾ú´Ù. `¾ÕÀÇ °Í'Àº ·ÎÄà Ãø¿¡¼­´Â ºü¸£Áö¸¸, ·ÎÄà Ãø¿¡ Ä¿´Ù¶õ µð½ºÅ© °ø°£À» Â÷ÁöÇØ ¹ö¸®°í, (°Ô´Ù°¡ »õ·Î¿î °ñÄ©°Å¸®°¡ »ý±â´Âµ¥, ±×°ÍÀº ¸ðµç ·ÎÄà ÃøÀÇ º¹»çº»À» ¿øº»(master) ÀúÀå¼Ò¿Í {ÀÏÄ¡Çϵµ·Ï °»½ÅµÇ°Ô}(synchronized) °è¼Ó À¯ÁöÇÏ´Â ÀÛ¾÷ÀÌ´Ù.) "µÚÀÇ °Í"Àº ¾öû³ª°Ô ´À¸®´Ù. °Ô´Ù°¡ ¾çÂÊ ¸ðµÎ ³×Æ®¿öÅ© ÀÚ¿øÀ» »ó´çÈ÷ ¼Ò¸ðÇÑ´Ù.

----
  • [1] ¿ªÀÚÁÖ: ¿ø¹®Àº "two to four orders of magnitude larger"À̸ç, ±× ¶æÀº [http]¾ßÈÄ ¿µ¿µ»çÀü °Ë»ö°á°ú ƯÈ÷ Á¦2¹øÇ®À̸¦ º¸½Ã¿À
  • [2] 100BaseT, ´õ ÀÚ¼¼ÇÑ °ÍÀº [http]100BaseT¿¡ ´ëÇÑ empas°Ë»ö °á°ú¸¦ º¼ °Í.
  • [3] ¿ªÀÚÁÖ: "¾ÕÀÇ °Í", ÀÌ ±Û¿¡¼­´Â, "{rpm Çì´õ}¸¸À» Àü¼ÛÇÏ´Â °Í"À» ¶æÇÔ
  • [4] ¿ªÀÚÁÖ: "µÚÀÇ °Í", ÀÌ ±Û¿¡¼­´Â, "rpmÀ» Åë°·Î Àü¼ÛÇÏ´Â °Í"À» ¶æÇÔ
  • [5] ¿ªÀÚ ÁÖ: ¹«°Å¿î Áü
  • [6] ¿ªÀÚ ÁÖ: ÀÌ ¸»Àº ¿ø·¡ "±¹ºÎÀûÀÎ", "Áö¿ªÀûÀÎ", "¹üÀ§°¡ Á¼Àº"À̶ó´Â ¶æÀÇ ÀÏ¹Ý ´Ü¾î¿´À¸³ª, ÄÄÇ»ÅÍ ³×Æ®¿öÅ© Åë½Å¿¡¼­ ÀÌ ¸»À» ºô·Á°¡¼­ ÀÚ±âµé ºÐ¾ßÀÇ Àü¹® ¿ë¾î·Î »ç¿ëÇÑ ´Ü¾î·Î½á, ÀÌ ¹®¸Æ¿¡¼­´Â ³×Æ®¿öÅ©¿¡¼­ »ó´ë ÆíÀÌ ¾Æ´Ñ, ³×Æ®¿öÅ© ¿¬°á¿¡¼­ÀÇ ÀÌÂÊ Æí, ³×Æ®¿öÅ©°¡ ´ÜÀýµÇ¾îµµ ³» ¼ÕÀ¸·Î Á÷Á¢ Á¶ÀÛÀ» ÇÒ ¼ö ÀÖ´Â ÀÌÂÊ ÆíÀÇ ±â°è Àåºñ¸¦ ¶æÇÑ´Ù. ÀÏ¹Ý ´Ü¾î·Î¼­ÀÇ "local"ÀÇ ¹Ý´ë¸»Àº "global"(±¤¹üÀ§ÇÑ)ÀÌÁö¸¸, ³×Æ®¿öÅ© Àü¹®¿ë¾î·Î½áÀÇ ¹Ý´ë¸»Àº "remote"(¸Ö¸® ¶³¾îÁø, ÀúÂÊÀÇ)¶ó´Â Á¡À» »ý°¢Çϸé ÀÌÇØ°¡ ½¬¿ï °ÍÀÌ´Ù. ¿¹: "local host"ÀÇ ¹Ý´ë¸»Àº "global host"°¡ ¾Æ´Ñ "remote host"ÀÓ.

DeleteMe doob ¿©±âºÎÅÍ ¾Æ·¡ÀÇ DeleteMe doob±îÁö doobÀÌ ¹ø¿ªÇϱâ·Î ÂòÇß½À´Ï´Ù -- doob 2004-01-24 15:02:50

ÀÌ°ÍÀº YumÀÌ ÇØ°áÇØÁÖ´Â ±âº»ÀûÀÎ ¹®Á¦ÀÌ´Ù. 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.

As a parenthetical note, the author has used yum's caches in a trick to create a "virtual" update repository on his homogeneous, DSL-connected home LAN. By NFS exporting and mounting (rw,no_root_squash) /var/cache/yum to all the LAN clients, once normal updates have caused a header or rpm to be retrieved for any local host, they are available to all the local hosts over a (much faster than DSL) 100BT NFS mount. This saves tremendously on bandwidth and (campus) server load, using instead the undersubscribed server capacity of a tiny but powerful LAN. Best of all, there "is no setup"; what I just described is the works. A single export and a mount on all the clients and yum itself transparently does all of the work.

DeleteMe doob ¿©±â±îÁö doobÀÌ ¹ø¿ªÇϱâ·Î ÂòÇß½À´Ï´Ù. -- doob 2004-01-24 15:02:50

However, it is probably better in many cases to use rsync or other tools to provide a faithful mirror of the repository in question and use yum's fallback capability to accomplish the same thing (single use of a limited DSL channel) by design. 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.

Indeed, it is now so powerful that it risks losing some of its appealing simplicity. This HOWTO is intended to document yum's capabilities so even a novice can learn to use it client-side effectively in a very short time, and so that LAN administrators can have guidance in the necessarily more complex tasks associated with building and maintaining the repositories from which the yum clients retrieve headers and rpm's.

YumÀÇ °³¹ßÀº ¾ÆÁ÷ ¿Ï·á µÇÁö ¾Ê¾Ò´Ù. Áö¿øÀÚµéÀÌ GUI ȯ°æÇÏ¿¡¼­ ÀÛ¾÷ ÁßÀÌ´Ù.(...) Yum's development is far from over. Volunteers are working on a GUI (to encapsulate many of yum's features for tty-averse users). Some of yum's functionality may be split off so that instead of a single client command there are two, or perhaps three (each with a simpler set of subcommand options and a clear differentiation of functionality). The idea of making yum's configuration file XML (to facilitate GUI maintenance and extensibility) is being kicked around. And of course, new features are constantly being requested and discussed and implemented or rejected. Individuals with dreams of their own (and some mad python or other programming skills:-) are invited to join the yum list and participate in the grand process of open source development.

1.3. Yum, RPM, ±×¸®°í Red Hat


Because yum invokes the same tools and python bindings used by e.g. Red Hat to actually resolve dependencies and perform installations (functioning as basically a supersmart shell for rpm and anaconda that can run directly from the local header cache) it has proven remarkably robust over several changes to the rpm toolset that have occurred since its inception, some of them fairly major. It is at least difficult for yum to "break" without Red Hat's own rpm installation toolset breaking as well, and after each recent major change yum has functioned again after a very brief period of tuneup.

It is important to emphasize, however, that yum is not a tool for administering Red Hat (only) repositories. Red Hat will be prominently mentioned in this HOWTO largely because we (Duke) currently use a Red Hat base for our campuswide linux distribution, maintain a primary (yum-enabled) Red Hat mirror, and are literally down the road a few miles from Red Hat itself. Still, if anything, yum is in (a friendly, open source) competition with Red Hat's own up2date mechanism and related mechanisms utilized by other distribution vendors.

So Note Well: Yum itself is designed for, and has been successfully used to support, rpm repositories of any operating system or distribution that relies on rpm's for package management and contains or can be augmented with the requisite rpm-python tools. Yum has been tested on or is in production on just about all the major rpm-based linuces, as well as at least one Solaris repository. Its direct conceptual predecessor (with which it shares many design features and ideas, although very little remaining actual code) is Yellowdog Linux's updater tool yup, which had nothing whatsoever to do with Red Hat per se. Yum truly is free like the air, and distribution-agnostic by deliberate design.

1.4. Karmic Balance¿¡ ´ëÇÑ È£¼Ò


It is worth taking a short moment here and put in a bit of a plug for the distribution providers, Red Hat, Mandrake, SuSE, Yellowdog and all the rest. Yum is a tool that (clearly) can completely short circuit some, if not all, of their expected/hopeful income streams. Using the methods described below, one can literally scale any distribution over the entire Internet, working directly from a mirror (of a mirror of a mirror...) from their original web distribution, in such a way that all maintenance is fully automated and yet makes the distribution provider absolutely no money for doing the toplevel maintenance on the base distribution itself.

There are obvious ethical and practical issues here. Ethically one should exchange value to remain in karmic balance with the world ecology, including the amorphous and chaotic one that encompasses all of linux. There are two ways to do so in the open source world: share in the work of providing the services or pay some money (to help pay for the time and profit of those that do the work for you).

Practically one should be aware that if a distribution provider doesn't make enough money to pay for the actual work and capital investment required to assemble, test, debug, maintain, and distribute the software (plus a fair profit) they will either go out of business or alter their business model in ways that make it more difficult for us all to work efficiently and scalably from their distribution without paying them some money.

For both reasons I would urge that even though one can obtain linux using the methodologies described in this HOWTO, install it on ten thousand systems in a single organization, and maintain it completely automagically with yum for free, one seriously consider meeting one's ethical and practical responsibilities and ensuring that you pay the global mind back, either way.

I personally do both. I'm writing this HOWTO, and have written GPL packages in the past and made them publically available. I have participated in all sorts of linux development processes and am on a dozen high level linux lists. I still make sure that I buy something inexpensive from Red Hat (my current primary distribution) every two or three years so that they make a buck or two for every one of the systems I personally run in my house, per year.

It would be lovely if the primary distribution vendors made this easier. Obviously, I install via dulug and maintain via yum, so the RH 9 box set I purchased was a complete waste (and I'll cheerfully give it away if I can find anybody to give it to). I'd have rather found a paypal link on the RH website where one could utterly voluntarily kick in a payment and NOT get a damn thing back from them -- no updates, no free support services, nothing at all but continued free access to their distribution via the chain of mirrors I use to install and maintain it. Pure revenue for them, pure karmic peace for me.

1.5. RPM ÀúÀå¼ÒÀÇ ¹«¸ðÇÔ


A moment or two of meditation upon dependency resolution should suffice to convince one that Great Evil is possible in a large rpm repository. You have hundreds, perhaps thousands of rpm packages. Some are commercial, some are from some major distribution(s), others are local homebrew. What if, in all of these packages built at different times and by different people, you ever find that there exist rpm's such that (e.g.) rpm A requires rpm B, which conflicts with rpm C (already installed)? What if rpm A requires rpm B (revision 1.1.1) but rpm B (revision 1.2.1) is already installed and is required in that revision by rpm C (also already installed)? It is entirely possible to assemble an "rpm repository from hell" such that nearly any attempt to install a package will break something or require something that breaks something.

(As yet another parenthetical note, this was the thing that made many rpm-based distribution users look at Debian with a certain degree of longing. Apt untangles all of this for you and works entirely transparently from a single distribution "guaranteed to be consistent", and provides some lovely tools (some of which are functionally cloned in yum) for package management and dependency resolution. However, as is made clear on the yum site, yum is a better solution in many ways than apt or, for that matter, Current or up2date. I believe that the designers are working fairly aggressively to make sure it stays that way.)

A cynical (but correct) person would note that this was why rpmfind and other rpm "supertools" ultimately failed. Yes, rpmfind could locate any rpm on the planet in its superrepository a matter of a few seconds, BUT (big but) resolving dependencies was just about impossible. If one was lucky, installing an e.g. Mandrake rpm on a Red Hat system that used SuSE libraries rpm's would work. Sometimes one required luck to install the Red Hat rpm's it would find on a Red Hat system, as they were old or built with non-updated libraries. Sometimes things would "kind of work". Other times installing an rpm would break things like all hell, more or less irreversibly.

Untangling and avoiding this mess is what earns the major (rpm-based or not) linux distribution providers their money. They provide an entire set of rpm's (or other packages) "all at once" that are guaranteed to be consistent in the distribution snapshot on the CD's or ISO images or primary website. All rpm's required by any rpm in the set are in the set. No rpm's in the provided set conflict with other rpm's in the set. Consequently any rpm in the set can be selected to be installed on any system built from the distribution with the confidence that, once all the rpm dependencies are resolved, the rpm (along with its missing dependencies) can be successfully installed. The set provided is at least approximately complete, so that one supposedly has little incentive or need to install packages not already in the distribution (except where so doing requires the customer to "buy" a more expensive distribution from the vendor:-).

In the real world this ideal of consistency and completeness is basically never achieved. All the distributions I've ever tried or know about have bugs, often aren't totally consistent, and certainly are not complete. A "good" distribution can serve as a base for a repository and support e.g. network installs as well as disk or CD local installs, but one must be able to add, delete, update packages new and old to the repository and distribute them to all the systems that rely on the repository for update management both automatically and on demand.

Alas, rpm itself is a terrible tool to use for this purpose, a fact that has driven managers of rpm-based systems to regularly tear their hair for years now. Using rpm directly to manage rpm installs, the most one can do is look one step ahead to try to resolve dependencies. Since dependency loops are not at all uncommon on real-world repositories where things are added and taken away (and far from unknown even in box-set linux distributions that are supposed to be dependency-loop free) one can literally chase rpm's around in loops or up a tree trying to figure out what has to be installed before finally succeeding in installing the one lonely application you selected originally.

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. Installing locally built software into /usr/local becomes Evil and must be prohibited as impossible to keep up to date and maintained. Commercial packages have to have their cute (but often dumb) installation mechanisms circumvented and be repackaged into some sort of rpm for controlled distribution.

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.

For all of these reasons an entire section of this HOWTO is devoted to a guide for repository maintainers and rpm builders, including some practices which (if followed) would make dependency and revision numbering problems far less common and life consequently good.

In the next few sections we will see where to get yum, how to install it on the server side, and then how to set up and test a yum client. Following that there will be a few sections on advanced topics and design issues; how to set up a repository in a complex environment, how to build rpm's that are relatively unlikely to create dependency and revision problems in a joint repository, how to package third party (e.g. site licensed) software so it can be distributed, updated, and maintained via yum (linux software distributors take note!) and more.

1.6. ÀúÀÛ±Ç


Yum HOWTO Copyright (c) 2003 by Robert G. Brown

ÀÌ ¹®¼­´Â ¾î¶² ÇüÅ·εç ÀÚÀ¯·Ó°Ô º¹»ç ¹× ¹èÆ÷ (ÆǸųª Á¦°ø)ÇÒ ¼ö ÀÖ´Ù. ¼öÁ¤À̳ª ºñÆòÀº ¹®¼­ °ü¸®ÀÚ¿¡°Ô º¸³»ÁÖ±æ ¹Ù¶õ´Ù. ¸¸¾à ´ÙÀ½ »çÇ×µéÀ» ÁöŲ´Ù¸é ÆÄ»ýº»À» ¸¸µé°í ¹èÆ÷Çصµ ÁÁ´Ù.:

  • ÆÄ»ýº»À» (sgml°ú °°ÀÌ °¡Àå ¾Ë¸ÂÀº Çü½ÄÀ» °®Ã߾) LDP (Linux ¹®¼­ ÇÁ·ÎÁ§Æ®)¿¡ º¸³»°Å³ª ȤÀº ±×¿Í ºñ½ÁÇÏ°Ô ÀÎÅͳݿ¡ ¿Ã¸± °Í. LDP¿¡ º¸³½ °ÍÀÌ ¾Æ´Ï¶ó¸é, ±× ¹®¼­ÀÇ À§Ä¡¸¦ LDP¿¡°Ô ¾Ë¸± °Í.
  • ÆÄ»ýº»ÀÇ ÀúÀÛ±ÇÀº ÀÌ ¹®¼­¿Í °°Àº °ÍÀ» ¾²°Å³ª GPLÀ» »ç¿ëÇÒ °Í. ÀúÀÛ±Ç °øÁö´Â ¹°·Ð Àû¾îµµ »ç¿ëÇÑ ÀúÀÛ±ÇÀÇ ¸µÅ©¸¦ Æ÷ÇÔÇÒ °Í.
  • ÀÌÀüÀÇ ÀúÀÛÀÚ¿Í ÁÖ¿äÇÑ °øÇåÀÚµéÀÇ °ø·Î¸¦ Ç¥½ÃÇÒ °Í.

¸¸¾à ¹ø¿ªÀÌ ¾Æ´Ñ ÆÄ»ýº» Á¦ÀÛÀ» °í·ÁÇÑ´Ù¸é, ±× °èȹÀ» ÇöÀçÀÇ ¹®¼­ °ü¸®ÀÚ¿Í ÀdzíÇÏ±æ ¹Ù¶õ´Ù.

1.7. Ã¥ÀÓÀÇ ÇÑ°è


ÀÌ ¹®¼­ÀÇ Á¤º¸¸¦ ÀڱⰡ Ã¥ÀÓÁö°í »ç¿ëÇ϶ó. ³ª´Â ÀÌ ¹®¼­ÀÇ ³»¿ë¿¡ ´ëÇÑ ¾î¶°ÇÑ ÀáÀçÀûÀΠåÀÓµµ ºÎÀÎÇÑ´Ù. ÀÌ ¹®¼­¿¡ Æ÷ÇÔµÈ °³³ä, ¿¹Á¦ ¹× ±âŸ ³»¿ëµéÀÇ »ç¿ëÀº ÀüÀûÀ¸·Î ÀÚ½ÅÀÇ Ã¥ÀÓÀÌ´Ù.

º°´Ù¸¥ ¹æ¹ýÀ¸·Î Ç¥½ÃÇÏÁö ¾Ê´õ¶óµµ, ¸ðµç ÀúÀÛ±ÇÀº ±× ¼ÒÀ¯ÀÚ¿¡°Ô ÀÖ´Ù. ÀÌ ¹®¼­¿¡ Æ÷ÇÔµÈ ¿ë¾î »ç¿ëÀº ¾î¶°ÇÑ »óÇ¥³ª ¼­ºñ½º±ÇÀÇ À¯È¿¼º¿¡ ¿µÇâÀ» ³¢Ä¡´Â °ÍÀ¸·Î °£ÁֵǾ´Â ¾ÈµÈ´Ù.

Ưº°ÇÑ »óÇ°À̳ª »óÇ¥¸¦ °Å·ÐÇÏ´Â °ÍÀº ±×¿¡´ëÇÑ ÁöÁö·Î ¿©°Ü¼­´Â ¾ÈµÈ´Ù.

Áß´ëÇÑ ¼³Ä¡Àü¿¡ ½Ã½ºÅÛÀ» ¹é¾÷ÇÒ °Í°ú ±ÔÄ¢ÀûÀÎ °£°ÝÀ¸·Î ¹é¾÷À» ¸¸µé °ÍÀ» °­·ÂÈ÷ ±Ç°íÇÑ´Ù.

1.8. »õ¼Ò½Ä


ÀÌ°ÍÀº º» ¹®¼­ÀÇ Ã¹ ¸±¸®ÁîÀ̹ǷÎ, ±×´ÙÁö ¼Ò½ÄÀÌ ¾ø´Ù.

±Ã±ØÀûÀ¸·Î ÀÌ ¹®¼­ÀÇ ÃÖÁ¾ ¹öÀüÀÌ http://www.linux.duke.edu/projects/yum/yum_HOWTO.html (¾Æ¸¶ ¾ÆÁ÷Àº µ¿ÀÛÇÏÁö ¾ÊÀ½)°ú °°Àº URL¿¡¼­ ¾òÀ» ¼ö Àֱ⸦ Èñ¸ÁÇÑ´Ù.

1.9. °ø·Î ¹× °¨»ç


Greg Wildman gregw at techno.co.za Stein Gjoen sgjoen at nyx.net Russ Herrold Seth Vidal Michael Stenner

(±× ¿Ü Yum ¸®½ºÆ®¿¡ ÀÖ´Â »ç¶÷µé).

ƯÈ÷ rgb´Â ÀÌ HOWTO°¡ À¯·¡µÈ ±âº» ¹®¼­¸¦ Æ÷ÇÔÇؼ­ YumÀ» Áö¼ÓÀûÀ¸·Î Á¦ÀÛÇÏ°í °ü¸®ÇÑ Seth Vidal°ú Michael Stenner´Â ¹°·Ð, ÀÌ ¹®¼­°¡ ´ëÃæ ÆÄ»ýµÇ¾ú´Ù°í º¼ ¼ö ÀÖ´Â ÃÖÃÊÀÇ non-HOWTO ¿Â¶óÀÎ Yum ¹®¼­ÀÇ ÀÛ¼º¿¡ µµ¿òÀ» ÁØ Russ Herrold¿¡°Ôµµ ±íÀÌ °¨»çÇÑ´Ù. ¾î¶°ÇÑ ºñÆòÀ̳ª Á¦¾Èµµ ¹Þ¾Æ µéÀδ٠: Myum mailing list. À¥»çÀÌÆ® [https]yum mailing list¸¦ ¹æ¹®Çصµ ÁÁ´Ù.

2. HOWTO ±¸¼º


2.1. º» HOWTOÀÇ Å뵶À» ÇÇÇÏ´Â ¹ý

ÀÌ HOWTO´Â ¼¼ ºÎ·ùÀÇ µ¶ÀÚµéÀ» À§ÇØ ¼³°èµÇ¾ú´Ù.

  • ´Üµ¶½Ã½ºÅÛ »ç¿ëÀÚ: ¸¸¾à Çϳª ¶Ç´Â ±× ÀÌ»óÀÇ ½Ã½ºÅÛÀ» °¡Áö°í ÀÖ°í, ÀÚ½ÅÀÇ ÀúÀå¼Ò¸¦ ¼³Á¤Çϴµ¥´Â °ü½ÉÀÌ ¾øÀ¸¸ç, ´Ù¸¸ »õ ¼ÒÇÁÆ®¿þ¾î ÆÐÅ°Áö¸¦ ã¾Æ¼­ ¼³Ä¡ÇÏ°í ½Ã½ºÅÛÀ» ÃÖ½ÅÀÇ »óÅ·ΠÀ¯ÁöÇϱâ À§Çؼ­ YumÀÇ »ç¿ë¹ýÀ» ¹è¿ì°íÀÚ ÇÑ´Ù¸é, ÀÌ´Â ´Üµ¶½Ã½ºÅÛ »ç¿ëÀÚÀÌ´Ù. ±×·¸´Ù¸é ÀÏ·¯µÎ±â ºÎºÐ°ú Yum ¼³Ä¡ÇÏ±â ¹× yum.conf ±×¸®°í Yum Ŭ¶óÀ̾ðÆ® ÀÚü¿¡ ´ëÇÑ ºÎºÐ±îÁö´Â ±×³É Áö³ªÃĵµ µÈ´Ù. ¸¸¾à ½Ã°£ ¶Ç´Â Èï¹Ì°¡ ÀÖ°í ÇÑ °³ ÀÌ»óÀÇ ½Ã½ºÅÛ¿¡ °ü¿©ÇØ¾ß ÇÑ´Ù¸é ´Ù¸¥ ºÎºÐµéµµ ´ë°­ Àо´Â °ÍÀÌ ÁÁ´Ù. - »ý°¢ÇÏ´Â °Íº¸´Ù ÀúÀå¼Ò ¹Ì·¯¸¦ ¼³Á¤ÇÏ´Â °ÍÀº ½±´Ù. °Ô´Ù°¡ Áß¿ä µµ±¸µé¿¡ ´ëÇØ ¸¹ÀÌ ¾Ë ÇÊ¿äµµ ÀüÇô ¾ø´Ù. ½ÃÀÛÇϴµ¥ Ãß°¡ÀûÀÎ µµ¿òÀ» ¾ò±â À§ÇØ Yum ¸ÞÀϸµ ¸®½ºÆ®¿¡ °¡ÀÔÇϴ°ÍÀ» ¿øÇϰųª ±×·¸Áö ¾ÊÀ» Áöµµ ¸ð¸¥´Ù. -- ÀÏ´Ü ½ÃÀÛÇßÀ¸¸é ÇÊ¿ä ¾øÀ» °ÍÀÌ´Ù.

  • ¿öÅ©½ºÅ×ÀÌ¼Ç ³×Æ®¿öÅ©ÀÇ ½Ã½ºÅÛ °ü¸®ÀÚ: ¸¸¾à Çϳª ȤÀº ´õ ÀÌ»óÀÇ ½Ã½ºÅÛµéÀ» ¼ÒÀ¯Çϰųª Ã¥ÀÓÁ®¾ßÇÏ°í ÇÑ °³ ȤÀº ±× ÀÌ»óÀÇ ÀúÀå¼Ò¸¦ ±¸¼ºÇÏ·Á°í ÇÑ´Ù¸é, Àüü ¹®¼­¸¦ Àû¾îµµ ´ë°­ ÈÈ¾î º¸°Å³ª ÀÐÀ» ÇÊ¿ä°¡ ÀÖ´Ù. ÀÌ HOWTO ´Â »ç½Ç ÀÌ »ç¶÷µéÀ» ¿ì¼±ÀûÀÎ µ¶ÀÚ·Î ¿©±â°í ¼³°èµÇ¾ú´Ù. º» ¹®¼­ÀÇ ¸î ºÎºÐµé(¹è°æÁö½ÄÀÌ ´õ ºÎÁ·ÇÑ µ¶ÀÚµéÀ» À§ÇØ »ðÀÔÇÑ ºÎºÐµé)Àº ±×³É Áö³ªÃĵµ µÇÁö¸¸, »ìÆ캸¸é ¹«¾ùÀÎÁö ¾Ë ¼ö ÀÖÀ» °ÍÀÌ´Ù. Ãß°¡ÀûÀÎ Áö¿øÀ̳ª °³¹ß¿¡ Âü¿©Çϱâ À§ÇØ Yum °³¹ßÀÚ ¸ÞÀϸµ ¸®½ºÆ®¿¡ °¡ÀÔÇÒ ÇÊ¿ä°¡ Àְųª °¡ÀÔÀ» ¿øÇϰųª ȤÀº ±×·¸Áö ¾ÊÀ» Áöµµ ¸ð¸¥´Ù.

  • °³¹ßÀÚ: ¸¸¾à Á÷Á¢ÀûÀÎ ¹èÆ÷ ¼ö´ÜÀ¸·Î YumÀ» »ç¿ëÇϰųª Yum ÀÚüÀÇ °³¹ß Âü¿©¿¡ °ü½ÉÀÌ ÀÖ´Â ¼ÒÇÁÆ®¿þ¾î °³¹ßÀÚ¶ó¸é, ¿ª½Ã Àüü ¹®¼­¸¦ ´ë°­ ÈÈ¾î º¸°Å³ª Àд °ÍÀÌ ÇÊ¿äÇÏ°ÚÁö¸¸, ÀÌ ¹®¼­·Î´Â ºÎÀûÀýÇÒ °ÍÀÌ´Ù. ¾Æ·¡ÀÇ °ø½Ä Yum À¥»çÀÌÆ®¿¡ ¸µÅ©µÈ Yum ¸®½ºÆ®¿¡ °ÅÀÇ ºÐ¸í °¡ÀÔÇØ¾ß µÉ °ÍÀÌ´Ù.

3. À¯¿ëÇÑ ¸µÅ©µé:

´ÙÀ½Àº YumÀ» °øºÎÇÏ´Â »ç¶÷µé¿¡°Ô À¯¿ëÇÑ ¸µÅ©µéÀÌ´Ù.:

  • Yum °ø½Ä À¥»çÀÌÆ®: http://www.linux.duke.edu/projects/yum
  • Yum HOWTO (ÃֽŠ¹öÀü): http://www.phy.duke.edu/~rgb/General/yum_HOWTO.php
  • Yum¿¡ ´ëÇÑ ±â»ç: http://www.phy.duke.edu/~rgb/General/yum_articicle.php ÀÌ°ÍÀº Yum¿¡ °üÇÑ ÂªÀº ±Û·Î¼­, ÀÏÁ¾ÀÇ "ÀÔ¹®¼­"ÀÌ´Ù.
  • Duke University Linux Users Group (DULUG) Red Hat ÀúÀå¼Ò ¹Ì·¯: http://mirror.dulug.duke.edu/pub/yum-repository/redhat ÀÌ ÀúÀå¼Ò ¸ðÀ½Àº Yum¿¡ ÃÖÀûÈ­µÇ¾úÀ¸¸ç Red Hat Linux 7.1ºÎÅÍ 9±îÁö Áö¿øÇÑ´Ù. Red Hat Linux°¡ ³»³â (2004)ºÎÅÍ ÀÌ ¹öÀüµéÀ» ´õÀÌ»ó Áö¿øÇÏÁö ¾ÊÀ¸¹Ç·Î ´ëºÎºÐÀÇ »ç¿ëÀÚµéÀÌ Fedora¸¦ ¼±È£ÇÏ¿© Red Hat Linux´Â ¼Ò¿ë¾ø°Ô µÇ¾ú´Ù. ÀÌ°ÍÀº ÇöÀç ±âº» yum.conf¿¡ Æ÷ÇÔµÈ ÀúÀå¼Ò·Î¼­, YumÀÌ ´ëºÎºÐÀÇ Red Hat »ç¿ëÀÚµéÀ» À§ÇÑ RPM ¹Ú½º¿Í ¾ó¸¶°£ ÀÚµ¿À¸·Î µ¿ÀÛÇϵµ·Ï ÇÑ´Ù.

4. ÀÏ·¯µÎ±â


4.1. Superuser ¿ä±¸»çÇ×

¸®´ª½º¿Í À¯´Ð½º´Â ÀϹݻç¿ëÀÚ°¡ ¼ÒÇÁÆ®¿þ¾î, ¶óÀ̺귯¸®, ¶Ç´Â Áß¿äÇÑ ¼³Á¤ Á¤º¸¸¦ ¼³Ä¡, Á¦°Å, º¯°æÇÏ´Â °ÍÀ» ¸·´Â´Ù. On a networked, professionally run installation of workstations the need for this sort of control to ensure security and functionality is obvious. On a privately owned and controlled workstation, the need is less obvious but just as profound. Even there the owner of the workstation needs to take extreme care whenever working with the fundamental system configuration and package installation or they will likely break the system or leave it vulnerable to crackers.

To ensure that an adequate degree of care is exercised when doing things that could render a system unusable or vulnerable, linux and Unices require the owner of such a workstation to assume root privileges, usually by means of the su command. In order to execute the privileged commands to add or remove software from your system, you must therefore become root. To do this, enter (in a tty window such as an xterm):
$ su
root ¾ÏÈ£¸¦ ÀÔ·ÂÇÑ´Ù. ÇÁ·ÒÇÁÆ®´Â sharp ±âÈ£ `#'°¡ µÈ´Ù
# yum list
to remind you to be sharp as root.

°æ°í! It is essential that you heed this advice to "be sharp" as you can destroy your system's installation with a careless keystroke, especially one involving wildcards such as '*' or '?'. Certain yum commands (notably upgrade and remove) can have unexpected side effects depending on the whims of the maintainers of RPMs in the repository, so caution and testing are advised. Be certain that you understand what a command will do, including side effects, before invoking it, especially with commands that delete files.

Some yum commands will actually work fine for ordinary, unprivileged users. In general these are the informational yum commands, discussed next. Note that the unprivileged commands do require that the yum header cache exist, so they will not work at all correctly if run before root has run a yum command to create current images of the header files.

4.2. Yum ±¸Çϱâ


"YumÀ» ±¸ÇÏ´Â ¹æ¹ý"¿¡´Â ¿©·¯°¡Áö°¡ ÀÖ´Ù. :
  • If you are only trying to obtain a copy of yum to install on your personal workstation so you can use it as a client, directing it for updates to one of the growing number of public repositories that support yum-based access, then you can download the prebuilt rpm's from the yum website linked below.
  • If you are setting up a repository to serve a LAN (or even a WAN) or you are planning to install yum for use as a client only on a LAN, again directing it to one of the public repositories that support yum, and are not interested in participating actively in yum development, then you should get the yum tarball (.tgz compressed source directory) from the yum website linked below.
  • Finally, if you are setting up yum for a LAN and either want to participate in yum's ongoing development (joining the yum list to get help and submit bug reports and patches) or encounter difficulty getting the stable version of yum downloaded from the yum website working (perhaps because your system is very new or not one of the distributions already well-supported), you will likely want to access the CVS repository and get a tarball of the current yum snapshot.

°¢°¢ÀÇ ¹æ¹ýµéÀº ¾Æ·¡¿¡¼­ ÀÚ¼¼È÷ ¼³¸íÇÑ´Ù.

Yum RPM ³»·Á¹Þ±â

If your goal is just to get yum and install it on a client, you will likely just want to get yum in a ready-to-install-and-run rpm from from the main yum website. One can select and download the appropriate rpm for your architecture (which matters) from the yum website http://www.linux.duke.edu/projects/yum.

To explain the importance of matching architecture for a tool written in a presumably agnostic and slowly varying scripting language, note that yum is written in python (the agnostic and slowly varying language:-) and uses the python rpm bindings, the same as Red Hat's anaconda and up2date. Ahh, good news and bad news, same as always.

The good news is that the basic python code is indeed quite stable, and using the python-rpm bindings makes yum relatively unlikely to break, at least for long, as Red Hat has a vested interest in making these binding work for their own products.

The bad news is that as rpm changes (fairly rapidly in recent releases) the bindings change and yum needs revision. Hence there are thus several versions of yum available for download at this time, each matching a quite recent revision of rpm and (not coincidentally) a release number of Red Hat Linux.

Fortunately, there is a short table of download links on the server above where you can find ready to install rpm's for yum built for each of the recent major linux releases. If you have difficulty picking, ask on the yum list for help or try using the tarball of yum sources to build the right version automagically. Or both!

Note Well: The yum rpm's you will download from this site have an /etc/yum.conf that is preconfigured to point to a public repository that supports yum, probably http://mirror.dulug.duke.edu. Naturally, if the entire Internet got yum and started updating clients from this site, at some point it would pretty much get hammered to where it no longer worked. DULUG is not google, and this is a single not-particularly powerful server, not a web farm. You may well want to look over the list of public yum repositories and edit /etc/yum.conf to use one of the alternatives, or (if you are a LAN manager with a publically accessible webserver) set up a repository of your own and add it to the list, following the instructions in this HOWTO!

Yum Tarball ³»·Á¹Þ±â

To set up a repository of your own to serve a private LAN or public WAN or both, you will need the yum tarball so that you can build your own yum rpm with its configuration files and %post installation instructions customized for your site (following the instructions given in the next couple of sections). If you are new to yum, you should likely start with the stable tarball, not the development tree, and join the yum list. You'll know when it is time to move up and start using the public CVS repository to get the latest tarball snapshot instead of using the stable tarball.

To get the stable tarball is simple. Just visit the yum website, http://www.linux.duke.edu/projects/yum, and download it. Then skip ahead to the sections on planning a repository and building a custom yum rpm.

À͸í CVS

As noted above, it is also possible to get yum directly from the CVS tree on the linux@duke repository. Most "normal humans" won't need or want to do this -- you are accessing the raw development tree, which might have cool new features or support a broader range of cutting edge distributions and releases, but which also might have bugs. Even immediately fatal bugs -- some snapshots you might grab will simply be pre-broken and need immediate replacement.

To use the CVS repository you don't quite need mad skills, but you do need to be familiar with and comfortable with the open source development process. Joining the yum mailing list is essential for example, and in fact if you are reading this in preparation for doing a CVS download I'm going to hope that you've been on the list already for a while, and are grabbing the CVS-based snapshot fully understanding that if it doesn't work you'll submit an immediate bug report and wait for (or help find) a solution, not scream because it "breaks" your production network.

It should almost never break your production network because anybody who participates in this sort of development cycle knows better than to immediately deploy such a snapshot without a fair bit of testing on clients and servers where if it turns out to be broken "it doesn't matter".

Don't let these dire-sounding warnings deter you, though. The entire operating system you are using (presuming that you are using Linux) was built by precisely this process, and many hands contributing a small bit of work, intelligently directed, can create incredibly powerful tools. Come on in, the water's fine! Especially if you have mad python skills and some clever ideas...;-)

To pull yum from cvs do the following:

cd ~
mkdir cvsroot
cd cvsroot
cvs -d :pserver:anonymous@devel.linux.duke.edu:/cvsroot/yum/cvs/\
  login
cvs -d :pserver:anonymous@devel.linux.duke.edu:/cvsroot/yum/cvs/\
  get yum

To update it once you've gotten it:

cd ~
cd cvsroot
cvs -d :pserver:anonymous@devel.linux.duke.edu:/cvsroot/yum/cvs/\
  upd yum 

{*Thanks to Russ Herrold for providing the above instructions*}

As noted above, it is strongly recommended that one become pretty thoroughly familiar with yum from using a stable release version and at least listening in on the yum list (which is mailman-managed and hence can easily be digested or throttled altogether) before tackling a CVS tree build. Knowing python is probably a good idea as well.

Once you have yum sources from either the stable tarball or the CVS tree, it is time to plan out your repository. This is detailed in the next section

5. Yum ÀúÀå¼Ò °èȹÇϱâ


½ÃÀÛÇϱâ Àü¿¡ ¿ë¾î¸¦ ¸î °³ Á¤ÀÇÇÏÀÚ. When we refer to a "server" below, let me remind you that we are referring to a piece of hardware. Beware! In e.g. "man yum.conf" a server is really a label for a repository, not a web, ftp or file server that might be one of several that provide mirrored access to the same repository. This is made clear later in the man page, where it is referenced in practice as serverid. A single physical "server" might well offer several repositories, each identified by a unique URL path on the server and by a unique serverid in /etc/yum.conf on the clients. Each serverid may similarly have several fallback URL's for the same repository (generally on different servers). This may initially be confusing, but it makes sense and provides for extremely robust operation.

As discussed in the Introduction, yum works by means of accessing a "yummified" repository -- a URL-accessible path where yum-arch has been run on the server to create a special directory with a known relative path displacement from the RPMS directory used to actually provide the downloads, into which all of the split-off headers are placed so they can be separately downloaded and cached on the client side.

Simple as this is (really!) there is a bit of work that should be expended planning out a yum repository, especially if you are starting from scratch and don't already have an rpm repository in place to which you are planning to "add yum support". It is probably wise to start simple and work up to a complex system of repositories and servers gradually and as need dictates (many sites will ONLY need a single monolithic server, maintained by a single wise administrator, with a single repository apiece for each distribution supported).

However, it never hurts to know a bit about what can be done in terms of repository design. To meet specific needs of the fairly wide variety of systems persons already using yum and participating in its active development, some fairly slick features have been added: the ability to operate from multiple servers and repositories in an overlaid/prioritized fashion with failover, for example.

In a small LAN this is total overkill. If one is using yum to support an entire University, however, where each department has its own "special, must have" packages or (a more common case) some rpm's that set up e.g. /etc with the appropriate configuration for just that department, the ability to specify multiple repositories on different servers that are checked in a particular order lets those departments manage just the rpm's they require that are department specific or otherwise customized.

This keeps the manager of the central/primary repository(s) sane, as that individual does not have to juggle lots of departmental configuration rpm's with names like physics-stuff-0.1.1.noarch.rpm, biology-stuff-0.1.1.noarch.rpm,... and keeps the central/primary server secure, as the departmental lan managers do not need any sort of trusted access to the primary server. This has nothing to do with whether or not these departmental managers are fundamentally "trusted" -- it is simply always a good idea to heavily restrict and regulate root-level access to a server the cracking of which de facto cracks an entire network! Putting rabid mastiffs outside the door to the server room isn't out of the question.

The following is an approximate (probably incomplete, as features are constantly being discussed on the yum list and added) list of some of the options and True Facts to consider when planning, building, or modifying a yum-based rpm repository (set):

  • Yum can currently work from either http (recommended) or ftp or nfs/file servers. All that is required is that the repository be accessible via a URL from the client(s) in question.
  • Yum is configured in /etc/yum.conf to automagically access a list of repositories...
  • Which are just URL's -- server paths to directories that contain rpms...
  • According to a policy that determines the order they are checked...
  • With failover, so rpms can be reliably delivered...
  • And optional GPG signature checking, so rpms can be securely delivered...
  • And control over architecture specificity, so one can load (e.g.) Athlon or i686 where it matters but i386 or noarch where it does not...
  • And control over distribution specificity, so one doesn't accidentally update in a way that breaks things silently.
  • In the True Facts category, since yum is designed to facilitate distributed maintenance (automated updates) of an rpm-based distribution of something -- operating systems, complete distribution, or even just a finite set of packages on some system installed and maintained with completely different tools -- the repository should be designed and built so that it remains up to date!

Some people won't need any of these bells and whistles. Start simple, yum's defaults are probably what you want anyway. Most people won't need more than one or two servers, perhaps a base distribution server (with primary repository images) plus an overlay server which might also mirror the primary repositories, used in a specified order, with GPG checking, for example. Some people, generally toplevel and local systems managers co-maintaining a repository network for a large organization, will use all of these features and even clamour for more on the yum list.

In the subsections below a strategy for planning out a yum repository/server set will be indicated that lets one smoothly move from a single server of a single repository (possibly originally mirrored from and updated from one of the existing distribution repositories) through to a really complex set of repositories on multiple servers that use all of the features.

5.1. ´ÜÀÏ ÀúÀå¼Ò (Rsync »ç¿ë)


To set up your first repository, it probably makes sense to clone a repository from an existing server. Yum works to support pretty much any kind of rpm-based repository for any of the major Linux distributions across several hardware architectures, as well as for other operating systems that either already support rpm package management or upon which the rpm toolkits and python can be built. Unfortunately, that makes giving detailed instructions for EVERY ONE of those possibilities impossibly complex. It is probably better to give an example and leave it up to you to figure out what you need to do to set up a "leaping frog linux" distribution repository or a repository for all of the rpm's required to do molecular dynamics off of a common set of tools and data on a small cluster.

Ordinarily as a very first step one would pick a server/repository to mirror. Be cautious. Some repositories are public and their servers have lots of capacity. Others may require permission to use. Some will support rsync, others will require wget or worse as retrieval agents. Usually the repository itself will tell you what its policy is with respect to mirroring (and of course won't let you in at all if it is truly restricted), but it never hurts to ask if there is any doubt.

Rsync is probably the tool of choice for mirroring and maintenance. It only downloads files if it needs to and is very smart and (one hopes) reasonably secure. So we'll use rsync in our examples below. However, not everybody sets it up on their servers. So what do you do if the repository you wish to mirror doesn't support rsync?

At least one possibility (there are probably others) is to use wget. wget is a common tool that can be used to get whole branches, recursively, from a website in order to create a locally rereferenced copy or a mirror. It is beyond the scope of this HOWTO to detail all the steps at this point; but the wget documentation is fairly clear. Basically, one simply substitutes the appropriate wget invocation, (recursive and to an adequate depth and probably with links rereferenced, with the possibly different source url) for rsync in the examples below

For specificity only, then, the following example describes one way to set up a repository that is a mirror of the rsync-enabled dulug (primary, tier1) Red Hat mirror, and we'll even more specifically restrict ourselves to version 9 i386 and pretend that yum is not already installed on the repository.

We start by trying:
rgb@lilith|T:121>rsync mirror.dulug.duke.edu::
mirror.dulug.duke.edu
 - This rsync server is currently available to any/all people.
 - This is subject to change with little or limited notice.
 - We may in the not-so-distant-future restrict rsync access
   to tier2 red hat mirrors.


Modules:

archive         Everything
redhat-ftp      Red Hat FTP Site
redhat-base     Red Hat FTP Site
redhat-beta     Red Hat Linux beta releases
redhat-rawhide  Rawhide FTP Site
redhat-updates  Updates FTP Site
redhat-contrib  Red Hat, Inc. -- Contrib FTP Site



archive         Main Tree
redhat-ftp      Red Hat FTP Site
redhat-base     Red Hat FTP Site
redhat-beta     Red Hat Linux beta releases
redhat-rawhide  Rawhide FTP Site
redhat-updates  Updates FTP Site
redhat-contrib  Red Hat, Inc. -- Contrib FTP Site
Oh, good. Anonymous rsync is supported on this repository, and the repository's policy says we can go ahead, at least for now, and mirror any repository to be found on this site ourselves. However, it also notes that quite possibly access to this mirror in the near future will be restricted to tier2 mirrors (basically sites that let other people mirror them and hence REDUCE the load on the tier1 sites) if load gets to be more than it can handle, so perhaps you (who read this) might consider using a mirror of one of the tier2 mirrors instead, unless you are hoping to set up a site that will be a tier2 mirror and publically available in turn.

Base Repository

After a little bit of monkeying around with rsync and/or a web browser, we find the path we're looking for to a suitable "base" Red Hat 9 tree that will constitute our repository. In actual fact we'd probably want to mirror one level up from here even for a "version 9 only" repository, as one level up we'd find e.g. documentation and iso images for the release which we'd almost certainly like to have handy even if yum itself points to a repository path one directory down. For the purposes of this example, however, we go to our (already set up) web or ftp server and create a suitably named path to our new repository.

This path should probably contain something that indicates distribution and revision it contains as part of its eventual URL; http://whatever.org/base is probably a bad choice, but http://whatever.org/RedHat9/base might be ok, or something much longer if you have lots of distributions or revisions or other repositories on the server.

After creating the path, enter the directory and enter (for example):
rgb@lucifer|T:27#rsync -avH
mirror.dulug.duke.edu::redhat-ftp/redhat/linux/9/en/os .
mirror.dulug.duke.edu
 - This rsync server is currently available to any/all people.
 - This is subject to change with little or limited notice.
 - We may in the not-so-distant-future restrict rsync access
   to tier2 red hat mirrors.


Modules:

archive         Everything
redhat-ftp      Red Hat FTP Site
redhat-base     Red Hat FTP Site
redhat-beta     Red Hat Linux beta releases
redhat-rawhide  Rawhide FTP Site
redhat-updates  Updates FTP Site
redhat-contrib  Red Hat, Inc. -- Contrib FTP Site



receiving file list ... done
os/
os/i386/
os/i386/RedHat/
os/i386/RELEASE-NOTES-it.html
os/i386/dosutils/
os/i386/dosutils/fips15c/
os/i386/dosutils/fips20/
os/i386/images/
os/i386/RELEASE-NOTES-ja.html
...
(for a few hundred directories packages and files more) and we're off to the races.

Depending on your bandwidth, you will have a brand, spanking new Red Hat 9 repository in minutes to hours (however long it takes to transfer a few GB of RPM's and support materials). Obviously, a nearly identical process would work for any other distribution that has rsync-enabled originals or mirror servers. Don't forget to consider buying SOMETHING from the original distribution provider (if they sell anything) to help them make some money from providing the tremendous value you are about to distribute at zero marginal cost across a whole network of systems!

Updates Repository

The next thing to worry about is keeping the new base repository itself up to date. There are two levels to even this -- one is rsync'ing the repository itself with the master on a periodic basis. This is accomplished with a simple cron script that changes to the appropriate directory and reruns the rsync command. rsync is smart enough to only download and replace files if they've changed. rsync can be run to either delete files that disappear from the master (remaining absolutely faithful to the master image) or to get new files and update changed ones but leave the old copies of ones that disappear. You have to decide which policy is right for your site, as both have risks.

You may want to quit there, and if the primary repository image already contains an "updates" path where updates automatically appear as bugs are fixed and security holes plugged, you may be able to. The repository just installed should support basic network installs (if the distribution does in the first place) and automated yum updates to the images in the repository once your clients are appropriately configured.

However, in many cases you will need to worry about keeping this base system correctly updated outside of the automatic updates provided by the distribution maintainer or vendor.

There are a couple of reasons for this. One is that not every distribution will handle updates the same way. Some distributions may be very aggressive and maintain updates that match and replace their distribution tree with a numbering/dating scheme that yum can understand and that changes rapidly as security, performance, and bug patches are released (Red Hat does). Others might replace files in their master distribution silently, after you've come to rely on a feature that suddenly goes away. Others might be lazy and not update their master distribution at all, or may have specialized tools for detecting and retrieving updates. Finally, even if your master distribution is very reliable and aggressively maintained, you may wish to override its offerings and update from a local copy of some of the rpm's, perhaps because they contain custom patches or local data.

One solution to these various dilemnas is to add an updates repository separate (different URL/path, recall, quite possibly on the same physical server). Here you can again choose to rsync to an updates server somewhere else, or you can create one all your own and split updates out of the distribution itself any way you like.

5.2. Ãß°¡ÀûÀÎ ÀúÀå¼Ò ¹× ¼­¹ö


In addition to a separate update repository, you may well want (eventually) to add still more repositories, and possibly more servers (viewing a repository, recall as a specific path to a single URL source of rpm's not necessarily on a distinct server). Perhaps you want to make a games rpm repository available to everybody on campus, but not on the main server which is owned by philistines that view games as a waste of time. Perhaps you want to overlay department rpm's on top of a base distribution repository (set, including updates) on a central server.

The outline above, and the example of the more or less required base repository, should be enough to enable you to set up arbitrary URL pathways to new repositories for whatever purpose you like. However, yum cannot use these repositories yet. First one has to install yum on the server(s) and run the yum-arch command on each repository. This causes the rpm headers to be extracted and paths to be dereferenced in a way that makes yum ultimately very fast and efficient.

Once this step is completed, yum then allows clients, via options in yum.conf on the various clients, to access the repositories and servers in whatever order they like (or more likely, in the order specified in the yum client rpm they automatically loaded at install time from one of those repositories).

6. YumÀ» À§ÇÑ FTP ¼­¹ö ¼³Á¤


FTP server¸¦ ¼³Á¤ÇÏ´Â °ÍÀº ¾ÆÁÖ ½±´Ù. ¼ø¼­´Â ´ÙÀ½°ú °°´Ù.:

  • RPM ³»·Á¹Þ±â
  • RPM ¼³Ä¡Çϱâ
  • .conf ÆÄÀÏ ÆíÁý
  • FTP ¼­¹ö ½ÃÀÛ
  • ¿¬°á ½ÃÇè

6.1. RPM ³»·Á¹Þ±â


¸®´ª½º¿¡¼­ »ç¿ë°¡´ÉÇÑ ftp°¡ ¸¹´Ù. ´ëºÎºÐÀÇ ¼­¹ö´Â ¶È°°Àº °ÍÀ» ÇϹǷΠ¼±ÅÃÀº ´ç½Å¿¡°Ô ´Þ·ÁÀÖ´Ù. ³»°¡ »ç¿ëÇϱâ ÁÁ¾ÆÇÏ´Â ftp ¼­¹ö´Â vsftpdÀÌ´Ù. The rpm is usually available from the installation discs or can be downloaded from [http]rpmfind or just use [http]google. vsftpd is used by many large companies as the ftp server of choice and is very secure (it's part of the name so it must be true, right?).

6.2. FTP ¼­¹ö ¼³Ä¡


VSFTPD°¡ ´ç½ÅÀÇ ±â°è¿¡ ÀÌ¹Ì ¼³Ä¡µÇ¾îÀÖ´ÂÁö º»´Ù. ÀÌ°ÍÀº ¾Æ·¡¿Í °°ÀÌ ½±°Ô ÇÒ ¼ö ÀÖ´Ù:
root@cartman> rpm -q vsftpd
The system will tell you if the server is installed or not. If you get this message 'package vsftpd is not installed' then you will need to install the ftp server.

First download the latest version of VSFTPD from your preferred mirror and save it to e.g. /tmp on the server. The ftp directory structure required for your repository is unlikely to exist yet so you will need to create the repository directories that you planned out above, for example:

root@cartman> mkdir -p /var/ftp/pub/9/updates/ 
(the -p flag tells mkdir to create the whole tree of directories as required).

To install/upgrade the ftp server run the following as root:
root@cartman>rpm -Uvh /tmp/vsftpd-1.1.3-8.i386.rpm
Note that one will want this rpm to be in a repository the server itself uses to yum update from in the long run. It is very likely to be in a primary distribution repository you mirror, but you may have to put it in a local/update repository you maintain yourself from some other source.

(You can of course use rpm -ivh vsftpd-1.1.3-8.i386.rpm to install the package if the package is not already installed. The flag -U is for upgrade and -i is for install. No big deal, they will both work if the package does not exist on your system, IMHO -U is just better practise. It is not a good idea to use rpm -i if a previous version of the package already exists on your system.)

6.3. vsftpd.conf ÆÄÀÏ ÆíÁý


After the ftp package has been installed you will need to edit the vsftp.conf file. This is usually found at /etc/vsftpd/vsftpd.conf. If it is not here then just run:
jdip@cartman>rpm -ql vsftpd
and look in the list where the .conf file is. To edit the .conf file you can use kate, gedit, vi or any other text editor. This is the configuration file for the ftp server. You will need to be root to change the file:
root@cartman>vi /etc/vftp/vsftp.conf
If your network is secure and behind a firewall then you can leave the following option in the .conf file. This option allows for anonymous ftp access to your server:
# Allow anonymous FTP? (Beware - allowed by default if you comment this out).
anonymous_enable=YES
You can also change the welcome message of the ftp server.
# You may fully customise the login banner string:
ftpd_banner=Welcome to yum FTP service.
If you want increased security for your ftp server then set the flag anonymous_enable=NO. This will force the user to log into the ftp server to get access to the packages. If you want to use this option then you will need to create a yum user on the server that can be used by the yum client to access the server. It is prudent to make users log into the ftp server, but if this is your private server then it may not be necessary.

Save the .conf file.

You will need to (re)start the service to activate the changes to the ftp server (see next section).

6.4. FTP ¼­¹ö ½ÃÀÛ


If you installed VSFTPD from the rpm then VSFTPD can be started as a service:
root@cartman>service vsftpd restart
You should get this message:
Shutting down vsftpd:                               [  OK  ] or [ FAILED ]
Starting vsftpd for vsftpd:                         [  OK  ]
You will want your ftp server to start every time you start Linux so it is also prudent to run:
root@cartman>chkconfig vsftpd on
root@cartman>chkconfig --list vsftpd
¾Æ·¡¿Í °°Àº ¸Þ½ÃÁö¸¦ º¸°Ô µÈ´Ù:
vsftpd          0:off   1:off   2:on    3:on    4:on    5:on    6:off
´ç½ÅÀÇ ftp server ´Â ÀÌ ±â°è¿¡¼­ ¸®´ª½º¸¦ ½ÃÀÛÇÒ ¶§¸¶´Ù ½ÃÀÛµÉ °ÍÀÌ´Ù. ftp server°¡ ¿Ã¶ó¿À°í ¿¬°áÀ» ±â´Ù¸®°í ÀÖ´Ù.

6.5. FTP ¼­¹ö ½ÃÇè


It is a good idea to test that the ftp server is working correctly. This is easily done by logging onto the ftp server:
jdip@cartman>ftp 127.0.0.1
Connected to 127.0.0.1 (127.0.0.1).
220 Welcome to yum FTP service.
Name (127.0.0.1:root): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
¸¸¾à¿¡ ls¶ó°í ÇÁ·ÒÇÁÆ®¿¡¼­ Ä£´Ù¸é 'pub' µð·ºÅ丮ÀÇ ³»¿ëÀÌ º¸ÀÏ °ÍÀÌ´Ù. º¸ÀÌ´Â °ÍÀº /var/ftp/pub ¾ÈÀÇ ³»¿ëÀÌ´Ù. ÀÌ °æ·Î(Áö±Ý ¼³Á¤µÈ ÀúÀå¼ÒÀÇ Àüü°æ·Î)´Â ¹Ì·¯»çÀÌÆ®¿¡¼­ rsync¸¦ »ç¿ëÇÏ¿© ºôµåÇÒ ¶§ Áß¿äÇÏ´Ù, for when you use yum-arch to "yummify" the repository (see below), and for setting up a local yum.conf for your local clients so that they can update from this ftp-based repository.

That is it. ftp ¼­¹ö°¡ µ¹¾Æ°¡°í ¿¬°áÀ» ±â´Ù¸®°í ÀÖ´Ù. Skip ahead to where it describes how to get and install yum and yummify the repository.

7. Yum ºôµåÇϱâ


Before proceeding further, we need to have yum itself handy, specifically the yum-arch command and its current documentation. If you are working from the rpm's, you've probably already installed them on your repository (I mean actually installed the program, not necessarily inserted the rpm's into a server on the repository) and one or two test clients. If not, please do, and skip ahead to the sections on installing yum or setting up a server with yum-arch and creating a suitable /etc/yum.conf.

However, if you get the sources via tarball or from the CVS repository, you will have to locally build yum. If you plan to repackage it (basically required if you are setting up a repository ) so that yum clients automatically use the yum-based repositories you set up in their /etc/yum.conf, you will need the tarball (yum-*.tgz) anyway.

The steps required to transform the provided tarball into an rpm are given below. Note that many of these steps are not yet fully documented in the source README or INSTALL files and are a major reason a HOWTO is sorely needed by the project. Most of yum's current systems manager users are already sufficiently expert to be able to build rpm's without additional instructions, but of course many who would like to use yum are not, and in any event it never hurts to document a moderately complicated process even for the experts.

Experts can also disagree. The steps below are ONE way of proceeding, but there are many others. Some managers will be working in monolithic (topdown) management models where they have root control of all clients and will prefer to push /etc/yum.conf out to the clients directly, not de facto pull it onto clients during an install from a repository where it is available, preconfigured for the site in rpm form. Tools exist to make this simple enough (cfengine, rsync, more).

Different people also have different ways of building rpms. Some always proceed as root, for example, using /usr/src/redhat (which exists for that purpose, after all). However, in my own mind working as root is something to be avoided as much as possible because of the risk of unintended consequences when one makes a mistake. Some of you reading this HOWTO may be very uncomfortable working as root for this very reason. I therefore provide step by step instructions on how to turn the yum tarball into an rpm as either a user or as root.

Naturally, the rpm will have to be installed as root either way

Or at least, I'll provide them later. For the moment, I'm all tapped out and have to go anyway. I may not even return to this project for a few days. Told ya' it was a work in progress....

7.1. Root·Î Yum RPM ¸¸µé±â


7.2. User·Î Yum RPM ¸¸µé±â


8. Yum ¼³Ä¡Çϱâ


Yum is installed (originally) more or less like any other rpm you add to an existing system. After downloading one of the rpm's above you simply:
rpm -Uvh yum.X.rpm
where X is, of course, the revision number you downloaded. Do this initially on the server(s) you wish to use as yum repositories and perhaps a single test client only. If this install fails, be sure that yum's dependencies are satisfied on your system. As of right now its dependency list reads something like:
rgb@lilith|T:167>rpm -qR yum
/bin/sh
/bin/sh
/bin/sh
/sbin/chkconfig
/sbin/service
/usr/bin/python
config(yum) = 1.97-20030522
python
rpm-python >= 4.2
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
on Red Hat 9. Version numbers will of course change, but this gives you an idea of what it will need in order to install. If you simply cannot get an install to work, try a different rpm or seek help from the yum list.

It is beyond the scope of this HOWTO to describe how to set up any of the servers that can be used as vehicles for a yum repository. Fortunately, documentation for setting up an FTP or HTTP server on a linux (or general Unix) server exists in abundance. Interested novices are referred to [http]The Linux Documentation Project website, where one can find HOWTO's (like this one), FAQ's, and outright books on doing nearly anything complex on a linux system. Your favorite technical bookstore is likely to have good books on at least the more important tools (such as apache).

For our purposes here, we will assume that you already have a functional HTTP or FTP server that you wish to make into a repository. It will need good bandwidth to all the clients you wish it to serve. It may need mechanisms to be in place to restrict access to the server to a local domain, or you may be comfortable permitting the server to be used by outsiders. It should be very strictly controlled in terms of access and security as it is an obvious target for crackers seeking to take over an entire network by slipping a malware rpm onto your repository for "automated update" to an entire network at once.

A double-barrelled shotgun behind the server room door, loaded with salt and tacks, is not out of the question.

With this given, we will now present instructions for setting up an rpm repository and preparing it so that yum clients can use it for all of their operations.

9. Yum¿¡ ÃÖÀûÈ­µÈ ¼­¹ö ±¸¼º: yum-arch


9.1. ºñ±â¼úÀûÀÎ ¼³¸í


±âº»ÀûÀ¸·Î yum-arch°¡ ÇÏ´Â ¸ðµç °ÍÀº µð·ºÅ丮¿¡ µé¾îÀÖ´Â rpmµéÀ» °£Ã߸®°í °¢°¢ÀÇ rpmÀ» À§ÇÑ Çì´õ¸¦ ¸¸µé¾î³»´Â °ÍÀÌ´Ù. ÀÌ ¸»Àº "¸Å¿ì °íÂ÷¿øÀû"À̸ç yum-arch ÇÁ·Î±×·¥ÀÇ Á߿伺À» °ÝÇϽÃų Àǵµ°¡ ¾Æ´Ï´Ù. yum-arch´Â YumÀÇ Ãʼ®ÀÌ´Ù. ÀÌ°ÍÀÌ ¾ø´Ù¸é rpmÀ» °í¼öÇÏ´Â °ÍÀÌ Â÷¶ó¸® ³´´Ù.

9.2. FTP ¼­¹ö¸¦ À§ÇÑ Çì´õ ¸¸µé±â


yum-arch¸¦ root·Î ½ÇÇàÇØ¾ß ÇÒ ÇÊ¿ä°¡ ÀÖÀ» °ÍÀÌ´Ù.

Á¤È®ÇÑ µð·ºÅ丮¿¡ Yum Çì´õ¸¦ »ý¼ºÇÏ´Â °ÍÀº Áß¿äÇÑ »çÇ×ÀÌ´Ù. ¸¸¾à ±×·¸°Ô ÇÏ°í ½Í´Ù¸é, ÀúÀå¼ÒÀÇ ½ÃÀÛ µð·ºÅ丮¿¡¼­ yum-arch¸¦ ½ÇÇàÇÏ¿© ¸ðµç rpm ÇØ´õµéÀ» Æ÷ÇÔÇÑ ÇϳªÀÇ Ä¿´Ù¶õ headers µð·ºÅ丮¸¦ »ý¼ºÇÒ ¼ö ÀÖ´Ù. ÇÏÁö¸¸ ²À ±×·¸°Ô ÇØ¾ß ÇÏ´Â °ÍÀº ¾Æ´Ï´Ù.

»ý¼ºµÈ headers µð·ºÅ丮´Â yum.conf ÆÄÀÏÀ» ÀÛ¼ºÇÏ´Â µ¥ À־ Á÷Á¢ÀûÀÎ ¿µÇâÀ» ³¢Ä¡¹Ç·Î ÁÖÀDZí°Ô °í·ÁÇØ¾ß ÇÑ´Ù. YumÀÌ (yum.conf¸¦ ÅëÇØ) headers µð·ºÅ丮¸¦ °¡¸®Å³ ¼ö ÀÖµµ·Ï ÇØ¾ß Çϴµ¥, ±×·¸Áö ¾ÊÀ¸¸é YumÀº headers¸¦ ãÁö ¸øÇÏ°í µû¶ó¼­ ÆÐÅ°Áöµéµµ ãÀ» ¼ö ¾ø°Ô µÈ´Ù.

µð·ºÅ丮 ±¸Á¶¸¦ ±ò²ûÇÏ°í Á¤È®ÇÏ°Ô ±¸¼ºÇÏ´Â °ÍÀ» È®½ÇÈ÷ Çصξî¾ß ÇÑ´Ù. ÀÌ°ÍÀº ¾î¶² ÀÏÀÌ À߸ø µÇ¾úÀ» ¶§ 󸮰¡ ½±µµ·Ï ÇØÁØ´Ù. »Ó¸¸ ¾Æ´Ï¶ó ¿ø°Ý ¼­¹ö µð·ºÅ丮 ±¸Á¶¸¦ º¹Á¦ÇßÀ» °æ¿ì ·ÎÄà ¹Ì·¯¸¦ rsyncÇϱ⠽±µµ·Ï ÇØÁØ´Ù.

/var/ftp/pub ³»ÀÇ ¿¹Á¦ Æ®¸®´Â ´ÙÀ½°ú °°À» ¼ö ÀÖ´Ù:
        /9/
          /base/
               /athlon
               /i386
               /i586
               /i686
          /freshrpms
          /fedora
          /kde/
              /3.1.2
              /3.1.3
          /rawhide
          /updates/
                  /athlon
                  /i386
                  /i586
                  /i686
µû¶ó¼­ ´ÙÀ½ ¸í·ÉÀ» ½ÇÇàÇϸé
root@cartman>yum-arch /var/ftp/pub/9
yum-arch´Â 'headers' µð·ºÅ丮¸¦ /var/ftp/pub/9 ¼Ó¿¡ »ý¼ºÇÒ °ÍÀÌ°í /9/ ¾Æ·¡ ÀüüÀÇ Æ®¸®¸¦ À§ÇÑ ¸ðµç Çì´õ ÆÄÀϵéÀ» ±× µð·ºÅ丮 ¼Ó¿¡ ´ã¾ÆµÑ °ÍÀÌ´Ù.

µð·ºÅ丮 ±¸Á¶´Â ´ÙÀ½°ú °°¾ÆÁú °ÍÀÌ´Ù:
        /9/
          /base/
               /athlon
               /i386
               /i586
               /i686
          /freshrpms
          /fedora
          /headers              # yum-arch°¡ ¿©±â¿¡ Çì´õµéÀ» »ý¼ºÇÔ.
          /kde/
              /3.1.2
              /3.1.3
          /rawhide
          /updates/
                  /athlon
                  /i386
                  /i586
                  /i686
ÀÌ°ÍÀº Á¦´ë·Î µ¿ÀÛÇÒ °ÍÀÌÁö¸¸ yum-arch¸¦ »ç¿ëÇÏ´Â °¡Àå ±ò²ûÇÑ ¹æ¹ýÀº ¾Æ´Ï´Ù. ¸ðµç Çì´õµéÀÌ ÇϳªÀÇ µð·ºÅ丮¿¡ ´ã°ÜÁ³À» ¶§, ±×·ì°ú °°Àº ¸î°¡Áö »õ·Î¿î ±â´É»óÀÇ ¹®Á¦µé ¶ÇÇÑ ¹ß»ýÇÑ´Ù.

µû¶ó¼­ ÇÑ°¡Áö ÇØ°áÃ¥Àº ÀúÀå¼Ò Æ®¸®³»ÀÇ °³º°ÀûÀÎ ºÎÀúÀå¼Ò¿¡¼­ yum-arch¸¦ ½ÇÇàÇÏ´Â °ÍÀÌ´Ù. ÀÌ°ÍÀÇ ¿¹Á¦´Â ´ÙÀ½°ú °°´Ù:
root@cartman>yum-arch /var/ftp/pub/9/base
root@cartman>yum-arch /var/ftp/pub/9/freshrpms
root@cartman>yum-arch /var/ftp/pub/9/fedora
               µîµî...
yum-arch°¡ ¸ðµç rpmµéÀ» °£Ã߸° ÈÄ¿¡´Â °¢°¢ÀÇ ºÎÀúÀå¼Ò¿¡ headers µð·ºÅ丮°¡ »ý±æ °ÍÀÌ°í µð·ºÅ丮 ±¸Á¶´Â ´ÙÀ½°ú °°°Ô µÈ´Ù:
        /9/
          /base/
               /athlon
               /headers
               /i386
               /i586
               /i686
          /freshrpms/
                    /headers
          /fedora/
                 /headers
          /kde/
              /3.1.2
              /3.1.3
              /headers
          /rawhide/
                  /headers
          /updates/
                  /athlon
                  /headers
                  /i386
                  /i586
                  /i686
ÀÌÁ¦ Çì´õµéÀ» ¼Õ¼ö »ý¼ºÇßÀ¸¹Ç·Î yumÀÇ »ç¿ë°³½Ã¸¦ À§ÇØ Å¬¶óÀ̾ðÆ®°¡ headers¸¦ °¡¸£Å°µµ·Ï yum.conf ÆÄÀÏÀ» °ü¸®ÇÒ ÇÊ¿ä°¡ ÀÖÀ» °ÍÀÌ´Ù.

9.3. °í±Þ ¸í·É¾î


yum-arch´Â Çì´õ¸¦ »ý¼ºÇÏ´Â ¹æ½Ä¿¡ ¿µÇâÀ» ÁÙ ¼ö ÀÖ´Â ´Ù¾çÇÑ ¿É¼ÇÀ» °¡Áö°í ÀÖ´Ù.
root@cartman>yum-arch [options] directory
Æ®¸®³»ÀÇ ÀÇÁ¸¼º ¹× Ãæµ¹À» üũ (-d)
root@cartman>yum-arch -d directory
ÀÌ ¸í·ÉÀº ÀúÀå¼Ò¿¡ ¼ö¸¹Àº rpmµéÀÌ ÀÖ´Â »óȲ¿¡¼­ ´ÜÁö °¡Àå ÃÖ±ÙÀÇ rpmµéÀ» À§ÇÑ Çì´õ¸¸À» »ý¼ºÇÏ°í ½ÍÀ» ¶§ ¸Å¿ì À¯¿ëÇÏ´Ù. yum-arch -d´Â ¸Å¿ì ÀåȲÇؼ­, yum-arch°¡ ÇÏ´Â ÀÏ¿¡ ´ëÇÑ ´Ù·®ÀÇ Á¤º¸¸¦ º¸¿©ÁØ´Ù. ¼ö¸¹Àº Ãæµ¹°ú ÀÇÁ¸¼ºÀÌ ÀÖÀ» ¼ö ÀÖÀ¸¹Ç·Î ÀÌ°ÍÀ» ÆÄÀÏ·Î Ãâ·ÂÇÏ´Â °ÍÀº ÁÁÀº »ý°¢ÀÌ µÉ ¼ö ÀÖ´Ù.

ÀÌ°ÍÀº Ãæµ¹ÀÇ ÇÑ ¿¹Á¦ÀÌ´Ù:
Checking deps 91 % complete warning: package samba-client = 3.0.0-5rc1 was already added, replacing with samba-client <= 3.0.0-5rc1
±×¸®°í ÀÌ°ÍÀº ÀÇÁ¸¼º ½ÇÆÐÀÇ ÇÑ ¿¹Á¦ÀÌ´Ù:
depcheck: package xmms-devel needs xmms = 1.2.7
ÀÌ·¯ÇÑ ¸Þ½ÃÁöµéÀº ¸Å¿ì À¯¿ëÇÏ¸ç ¹®Á¦Á¡µéÀÌ ÀúÀå¼ÒÀÇ ¾îµð¿¡¼­ ¹ß»ýÇÏ°í ÀÖ´Â Áö¸¦ ÁöÀûÇØ ÁØ´Ù. ¸¹Àº »ç¶÷µéÀÌ ÀÌ·¯ÇÑ ¸Þ½ÃÁöµéÀ» ¹«½ÃÇϴµ¥ ±×°ÍÀº ±×µéÀÇ ¼±ÅûçÇ×ÀÌ´Ù. ¸Þ½ÃÁöµéÀº ÀÌÀ¯°¡ Àֱ⠶§¹®¿¡ °Å±â¿¡ ÀÖ´Â °ÍÀÌ´Ù.

Ãæµ¹¿¡ ´ëÇÑ °¡´É¼º ÀÖ´Â ÇØ°áÃ¥

ÀÌ°ÍÀº ¸Å¿ì °£´ÜÇÏ´Ù. ÀúÀå¼Ò¿¡¼­ °¡Àå ¿À·¡µÈ rpmµéÀ» Áö¿ö¶ó. ÀÌ°ÍÀº (¾Õ¼­ ¸»ÇßµíÀÌ) rsync¸¦ »ç¿ëÇÏ¿© ÇàÇØÁ®¾ß ÇÑ´Ù. ¿ø°Ý ¹Ì·¯¸¦ ·ÎÄ÷Πº¹Á¦ÇϱâÀ§ÇØ »ç¿ëÇÏ´Â rsync´Â ¿ø°Ý ¼­¹ö¿¡ Á¸ÀçÇÏÁö ¾Ê´Â ·ÎÄà ÆÄÀϵéÀ» »èÁ¦Çϵµ·Ï ¼³Á¤ÇÒ ¼ö ÀÖ´Ù.

ÀÇÁ¸¼º ¹®Á¦¿¡ ´ëÇÑ °¡´É¼º ÀÖ´Â ÇØ°áÃ¥

ÀÌ°ÍÀº °£´ÜÇÒ ¼öµµ ±×·¸Áö ¾ÊÀ» ¼öµµ ÀÖ´Ù.

¸¸¾à ¹Ì·¯ÁßÀÎ ¾î¶°ÇÑ ÀúÀå¼Ò¿¡µµ ¾ø´Â ÆÐÅ°Áö¿¡ ´ëÇÑ ¿ä±¸·Î ÀÇÁ¸¼º ¹®Á¦°¡ ¹ß»ýÇß´Ù¸é, rpmfind¿¡¼­ ±× ÆÐÅ°Áö¸¦ ã°Å³ª ȤÀº (ÆÐÅ°Áö¸¦ À§ÇÑ ¼Ò½ºµéÀ̳ª µ¥ÀÌÅÍ°¡ ÀÖ´Ù¸é) Á÷Á¢ rpmÀ» Á¦ÀÛÇØ¾ß ÇÑ´Ù. rpm Á¦ÀÛÀº ¾Æ·¡¿¡ ¼Ò°³µÇ¾î ÀÖ´Ù.

°æ°í ÇÑ ¸¶µð: (¸¸¾à ¿Ïº®ÇÑ ¹Ì·¯¸¦ À¯ÁöÇϱâ À§ÇØ --delete ¿É¼ÇÀ» »ç¿ëÇÑ´Ù¸é) ¹Ì·¯¿¡ ¾ø´Â ¾î¶°ÇÑ ÆÐÅ°Áöµéµµ rsync¿¡ ÀÇÇØ ·ÎÄà ÀúÀå¼Ò¿¡¼­ »èÁ¦µÉ ¼ö ÀÖÀ¸¹Ç·Î ÀÌ·¯ÇÑ »çÀÌÆ®-·ÎÄà ÆÐÅ°ÁöµéÀ» "µû·Î" ÀúÀå¼Ò¿¡ º¸°üÇØµÑ ÇÊ¿ä°¡ ÀÖ´Ù. ºÐ¸íÈ÷ °æ°íÇß´Ù.

¸¸¾à ÀÇÁ¸¼º ¹®Á¦°¡ ´õ º¹ÀâÇÏ´Ù¸é (Á¦ÀÛÀÚµéÀÌ À̸§/¹öÀüºÙÀ̱⠱ÔÄ¢À» ´Ù¸£°Ô »ç¿ëÇÏ´Â ¼­·Î ´Ù¸¥ ÀúÀå¼Ò·Î ºÎÅÍ ¿Â µÎ°³ ȤÀº ±× ÀÌ»óÀÇ ÆÐÅ°ÁöµéÀ» »ç¿ëÇϰųª, ´ëºÎºÐÀÇ ÀÀ¿ëÇÁ·Î±×·¥µéÀÌ ÃÖ±ÙÀÇ ¶óÀ̺귯¸®¸¦ ¿ä±¸Çϴµ¥ ¿À·¡µÈ ¹öÀüÀÇ ¶óÀ̺귯¸®¸¦ ¿ä±¸ÇÏ´Â µ¶ÀÚÀûÀΠȤÀº ºñ°ø°³¼Ò½ºÀÇ ÆÐÅ°ÁöÀÎ "legacy"¸¦ »ç¿ëÇÑ´Ù¸é ¹®Á¦°¡ ¸Å¿ì º¹ÀâÇØÁú ¼ö ÀÖ´Ù. ±×·¸´Ù¸é) ±× ¹®Á¦µéÀ» ÇØ°áÇϱâ À§ÇØ ÈξÀ ´õ ¿­½ÉÈ÷ ÀÛ¾÷À» Çؾ߸¸ ÇÒ °ÍÀÌ´Ù. ½ÇÁ¦·Î, ¾î¶² °æ¿ì¿¡´Â ¼Ó¼ö¹«Ã¥ÀÏ ¼öµµ ÀÖ´Ù. -- Áß¿äÇÑ ÀÓ¹«¼öÇàÀ» ÇÏ´Â ÀÀ¿ëÇÁ·Î±×·¥µé ÁßÀÇ Çϳª°¡ ƯÁ¤ÇÑ ¹èÆ÷º» ¹× ±×°ÍÀÇ ¹ÙÀ̳ʸ®µé¿¡ ¾ôÈù libc³ª ±âŸ ¶óÀ̺귯¸®¸¦ ¿ä±¸ÇÑ´Ù´Â ÀÌÀ¯·Î ¼¼»ó¿¡´Â "½Ã´ë¿¡ µÚÁø" linux ¹èÆ÷º»À» ±¸µ¿ÇÏ´Â ¼ö¸¹Àº »çÀÌÆ®µéÀÌ ÀÖ´Ù.

¿îÁÁ°Ôµµ, ¸¶Ä¡ YumÀÌ ¼Õ½¬¿î ¾÷±×·¹À̵带 ÇØÁÖ´Â °Íó·³ (±×·¸´Ù¸é ¿Ö º¹ÀâÇÑ ÀúÀå¼Ò Æ®¸®°¡ ÇÊ¿äÇÑ°¡?) º¹ÀâÇÑ ÀúÀå¼Ò Æ®¸®¸¦ ½±°Ô °ü¸®ÇÒ ¼ö ÀÖµµ·Ï ÇØÁֹǷÎ, ÃÖ¾ÇÀÇ °æ¿ì ±× ÇØ°áÃ¥Àº Ãæµ¹ÇÏÁö ¾Ê´Â ¹èÆ÷º»¿¡ ´ëÇÑ ÀúÀå¼Ò Æ®¸®¸¦ µû·Î À¯ÁöÇÏ´Â °ÍÀÌ´Ù. ¹°·Ð, ÀÌ°ÍÀº ÁÁÁö´Â ¾ÊÁö¸¸, °ø°³ ¼Ò½º ¼¼°è¿¡¼­´Â (ȤÀº °°Àº ¹®Á¦·Î ºñ°ø°³ ¼Ò½ºÀÇ ¼¼°è¿¡¼­µµ) °øÅëÀÇ ±ÔÄ¢µéÀ» ÁؼöÇÏ´Â Áß¿ä ÆÐÅ°ÁöÀÇ Á¦ÀÛÀÚ¸¦ ÁöÁ¤ÇÒ ¼ö ¾ø°í, ´ÜÁö ±×µéÀÌ ±× ÀÏÀ» ÇØ Áֱ⸦ ¹Ù¶ó¸ç ±×·¸Áö ¸øÇÒ ¶§´Â ±×°ÍÀ» ó¸®ÇØ Áֱ⸦ ¹Ù¶ö »ÓÀÌ´Ù.

Ãâ·ÂÀ» ÀåȲÇÏ°Ô ¸¸µé±â (-v ¿Í -vv)
root@cartman>yum-arch -v directory
ÀÌ ¸í·É¾î´Â yum-arch °¡ ´ç½ÅÀÇ ÀúÀå¼Ò¿¡ ÀÖ´Â ¸ðµç ÆÐÅ°Áöµé°ú ÇÔ²² ¹«¾úÀ» ÇÏ´ÂÁö º¼¼ö ÀÖ°Ô Çϴµ¥ ¸Å¿ì À¯¿ëÇÏ´Ù. ¸¹Àº ¾çÀÇ Á¤º¸°¡ ¸¸µé¾îÁö±â ¶§¹®¿¡ ´ç½ÅÀº ±×°ÍÀ» ÀÌ¿ëÇϱâ À§ÇØ ±× Á¤º¸¸¦ ÆÄÀÏ·Î Ãâ·ÂÇϱ⸦ ¹Ù¶ö°ÍÀÌ´Ù. ¿©±â ÀåȲÇÑ Ãâ·ÂÀÇ ¿¹°¡ ÀÖ´Ù.:
ignoring older pkg: redhat/9/i386/openssh-askpass-gnome-3.5p1-6.9.i386.rpm
Digesting rpm - openssh-askpass-3.5p1-6.9.i386.rpm - 95/3202
Already found tuple: openssh-askpass i386

ignoring older pkg: redhat/9/i386/openssh-askpass-3.5p1-6.9.i386.rpm
Digesting rpm - openssh-3.5p1-6.9.i386.rpm - 96/3202
Already found tuple: openssh i386

ignoring older pkg: redhat/9/i386/openssh-3.5p1-6.9.i386.rpm
Digesting rpm - openssl096-0.9.6-17.i386.rpm - 97/3202
Digesting rpm - openssl-0.9.7a-5.i386.rpm - 98/3202
Digesting rpm - pam_smb-1.1.6-9.9.i386.rpm - 99/3202
Digesting rpm - php-4.2.2-17.2.i386.rpm - 100/3202
Digesting rpm - php-devel-4.2.2-17.2.i386.rpm - 101/3202
Digesting rpm - php-imap-4.2.2-17.2.i386.rpm - 102/3202
Digesting rpm - php-ldap-4.2.2-17.2.i386.rpm - 103/3202
Digesting rpm - php-manual-4.2.2-17.2.i386.rpm - 104/3202
¾ó¸¶³ª ´õ ¸¹Àº Á¤º¸°¡ ÇÊ¿äÇÑ°¡? ÀÏ´Ü yum-arch°¡ Á¦´ë·Î µ¿ÀÛÇÏ°í Á¤È®ÇÑ Çì´õ¸¦ »ý¼ºÇس½ °Í¿¡ ¸¸Á·ÇÑ´Ù¸é Ãâ·ÂÀÌ ´õ ÀåȲÇÒ ÇÊ¿ä´Â ¾ø´Ù. yum-arch´Â º¸Åë cronÀ¸·Î ½ÇÇàµÇ¹Ç·Î ½ÇÁ¦·Î ±× Ãâ·Â¿¡ ´ëÇØ Àß ¾ËÁö ¸øÇÑ´Ù. Ãâ·ÂÀÌ Á¸ÀçÇÏ¸ç °ú°Å¿¡ ¸î¸î ÀÌ»óµéÀ» Àß ¼³¸íÇØÁÖ¾ú´Ù´Â »ç½ÇÀ» ¾Æ´Â °Í¸¸À¸·Îµµ ÁÁ´Ù.

Çì´õ¸¦ »ý¼ºÇÏÁö ¾Ê±â (-n)
root@cartman>yum-arch -n directory
ÀÇÁ¸¼ºÀ» üũÇÒ ¶§, ½ÇÁ¦·Î Çì´õ¸¦ »ý¼ºÇÏ°í ½ÍÁö ¾ÊÀ» ¼öµµ ÀÖ´Ù. Á¤¸»·Î Áß´ëÇÑ Ãæµ¹¹®Á¦°¡ Á¸ÀçÇÑ´Ù¸é Çì´õ ÁýÇÕÀÌ "¸Á°¡Áú" ⱸ¸¦ Á¦°øÇÏ°í ½ÍÁö´Â ¾ÊÀ» °ÍÀÌ°í, ´Ù¸¸ ¸· »õ ÆÐÅ°Áö¸¦ Ãß°¡ÇßÀ» ¶§ ±×°ÍÀÌ Ãæµ¹À» ÀÏÀ¸Å°´ÂÁö ¿©ºÎ¸¸ ¾Ë°í ½ÍÀ» °ÍÀÌ´Ù. -n ¿É¼ÇÀº Çì´õÀÇ ÀÚµ¿ »ý¼ºÀ» ¾ïÁ¦Çϵµ·Ï ÇØÁØ´Ù.

Ãâ·ÂÀ» ´õ ÀáÀáÇÏ°Ô Çϱâ (-q)
root@cartman>yum-arch -q directory
½¬ÀÌÀÌÀÕ.

-q ¿É¼ÇÀº yum-arch°¡ »ý¼ºÇÏ´Â Á¤º¸ÀÇ ¾çÀ» Á¤¸»·Î ÁÙÀ̱â´Â ÇÏÁö¸¸ ±×·¸´Ù°í yum-arch°¡ Àý´ëÀûÀ¸·Î Á¶¿ëÇØÁöÁö´Â ¾Ê´Â´Ù. È­¸é¿¡ Ãæµ¹¿©ºÎ³ª °£Ã߸° ÆÐÅ°ÁöµéÀÌ ³ªÅ¸³¯ °ÍÀÌ´Ù. ÀÏ´Ü yum-arch°¡ ¿øÇÏ´Â ÀÏÀ» ¼öÇàÇس´ٴ »ç½Ç¿¡ ¸¸Á·ÇÑ´Ù¸é (Áï, ´ÙÀ½¹ø¿¡ ½ÇÇàÇÒ ¶§´Â) yum-arch¸¦ ¸ÅÀÏ ½ÇÇàµÇ´Â cron ÀÛ¾÷À¸·Î ¸¸µé °ÍÀÌ´Ù. yum-arch°¡ Çì´õ¸¦ »ý¼ºÇÏ°í ´ÜÁö °æ°íµé¸¸ ¾Ë·ÁÁÖ´Â Á¤µµ·Î »ç¿ëÇÒ ¶§ -q ¿É¼ÇÀº ÃÖ»óÀÇ Ç÷¡±×ÀÌ´Ù.

gpg¿Í md5·Î ÆÐÅ°Áö °Ë»çÇϱâ (-c), -n°ú´Â (¸í¹éÈ÷) ÇÔ²² ¾µ ¼ö ¾øÀ½
root@cartman>yum-arch -c directory
Èì... ÀÌ ¸í·ÉÀ¸·Î´Â È¥¶õ¸¸ °¡Áß½Ãų »ÓÀÌ´Ù. °£È¤ »ç¿ëÇϱâ´Â ÇÏÁö¸¸ ¸ðµç ÆÐÅ°Áö°¡ MD5 üũ¼¶À» °¡Áö°í Àִٰųª gpg ¼­¸íÀ» °¡Áö°í ÀÖ´Â °ÍÀº ¾Æ´Ï´Ù. ¸¸¾à º¸¾È¿¡ ¹Î°¨ÇÏ¸ç ³»·Á¹ÞÀº ÆÐÅ°Áö¿¡ ´ëÇÑ È®½ÅÀ» °®°í ÀÖÁö ¾Ê´Ù¸é ±×¶§ ÀÌ ¿É¼ÇÀ» »ç¿ëÇ϶ó.

{ÀÌ Ç÷¡±×°¡ ³»°Õ µ¿ÀÛÇÏÁö ¾Ê¾ÒÀ½ -- jp}

gzipÀ¸·Î Çì´õ¸¦ ¾ÐÃàÇϱâ (-z)
root@cartman>yum-arch -z directory
....

½Éº¼¸¯¸µÅ©¸¦ ó¸®Çϱâ (±âº»°ªÀº ½Éº¼¸¯¸µÅ© ¹«½Ã) (-l)
root@cartman>yum-arch -l directory
.....

...Á¤¸»·Î ÇؾßÇÒ ²À ÇÊ¿äÇÑ °Í
root@cartman>yum-arch directory
ÀúÀå¼Ò¸¦ À§ÇÑ Çì´õ¸¦ »ý¼ºÇϱâ À§ÇØ yum-arch¸¦ »ç¿ëÇÒ ¶§, yum-arch´Â Ç×»ó È­¸é º¸°íÀÇ ¸Ç ³¡¿¡ ´ÙÀ½°ú °°Àº µÎ ÁÙÀ» Ãâ·ÂÇÑ´Ù. (-q´Â Á¦¿Ü):
   Total: 3202                  #Total packages read
   Used: 1521                   #Total headers created
ÀÌ°ÍÀÌ ¹Ù·Î Á¤¸»·Î ¾Ë¾Æ¾ß ÇÒ ¸ðµç °ÍÀÌ´Ù. ÀÌ µÎ ÁÙÀÌ ¹«¾ùÀ» ¸»ÇØÁÖ´Â °ÍÀϱî? ¿ì¼± ÆÐÅ°ÁöÀÇ ¹Ý ÀÌ»óÀÌ Çì´õ°¡ »ý¼ºµÇÁö ¾Ê¾ÒÀ¸¹Ç·Î ÀúÀå¼Ò¸¦ Á¤¸®ÇÒ ÇÊ¿ä°¡ ÀÖ´Ù. ÀÌ°ÍÀº º¸Åë ¸î¸î ÆÐÅ°Áö°¡ ÀúÀå¼Ò¿¡¼­ Áߺ¹µÇ¾ú°Å³ª Ãæµ¹Çϱ⠶§¹®¿¡ ±âÀÎÇÑ´Ù. ¾Æ¸¶µµ ÀúÀå¼Ò¿¡ rawhide ÆÐÅ°ÁöµéÀÌ Àֱ⠶§¹®¿¡ ¹ß»ýÇÏ´Â °ÍÀÌ´Ù. ÃÖ½Å½Ä ±×°ÍÀÌ ¿øÀÎÀÌ´Ù.

10. Yum Ŭ¶óÀ̾ðÆ® ¼³Á¤


10.1. /etc/yum.conf


yum.conf ÆÄÀÏ¿¡´Â µÎ ºÎºÐÀÇ ¼½¼ÇÀÌ Á¸ÀçÇÑ´Ù.: main °ú server ÀÌ´Ù. mainÀº ¸ðµç Àüü¼³Á¤ ¿É¼ÇÀ» Á¤ÀÇÇÑ´Ù. server ¼½¼Ç(µé)Àº °¢°¢ÀÇ ¼­¹ö¿¡ ´ëÇؼ­ Á¤ÀÇÇÑ´Ù.

yumÀÌ ¾î¶² µ¿ÀÛÀ» Çϱâ À§Çؼ­´Â main ¼½¼ÇÀÌ ¹Ýµå½Ã ÀÖ¾î¾ßÇÑ´Ù. ¾Æ·¡ º¸ÀÌ´Â °ÍÀÌ ÀϹÝÀûÀÎ main ¼¼¼ÇÀÇ ÇüÅÂÀÌ´Ù.:
[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=redhat-release
Here is the meaning of the various options (straight from "man yum.conf", in case you haven't read this yet). All options are of the form:

option=value

Note that most of the options can be left at the default and yum will function just fine.

  • cachedir: Directory where yum should store its cache and db files.
  • debuglevel: debug level. valid numbers are 0-10. default is 2.
  • errorlevel: another debug level. valid numbers are 0-2. default is 2.
  • logfile: full directory and file name for where yum should write its log file.
  • assumeyes: 1 or 0 - tells yum whether or not to prompt you for confirmation of actions. Same as -y on the command line. Default to 0.
  • tolerant: 1 or 0 - Tells yum to be tolerant of errors on the command line with regard to packages. For example: if you request to install foo, bar and baz and baz is installed; yum won't error out complaining that baz is already installed. same as -t on the command line. Default to 0(not tolerant)
  • pkgpolicy: newest or last - Package sorting order. When a package is available from multiple servers, newest will install the most recent version of the package found. last will sort the servers alphabetically by serverid and install the version of the package found on the last server in the resulting list. If you don't understand the above then you're best left not including this option at all and letting the default (newest) occur.
  • exclude: list of packages to exclude from updates or installs. This should be a space separated list. Filename globs *,?,., etc are allowed.
  • exactarch: 1 or 0 - set to 1 to make yum update only update the architectures of packages that you have installed. i.e.-- with this enabled yum will not install an i686 package to update an i386 package.
  • commands: list of functional commands to run if no functional commands are specified on the command line. i.e: commands = update foo bar baz quux none of the short options (-y, -e, -d, etc) will be taken in the field.
  • distroverpkg: package to use to determine the "version" of the distribution - can be any package you have installed - defaults to redhat-release.
  • diskspacecheck: set this to 0 to disable the checking for sufficient diskspace before the rpm transaction is run. default is 1 (to perform the check)
  • retries: Set the number of times any attempt to retrieve a file should retry before returning an error. Setting this to 0 makes it try forever. Default to 3.
  • kernelpkgnames: list of package names that are kernels - this is really only here for the kernel updating portion - this should be removed out in 2.1 series.
  • installonlypkgs: list of packages that should only ever be installed, never updated - kernels in particular fall into this category. Defaults to kernel, kernel-smp, kernel-bigmem, kernel-enterprise, kernel-debug, kernel-unsupported.

In addition, there must be at least one server section. Note well that "server" here does not refer to a single physical machine, nor does it necessarily refer to a single repository, a server id (this is made clear in the man page for yum.conf). As such it is an arbitrary but unique label attached to a set of (usually identical/mirrored) repositories that will in general be on different physical machines to provide a measure of fallback robustness in operation.

Note well that yum creates cache directories according to the label in the server tag. If the fallback repositories are not in fact mirrors and consistent with the primary repository, odd things can be expected to occur that are very likely not going to be what you intended to happen.

Server sections inherit global options from main, but also have options of their own. Consider the following example:
[duke-base]
name=Linux@Home $releasever - $basearch - Base
baseurl=http://192.168.1.2/dulug/$releasever/$basearch/
        http://install.dulug.duke.edu/pub/dulug/base/$releasever/$basearch
gpgcheck=0

[duke-distrib]
name=Linux@Home Distributable add-on packages - $releasever $basearch
baseurl=http://192.168.1.2/dulug/$releasever/$basearch-distrib/
        http://install.dulug.duke.edu/pub/dulug/add-on/distrib/$releasever/$basearch
gpgcheck=0

[duke-nondistrib]
name=Linux@Home Nondistributable add-on packages - $releasever $basearch
baseurl=http://192.168.1.2/dulug/$releasever/$basearch-duke/
        install.dulug.duke.edu/pub/dulug/add-on/duke/$releasever/$basearch
        http://localhost:33333/pub/dulug/add-on/duke/$releasever/$basearchgpgcheck=0
gpgcheck=0

[home]
name=Linux@Home personal add-on packages - $releasever $basearch
baseurl=http://192.168.1.2/dulug/$releasever/$basearch-local/
gpgcheck=0

[ayo]
name=freshrpms
baseurl=http://ayo.freshrpms.net/redhat/9/i386/freshrpms/
gpgcheck=0
This example illustrates much of the power of yum. There are five distinct repositories indicated. The first, duke-base, is linux@duke's Red Hat 9 public repository. However, I use yum at home to keep my LAN up to date through a low-bandwidth DSL link. I have some ten computers that update nightly and don't want to have to move headers and rpm's through the link for each one. So I maintain a full mirror via rsync of this repository, and use it by preference rather than the repository at Duke.

Duke has two more collections of packages it provides in different repositories. One is open source/free add-ons to the base Red Hat distribution. This repository is open to the public, but less likely to be of use to people who aren't associated with Duke. I use some packages from this repository and so include in yum.conf, again first from a local mirror in my home LAN and from Duke through the DSL link only as a fallback.

The second repository contains packages that for one reason or another cannot be openly distributed. There are proprietary, site-licensed packages there, or packages with private data, for example. Although as a Duke faculty person I'm entitled to use these packages at home, only duke.edu addresses can access the repository. However, I connect via an ISP.

The duke-nondistrib entry thus tries to update from the home mirror (which I have to rsync via an ssh forwarded port). If this doesn't work it tries to access it directly (which might succeed on e.g. my laptop, if I've brought it into Duke). Finally, if neither of these work it tries localhost:33333, hoping that I've hotwired an ssh port forward at that address in case my laptop is not at home or at Duke, but I suddenly need access while I'm on the road.

The home entry is where I put those rpm's I build at home strictly for local/home distribution. This is surprisingly useful -- a good way to move around certain configuration files, for example, and there are a few packages I find to install that aren't maintained at Duke at all.

The ayo entry is a public rpm repository that contains one or two libraries that I need that aren't at Duke and that I don't want to build locally.

As one can see, yum can be amazingly powerful and flexible in the way that it is configured to use repositories (and their fallback mirros) in layers, each layer providing a different set of packages. Most yum clients will need a much simpler yum.conf than this -- in many cases one with a single server entry. However, systems managers who wish to install packages in layers from a common public repository and one or more private repositories will find that yum is designed to accomplish this in the most natural manner possible.

10.2. /etc/cron.daily/yum.cron


10.3. /var/cache/yum


10.4. ¼³Á¤ ¹èÆ÷Çϱâ


yum RPMÀ» °ðÀå ÀÛµ¿°¡´ÉÇÏ°Ô ¸®ºôµåÇϱâ

Push tools

11. Yum Ŭ¶óÀ̾ðÆ® »ç¿ëÇϱâ


yumÀ» À§ÇÑ ÇöÇà ¸í·É¾î À϶÷Àº ´ÙÀ½°ú °°´Ù.:
    »ç¿ë¹ý:  yum [¿É¼Ç] <update | upgrade | install | info | remove | list |
            clean | provides | search | check-update | groupinstall | groupupdate |
            grouplist >
                
         ¿É¼Ç:
          -c [¼³Á¤ ÆÄÀÏ] - »ç¿ëÇÒ ¼³Á¤ ÆÄÀÏ ÁöÁ¤
          -e [¿À·ù ¼öÁØ] - ¿À·ù ±â·Ï ¼öÁØ ¼³Á¤
          -d [µð¹ö±× ¼öÁØ] - µð¹ö±× ¼öÁØ ¼³Á¤
          -y ¸ðµç Áú¹®¿¡ yes·Î ÀÀ´ä
          -t ÆÐÅ°Áö ¸í·É¿¡ °üÇÑ ¿À·ù´Â ¿ëÀÎ
          -R [ºÐ ´ÜÀ§ÀÇ ½Ã°£] - ¹«ÀÛÀ§·Î ½ÇÇàµÇ´Â ÃÖ´ë ½Ã°£ ¼³Á¤
          -C ij½Ã¿¡ ´ëÇؼ­¸¸ ½ÇÇà - ij½Ã¸¦ °»½ÅÇÏÁö ¾ÊÀ½
          --installroot=[°æ·Î] - ¼³Ä¡ ·çÆ® À§Ä¡¸¦ ¼³Á¤ (±âº»°ªÀº '/')
          --version - yumÀÇ ¹öÀüÀ» Ãâ·Â
          -h, --help ÀÌ È­¸é

(¹öÀü 2.0.4¿¡ ÇÑÇÔ).

11.1. ·çÆ® ±ÇÇÑÀÌ ÇÊ¿äÇÑ Yum ¸í·É¾î


´ÙÀ½ÀÇ ¸í·ÉµéÀº ÆÄÀϵéÀ» ¼³Ä¡, °»½Å ¹× »èÁ¦ÇÔÀ¸·Î½á ÆÄÀϽýºÅÛÀ» º¯°æÇÑ´Ù. óÀ½À¸·Î yumÀ» ½ÇÇàÇϸé, /etc/yum.conf¿¡ ÁöÁ¤ÇÑ Àå¼Ò·Î ¸ðµç Çì´õ ÆÄÀϵéÀ» ³»·Á¹Þ°í ij½ÃÇϴµ¥, ÀÌ°Í ¶ÇÇÑ ·çÆ® ±ÇÇÑÀ» ¿ä±¸ÇÑ´Ù. ±× ÈÄ¿¡´Â Ưº°ÇÑ ±ÇÇÑÀÌ ÇÊ¿ä¾ø´Â ¸í·ÉµéÀº ¸ðµç »ç¿ëÀÚ°¡ ÀϹÝÀûÀ¸·Î µ¿ÀÛ½Ãų ¼ö ÀÖÁö¸¸, ¾Æ·¡¿¡ ³ª¿­ÇÑ ¸í·ÉµéÀº ¿ÀÁ÷ ·çÆ®·Î¸¸ µ¿ÀÛÇÒ °ÍÀÌ´Ù.

YumÀ¸·Î ÆÐÅ°Áö ¼³Ä¡Çϱâ
  # yum install ÆÐÅ°Áö1 [ÆÐÅ°Áö2 ÆÐÅ°Áö3...]
YumÀº ÆÐÅ°Áö1ÀÌ ÀÌ¹Ì ¼³Ä¡µÇ¾î ÀÖ°í ÃֽŠ¹öÀüÀÎÁö üũÇÒ °ÍÀÌ´Ù. ¸¸¾à ±×·¸Áö ¾Ê´Ù¸é, ÆÐÅ°Áö1{±×¸®°í ¸ðµç ÀÇÁ¸°ü°è¿¡ ÀÖ´Â ÆÐÅ°Áöµé}À» (ij½Ã µð·ºÅ丮¿¡ ÀúÀåÇϸ鼭) ³»·Á¹Þ°í ¼³Ä¡ÇÑ´Ù. Ãß°¡ÀûÀ¸·Î ¼³Ä¡ÇÒ ÆÐÅ°ÁöµéÀº °°Àº ¸í·ÉÁÙ¿¡ ³ª¿­ÇÏ¸é µÈ´Ù. ÆÐÅ°Áö À̸§Àº Ç¥ÁØ ÆÄÀϽýºÅÛ globÀ¸·Î ÁöÁ¤ÇÒ ¼öµµ ÀÖ´Ù. ¸î°¡Áö ¿¹¸¦ µé¸é:
  # yum install jpilot
ÀÌ°ÍÀº jpilot ÆÐÅ°Áö(ÆÊ ÆÄÀÏ·µÀ» À§ÇÑ ¸Å·ÂÀûÀÎ ÀÎÅÍÆäÀ̽º¸¦ Á¦°øÇÏ´Â µµ±¸)¸¦ Ž»öÇÏ¿© ÀÌ ÆÐÅ°Áö°¡ Á¸ÀçÇÏ´Â yum ÀúÀå¼Ò°¡ Çϳª¶óµµ ÀÖ´Ù¸é ÀÌ ÆÐÅ°Áö¸¦ ¼³Ä¡ÇÒ °ÍÀÌ´Ù.
  # yum install festival\*
ÀÌ°ÍÀº festival speech generation ÇÁ·Î±×·¥°ú speech ºÐ¼®À» ÇØÁÖ´Â °³¹ß ¼ÒÇÁÆ®¿þ°¡ ½ÇÇàµÇ±âÀ§ÇØ ÇÊ¿äÇÑ ¸ðµç ÆÐÅ°Áöµé(¿¹: festival ¹× festival-devel)À» ¼³Ä¡ÇÒ °ÍÀÌ´Ù. ½©¿¡¼­ "*" ¹®ÀÚ¸¦ ó¸®Çϱâ À§ÇØ "\"°¡ ÇÊ¿äÇÔ¿¡ À¯ÀÇÇ϶ó.

YumÀ¸·Î ÆÐÅ°Áö ¾÷µ¥ÀÌÆ®Çϱâ
  # yum update ÆÐÅ°Áö1 [ÆÐÅ°Áö2 ÆÐÅ°Áö3...]
YumÀº ÆÐÅ°Áö1ÀÌ ÀÌ¹Ì ¼³Ä¡µÇ¾î ÀÖ°í ÃֽŠ¹öÀüÀÎÁö üũÇÒ °ÍÀÌ´Ù. ¸¸¾à ±×·¸Áö ¾Ê´Ù¸é, ÆÐÅ°Áö1{±×¸®°í ¸ðµç ÀÇÁ¸°ü°è¿¡ ÀÖ´Â ÆÐÅ°Áöµé}À» (ij½Ã µð·ºÅ丮¿¡ ÀúÀåÇϸ鼭) ³»·Á¹Þ°í (È¿°úÀûÀ¸·Î ¾÷±×·¹À̵åÇϸ鼭) À缳ġÇÒ °ÍÀÌ´Ù. Ãß°¡ÀûÀ¸·Î ¾÷µ¥ÀÌÆ®ÇÒ ÆÐÅ°ÁöµéÀº °°Àº ¸í·ÉÁÙ¿¡ ³ª¿­ÇÏ¸é µÈ´Ù. ÆÐÅ°Áö À̸§Àº Ç¥ÁØ ÆÄÀϽýºÅÛ globÀ¸·Î ÁöÁ¤ÇÒ ¼öµµ ÀÖ´Ù. ¸î°¡Áö ¿¹¸¦ µé¸é:
  # yum update
¾î¶² ¸é¿¡¼­´Â À̸¦ À§ÇØ yumÀÌ °³¹ßµÇ¾ú´Ù°íµµ ÇÒ ¼ö ÀÖ´Â, °¡Àå Áß¿äÇÏ°í À¯¿ëÇÑ yum ¸í·É¾îµé ÁßÀÇ ÇϳªÀÌ´Ù. ÀÌ ¸í·ÉÀº ½Ã½ºÅÛ¿¡ ¼³Ä¡µÈ ¸ðµç ÆÐÅ°ÁöµéÀ» ÀúÀå¼Òµé¿¡ ÀÖ´Â ÃֽŠ¹öÀüÀ¸·Î ¾÷µ¥ÀÌÆ®ÇÑ´Ù. ÀÌ´Â ½Ã½ºÅÛÀ» ´Ü¼øÇÑ ½ºÅ©¸³Æ® Çϳª·Î ÃÖ½ÅÀÇ »óÅ·ΠÀ¯ÁöÇÒ ¼ö ÀÖ°Ô Çϸç, ÇÊ¿äÇÒ ¶§ ¾ðÁ¦µçÁö ¾î¶² ÆÐÅ°Áö¶óµµ ¾÷µ¥ÀÌÆ®ÇÒ ¼ö ÀÖ°Ô ÇÑ´Ù.
  # yum update jpilot
ÀÌ°ÍÀº jpilot ÆÐÅ°Áö(ÆÊ ÆÄÀÏ·µÀ» À§ÇÑ ¸Å·ÂÀûÀÎ ÀÎÅÍÆäÀ̽º¸¦ Á¦°øÇÏ´Â µµ±¸)¸¦ Ž»öÇÏ¿© ÀÌ ÆÐÅ°Áö°¡ Á¸ÀçÇÏ´Â yum ÀúÀå¼Ò°¡ Çϳª¶óµµ ÀÖ´Ù¸é ÀÌ ÆÐÅ°Áö¸¦ ¾÷µ¥ÀÌÆ®ÇÒ °ÍÀÌ´Ù.
  # yum update festival\*
ÀÌ°ÍÀº ¸¶Ä§ ½Ã½ºÅÛ¿¡ ¼³Ä¡µÇ¾î ÀÖ´Â festival speech generation suit¿¡ Æ÷ÇÔµÈ ¸ðµç ÆÐÅ°ÁöµéÀ» ¾÷µ¥ÀÌÆ®ÇÒ °ÍÀÌ´Ù. ½©¿¡¼­ "*" ¹®ÀÚ¸¦ ó¸®Çϱâ À§ÇØ "\"°¡ ÇÊ¿äÇÔ¿¡ À¯ÀÇÇ϶ó.

YumÀ¸·Î ÆÐÅ°Áö »èÁ¦Çϱâ

ÆÐÅ°Áö¸¦ »èÁ¦ÇÒ ¶§´Â Ç×»ó ÁÖÀǸ¦ ±â¿ï¿©¾ß ÇÑ´Ù. ±× ÀÌÀ¯´Â ÀÇÁ¸¼º °ü°è ¶§¹®ÀÌ´Ù. - ¸¸¾à ¼³Ä¡µÇ¾î ÀÖ´Â ´Ù¸¥ ÆÐÅ°ÁöµéÀÌ (±× ÆÐÅ°ÁöÀÇ °øÀ¯ ¶óÀ̺귯¸®¸¦ »ç¿ëÇϱâ À§Çؼ­, ¼³Á¤ ÆÄÀÏÀ» Àбâ À§Çؼ­, ½ÉÁö¾î ¹ÙÀ̳ʸ®¸¦ ÂüÁ¶Çϱâ À§Çؼ­) ÀÇÁ¸ÇÏ´Â ¾î¶² ÆÐÅ°Áö¸¦ »èÁ¦ÇÑ´Ù¸é ÀÇÁ¸°ü°è¿¡ ÀÖ´ø ´Ù¸¥ ÆÐÅ°ÁöµéÀº "µ¢±×·¯´Ï" ³²°Ô µÇ°í ºÎºÐÀû ȤÀº ÀüüÀûÀÎ ±â´ÉÀå¾Ö »óÅ·ΠÀÖ°Ô µÉ °ÍÀÌ´Ù. YumÀº ÆÐÅ°Áö »èÁ¦¿Í °ü·ÃÇؼ­ °¡´ÉÇÑ Æı«ÀÇ ºÎÀÛ¿ëÀ» ÇÇÇϵµ·Ï µµ¿ÍÁִµ¥, ÀÌ·± ºÎ·ùÀÇ ÀϵéÀÌ Ç×»ó ±×·¸µíÀÌ, »ç¿ëÀÚ·Î ÇÏ¿©±Ý À̸¦ »ç¿ëÇÒ ¶§ ÁÖÀDZí°Ô »ý°¢Çϵµ·Ï ¿ä±¸ÇÏ´Â °ÍÀÌ´Ù. ±×·¯¹Ç·Î ÆÐÅ°Áö¸¦ »èÁ¦ÇÒ ¶§ ºñ´ëÈ­½ÄÀ¸·Î YumÀ» »ç¿ëÇÏ´Â °ÍÀº °¡Àå Çö¸íÇÏÁö ¸øÇÑ °ÍÀÌ´Ù.

Àý´ë·Î ½Ã½ºÅÛÀ» ºÒÀÏÄ¡µÈ/±úÁø »óÅ·Π¸¸µéÁö ¾Ê´Â´Ù´Â °ÍÀÌ YumÀÇ ±âº» ¼³°è öÇÐÀ̹ǷΠ(YumÀº ¾î¶°ÇÑ

--force

¿Í °°Àº ¿É¼Çµµ Áö¿øÇÏÁö ¾Ê´Â´Ù.) ¸¸¾à yumÀ¸·Î ¾î¶² ÆÐÅ°Áö »èÁ¦¸¦ ¿äûÇÑ´Ù¸é, yumÀº ±× ÆÐÅ°Áö¿¡ ÀÇÁ¸ÀûÀÎ ¸ðµç ÆÐÅ°Áöµé ¶ÇÇÑ »èÁ¦ÇÏ·Á ½ÃµµÇÒ °ÍÀÌ´Ù. ÆÐÅ°Áö »èÁ¦ÀÇ °úÁ¤Àº ¸ðµç ÀÇÁ¸°ü°è¸¦ µû¶ó¼­ ¹Ýº¹µÇ¹Ç·Î ¸¸¾à »èÁ¦ÇÏ·Á´Â ÆÐÅ°Áö°¡ X ÀÚü³ª ¾ÆÆÄÄ¡°¡ ÀÇÁ¸ÇÏ°í ÀÖ´Â °ÍÀ̶ó¸é, ±×°ÍÀº ¸¶Ä¡ {»ç¿ëÀÚ È¯°æ Àüü}³ª {À¥¼­¹ö Àüü}¸¦ »èÁ¦ÇÏ·Á´Â °Í°úµµ °°´Ù. ´ëºÎºÐÀÇ °æ¿ì, ÀÌ°ÍÀº ¿øÇÏ´Â ¹Ù°¡ ¾Æ´Ò °ÍÀÌ´Ù.

»óȲÀ» ÀÌÇØÇغ¸ÀÚ. ¾î¶² °æ¿ì¿¡ ´ÜÁö ¸Ç À§ ¼öÁØÀÇ ÆÐÅ°Áö Çϳª¸¸ Áö¿ì·Á°í ÀǵµÇÏÁö¸¸, ¼³Ä¡µÈ ´Ù¸¥ ÆÐÅ°ÁöµéÀÌ ±× ÆÐÅ°Áö¿¡ ÀÇÁ¸ÀûÀ̶ó´Â »ç½ÇÀ» ±ú´ÝÁö ¸øÇÒ ¼öµµ ÀÖ´Ù. ÀÌ·¯ÇÑ °æ¿ì¿¡ YumÀº, ´Ù¸¥ ¾î¶² °Í¿¡ Á¤¸» ÇÊ¿äÇÏ´Ù´Â »ç½ÇÀ» ±ú´ÝÁö ¸øÇÑ Ã¤ ¾î¶² ÆÐÅ°Áö¸¦ »èÁ¦ÇÏ´Â °ÍÀ» ¹æÁöÇÏ´Â ÀÏÁ¾ÀÇ ¼­ºñ½º¸¦ Á¦°øÇÑ´Ù. ´Ù¸¥ °æ¿ì·Î, ´ÜÁö ±× ÀÇÁ¸¼ºÀ» ¸¸Á·½ÃÄÑÁÖ´Â ¶Ç ´Ù¸¥ ÆÐÅ°Áö·Î ´ëüÇÏ·Á°í ¾î¶² ÆÐÅ°Áö¸¦ »èÁ¦ÇÏ·Á´Â °Í »ÓÀε¥, ¸· ÀÇÁ¸¼ºÀÌ °á¿©µÈ ÆÐÅ°ÁöµéÀ» ´Ù½Ã ¿¬°á½ÃÄÑ ÁÖ·Á´Â ÂüÀε¥ ¿Ö yumÀÌ °ü·ÃµÈ ¸ðµç ÆÐÅ°ÁöµéÀ» Áö¿ì·Á°í µå´ÂÁö¿¡ ´ëÇØ µûÁö°í ½ÍÀ» Áöµµ ¸ð¸¥´Ù.

¿©·¯°¡Áö ÀÌÀ¯µéÀÌ ÀÖ´Ù. ÇÑ °¡Áö ÀÌÀ¯´Â, ¸¸¾à »óÈ£¿¬°áµÈ ÀÇÁ¸¼º Æ®¸®¸¦ ½ÉÇ÷À» ±â¿ï¿© ¿Ïº®ÇÏ°Ô È®Àå½ÃÄÑ¿ÀÁö ¸øÇß°í, ÇØ´ç ÀÇÁ¸¼º Æ®¸®¿¡¼­ ¸ðµç ÇÁ·Î±×·¥ ¹× µµ±¸µéÀ» öÀúÇÏ°Ô Å×½ºÆ®Çغ¸Áö ¸øÇß´Ù¸é, Áö±Ý Àá±ñ »èÁ¦ÇÏ·Á´Â ÆÐÅ°Áö°¡ Á¤¸»·Î ¿ÏÀüÈ÷ ´ëüµÇ¾î µ¿ÀÛÇÒ Áö´Â ¾Ë ¼ö ¾ø´Ù´Â °ÍÀÌ´Ù. ´ëü ÆÐÅ°Áö°¡ ÇÊ¿äÇÑ ÆÄÀÏÀ̳ª ÇÁ·Î±×·¥ ȤÀº ¶óÀ̺귯¸®¸¦ Á¦°øÇÑ´Ù´Â »ç½ÇÀ» ¾Æ´Â °Í ¸¸À¸·Î´Â ºÒÃæºÐÇÏ´Ù. -- ½Ã°£¿¡ µû¶ó ¹Ù²ð ¼ö ÀÖ°í Á¤¸» ±×·¸±âµµ ÇϹǷÎ, ÇÊ¿äÇÑ ÆÄÀÏÀ̳ª ÇÁ·Î±×·¥ ȤÀº ¶óÀ̺귯¸®ÀÇ ¹öÀü ÀÇÁ¸¼º¿¡ ´ëÇØ Ã¶ÀúÈ÷ ÀÛ¾÷Çؾ߸¸ ÇÑ´Ù. »õ ±â´ÉÀÌ Ãß°¡µÇ°í, ±¸ ±â´ÉÀº »ç¶óÁö¸ç, ¶È°°Àº ÀϹÝÀûÀÎ ¸ñÀûÀ» ¼öÇàÇÏ´Â °°Àº À̸§ÀÇ µÎ ÇÁ·Î±×·¥µµ °áÁ¤ÀûÀ¸·Î ´Ù¸¥ ÀÎÀÚµéÀ» ÃëÇÏ°Ô µÈ´Ù.

¹°·Ð ¾î¶² °æ¿ì¿¡´Â ´ÜÁö ÇÑ ÆÐÅ°Áö¸¦ »èÁ¦ÇÏ°í ±×°ÍÀ» °°Àº À̸§À» °¡Áø ´õ ÃÖ½ÅÀÇ ÆÐÅ°Áö·Î ´ëüÇÏ±æ ¿øÇÑ´Ù. However, this is what the update command above does for you already as an atomic entity that never leaves the dependencies dangling, and in general you should use it instead, as it is likely to do a far more careful job of resolving the dependencies and ensuring that the updated package will still suffice.

There is one more place where this sort of remove-and-replace activity is likely to occur - when a package is obsoleted by another package. A package is obsoleted when it is removed entirely from an entire distribution/dependency tree and replace by a completely different package (different name, possibly different contents). This happens fairly regularly, if rarely, especially when the obsoleted package provides a configuration file that is shared by several tools. RPM's obsoletion process is very tricky, and can break things even when used correctly as it depends on all the packages in the dependency tree doing the right thing. Package are often obsoleted when a distribution changes its revision number, as that is the right time to manipulate entire branches of the tree with minimal impact.

The yum upgrade command listed below is the solution to the problem of obsoletion. It functions much like update, except that it manages the RPM obsoletes.

¾î¶² °æ¿ìµç, ÆÐÅ°Áö »èÁ¦¸¦ À§ÇÑ ¸í·É¾î ±¸Á¶´Â ´ÙÀ½°ú °°´Ù.:
  # yum remove ÆÐÅ°Áö1 [ÆÐÅ°Áö2 ÆÐÅ°Áö3...]
¾Õ¼­ ¸»ÇßµíÀÌ, ÀÌ ¸í·ÉÀº ÆÐÅ°Áö1°ú ´õºÒ¾î ÀÌ ÆÐÅ°Áö¿¡ ÀÇÁ¸ÀûÀÎ ¸ðµç ÆÐÅ°ÁöµéÀ» »èÁ¦ÇÑ´Ù. (¾Æ¸¶ ¼³Á¤ ÀÚ·á¿¡ °üÇÑ ÇÑ º¹±¸ÇÒ ¼ö ¾øÀ» ¼öµµ ÀÖ´Ù). °è¼Ó ÁøÇàÇϱâÀü¿¡ »èÁ¦µÈ ÆÐÅ°ÁöÀÇ ¸ñ·ÏÀÌ È®ÀÎÇÑ °Í°ú ÀÏÄ¡ÇÏ´ÂÁö È®½ÇÈ÷ ÇØ µÎ¾î¶ó. Ãß°¡ÀûÀ¸·Î »èÁ¦ÇÒ ÆÐÅ°ÁöµéÀº °°Àº ¸í·ÉÁÙ¿¡ ³ª¿­ÇÏ¸é µÇ¸ç, ÆÐÅ°Áö À̸§Àº Ç¥ÁØ ÆÄÀϽýºÅÛ globÀ¸·Î ÁöÁ¤ÇÒ ¼ö ÀÖÁö¸¸ »èÁ¦ÇÒ ¸ñ·ÏÀ» È®ÀÎÇÏ´Â ¹®Á¦¸¦ ÈξÀ Èûµé°Ô ¸¸µç´Ù.

yum upgrade

Upgrading is the same as updating (and takes similar arguments) except that, as noted above, it also resolves and manages RPM package obsoletes, which remove core packages upon which many things depend and replace them (and as many of the dangling dependencies as possible) with a new, consistent branch in the dependency tree. This is not a completely safe thing to do in many cases because the overall replacement process can be very wide-reaching and have side effects that are difficult to fully explore in a testing process.

Note that under ordinary circumstances one should almost never encounter obsoletes unless you are actually upgrading from one distribution revision to another or are mixing packages from two different distributions revisions into your repository. For a variety of reasons, the latter is a really bad idea unless you love administrative pain. For a variety of reasons, it is often done anyway, and one of the things that tempts the use of

rpm --force

and consequently "breaks" the RPM database so that it becomes nearly impossible to safely resolve dependencies in the future. Yum upgrade at least gives you your best chance not to egregiously break something in this process without fair warning.

Even the legitimate purpose of doing a full revision upgrade is fraught with peril. For example, in revision upgrades the entire format of key configuration files in /etc might well change, and all tools and functions that depend on them might also need to change all the way down at the API or ABI level. It is again difficult to know that the RPMs for the entire upgraded tree are sufficiently carefully built that they can manage to both remove the old configuration files and preserve their contents and port the contents into the newly supported format, if possible. It is not at all unlikely that configuration data may be lost across an upgrade and that a system will therefore require a certain judicious amount of reconfiguration afterwards to regain full functionality.

For a specific example of this, consider the gradual replacement of the old Unix

lpr

printing system with the newer

CUPS

(Common Unix Printing System). Every aspect of printing configuration changes between the two, and it is nearly impossible to upgrade from one to the other without totally redoing the way printing is managed.

Because of these issues and yum's desire to function and do no harm in the process, it is likely the the

yum upgrade

function will be deprecated in the not horribly distant future. For that reason it is listed last in this HOWTO. In the meantime, it can certainly be a useful command and yum often does extraordinarily well at doing an upgrade, for all the dire warnings above. The author (rgb) of this HOWTO has used yum to upgrade Red Hat based systems on several occasions with complete satisfaction. He no longer does this - better practice is to develop e.g. a kickstart description of the systems in question that permits a full (re)install at any time into a perfectly functional state. This kickstart file is a much safer basis for upgrading the system to new distributions as they are released, as a full install eliminates the obsolescence process altogether, or at least forces one to confront precisely the relevant configuration issues as the emerge.

YumÀÇ ±×·ì ¼³Ä¡/»èÁ¦ ¸í·É¾î
  # yum group[install,update] ±×·ì1 [±×·ì2 ±×·ì3...]
ÃÖ±Ù Yum¿¡´Â ´Ù¼Ò À¯»çÇÑ ÀÎÀÚ¸¦ °¡Áø, (¾Æ·¡¿¡ ³ª¿À´Â ¸®½ºÆ® ±â´ÉÀº ¹°·Ð) ½Ã½ºÅÛ¿¡ Á¤ÀÇµÈ "ÆÐÅ°Áö ±×·ì"ÀÇ ´ÜÀ§·Î ¼³Ä¡ ¹× ¾÷µ¥ÀÌÆ® ±â´ÉÀ» ¼öÇàÇÏ´Â ´É·ÂÀÌ Ãß°¡µÇ¾ú´Ù. ÀÌ´Â ÆÐÅ°Áö ±×·ìµéÀÌ Á¤ÀÇµÈ ½Ã½ºÅÛ¿¡¼­, ÇϳªÀÇ Àüü ¼ÒÇÁÆ®¿þ¾î ºí·ÏÀ» ´Ü¹ø¿¡ ºñ±³Àû ¼³Ä¡Çϱ⠽±°Ô ÇØÁØ´Ù.

This can be very useful if one is using yum as a full scale system installation tool in its own right. For example, it is possible to put X onto a server originally installed without it by means of:
  # yum groupinstall "X Window System" "X Software Development"
The

groupupdate

function is likely to be only infrequently required, as of course a

yum update

will update all packages on the system whether or not they were originally installed as a part of a group. One could imagine, perhaps, a circumstance where one wishes to update a particular group to current but not update the rest of your software installation to current, but I (rgb) have never encountered one.

11.2. Á¤º¸¸¦ Á¦°øÇÏ´Â Yum ¸í·É¾î


YumÀ¸·Î ¼³Ä¡ °¡´ÉÇϰųª ÀÌ¹Ì ¼³Ä¡µÈ ÆÐÅ°ÁöÀÇ ¸ñ·Ï ¸¸µé±â

YumÀ¸·Î ÆÐÅ°Áö¿¡¼­ Á¤º¸ ¾ò¾î¿À±â

YumÀ¸·Î ÆÐÅ°Áö¼ÓÀÇ ³»¿ë º¸¿©ÁÖ±â

YumÀ¸·Î ¼³Ä¡µÇ¾ú°Å³ª ±×·¸Áö ¾ÊÀº ÆÐÅ°Áö¼ÓÀÇ ÆÄÀÏ °Ë»öÇϱâ

12. Yum ÀúÀå¼Ò¸¦ À§ÇÑ RPMs ºôµåÇϱâ


13. º¸¾È


14. ±âŸ


15. ´õ ¸¹Àº Á¤º¸


ID
Password
Join
You are scrupulously honest, frank, and straightforward.


sponsored by andamiro
sponsored by cdnetworks
sponsored by HP

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2006-12-06 15:27:46
Processing time 0.0291 sec