URL അടിസ്ഥാനമാക്കിയ പാക്കേജ് ഡൗൺലോഡുകൾക്കുള്ള RPM പ്രോക്സി ഓപ്ഷനുകൾ
നേരിട്ടുള്ള റിമോട്ട് പാക്കേജ് കമാൻഡ് DNF-യിൽ നിന്ന് വ്യത്യസ്തമായി പ്രവർത്തിക്കുമ്പോൾ RPM-ന്റെ സ്വന്തം URL-ഫെച്ച് പ്രോക്സി ഓപ്ഷനുകൾ പരിശോധിക്കുക.
rpm -Uvh https://packages.example.net/example.rpm നെറ്റ്വർക്ക് വഴിയുള്ള ഫെച്ച് ഘട്ടം ഉൾക്കൊള്ളുന്നു. പാക്കേജ് പരിശോധിക്കുന്നതിനോ ഇൻസ്റ്റാൾ ചെയ്യുന്നതിനോ മുമ്പ് RPM ഫയൽ നേടണം.
പ്രവർത്തിക്കുന്ന DNF പ്രോക്സി കോൺഫിഗറേഷൻ ആ വേറിട്ട കോള് ഉപയോഗിക്കുന്ന ക്രമീകരണങ്ങൾ നിർണ്ണയിക്കുന്നില്ല. RPM-ന്റെ മാനുവൽ അതിന്റെ HTTP വീണ്ടെടുക്കൽ പാതയ്ക്കായി --httpproxy, --httpport എന്നിവ രേഖപ്പെടുത്തുന്നു. ഇൻസ്റ്റാൾ ചെയ്ത RPM പതിപ്പും അതിന്റെ URL സഹായിയുടെ ക്രമീകരണവുമാണ് വിശദാംശങ്ങൾ നിർണ്ണയിക്കുന്നത്. RPM 6-ന്റെ പൊതു-ഓപ്ഷൻ റഫറൻസ് ഈ നെറ്റ്വർക്ക്-ഫെച്ച് ഓപ്ഷനുകളെ കാലഹരണപ്പെട്ടതായി അടയാളപ്പെടുത്തുകയും പകരം curl അല്ലെങ്കിൽ GNU Wget പോലുള്ള സമർപ്പിത ഫെച്ച് ടൂൾ ശുപാർശ ചെയ്യുകയും ചെയ്യുന്നു.
നിങ്ങൾ പരിപാലിക്കുന്ന വർക്ക്ഫ്ലോയ്ക്ക് ആദ്യം ഏത് ലെയർ URL ഫെച്ച് ചെയ്യുന്നുവെന്ന് നിർണ്ണയിക്കുക. പുതിയ വർക്ക്ഫ്ലോയ്ക്ക്, വ്യക്തമായി അംഗീകരിച്ച ഡൗൺലോഡും തുടർന്ന് പ്രാദേശിക പാക്കേജ് പരിശോധനയും ഇൻസ്റ്റാളേഷനും ഈ കാലഹരണപ്പെട്ട ഫെച്ച് ഓപ്ഷനുകളെ ആശ്രയിക്കുന്നത് ഒഴിവാക്കുന്നു.
ഫീൽഡുകൾ അവയുടെ രേഖപ്പെടുത്തിയ ഫോർമാറ്റിൽ നിലനിർത്തുക. പ്രോക്സി ഹോസ്റ്റ്നെയിം ആവശ്യപ്പെടുന്നിടത്തെല്ലാം ഓരോ പതിപ്പും ക്രെഡൻഷ്യലുള്ള URL സ്വീകരിക്കുമെന്ന് അനുമാനിക്കരുത്, പഴയ ഉത്തരം അങ്ങനെ ചെയ്തു എന്ന കാരണത്താൽ ഒരു ഡിസ്ട്രിബ്യൂഷന്റെ ഗ്ലോബൽ മാക്രോ ഫയൽ തിരുത്തരുത്.
പരാജയത്തിന്റെ ഘട്ടം കണ്ടെത്തുക: ഫെച്ചിന് പ്രോക്സിയിൽ എത്താൻ കഴിഞ്ഞോ, പ്രാമാണീകരണം സ്വീകരിച്ചോ, പാക്കേജ് എൻഡ്പോയിന്റ് ഉദ്ദേശിച്ച ഫയൽ തിരികെ നൽകിയോ? പിന്നീട് വരുന്ന സിഗ്നേച്ചർ അല്ലെങ്കിൽ ആശ്രിതത്വ പിശക് കുടുങ്ങിയ പ്രോക്സി കണക്ഷനിൽ നിന്ന് വ്യത്യസ്തമായ പ്രശ്നമാണ്.
സാധാരണ പാക്കേജ് പരിശോധന നിലനിർത്തുക. ഡൗൺലോഡ് പാത പ്രവർത്തിക്കുന്നത് സിഗ്നേച്ചർ പരിശോധനകൾ ഓഫ് ചെയ്യാനോ വിശ്വസിക്കാനാകാത്ത ഫയൽ ഇൻസ്റ്റാൾ ചെയ്യാനോ വിജയകരമായ DNF കമാൻഡ് ഈ RPM ഫെച്ച് അതേ പാത പിന്തുടർന്നു എന്നതിന് തെളിവായി കണക്കാക്കാനോ ഉള്ള കാരണമല്ല.