SourceMod-ის ადმინ-ფლაგები, ჯგუფები და იმუნიტეტი

SourceMod წყვეტს, რისი გაკეთება შეუძლია ადმინს, ერთასოიანი ფლაგებით (b ზოგადი ადმინი, c გაგდება, d ბანი, z-მდე - root), რომლებიც მიბმულია იდენტობაზე, ჩვეულებრივ SteamID-ზე, ფაილში addons/sourcemod/configs/admins_simple.ini. რიცხვი ფლაგების წინ, როგორც "STEAM_0:1:123456" "50:bcdj"-ში, ადმინის იმუნიტეტის დონეა: ნაგულისხმევად ადმინს არ შეუძლია უფრო მაღალი იმუნიტეტის მქონე სხვა ადმინის დამიზნება, ხოლო თანაბარი იმუნიტეტის ადმინებს ერთმანეთის დამიზნება შეუძლიათ, რაც sm_immunity_mode-ით cfg/sourcemod.cfg-ში შეიძლება შეიცვალოს. ჯგუფები admin_groups.cfg-ში აერთიანებს ფლაგებსა და იმუნიტეტს, ასე რომ როლს ერთ ადგილას ცვლი, ხოლო admin_overrides.cfg ცვლის, რომელ ფლაგს მოითხოვს ბრძანება. ეს მთელი მოდელია; სტატიის დანარჩენი ნაწილი ის დეტალებია, რომლებიც მას ისე ამუშავებს, როგორც ელოდები.

ეს ეხება ყველა თამაშს, რომელზეც SourceMod მუშაობს: Team Fortress 2, Garry's Mod (სადაც SourceMod ULX-ზე ან SAM-ზე ნაკლებად გავრცელებულია), Left 4 Dead 2, Counter-Strike: Source, Day of Defeat: Source და სხვები. Counter-Strike 2-ზე SourceMod არ მუშაობს; მისი ეკვივალენტი CounterStrikeSharp-ია, რომელსაც ხსნის CS2 პლაგინები Metamod-ითა და CounterStrikeSharp-ით.

საიდან კითხულობს SourceMod ადმინებს#

ყველა ეს ფაილი თამაშის საქაღალდის (tf/, left4dead2/, cstrike/ და ა.შ.) addons/sourcemod/configs/-შია.

ორივე ადმინ-ფაილი იკითხება, ასე რომ ადმინი შეიძლება რომელიმეში იყოს. აირჩიე ერთი თითო სერვერზე და მას მიჰყევი: ადამიანი, რომელიც ორივეშია განსაზღვრული სხვადასხვა ფლაგებით, დაბნეული შუადღის გარანტიაა. admins_simple.ini რამდენიმე ადამიანისთვის კარგია; admins.cfg ჯგუფებით უკეთესია, როცა როლები გაქვს; SQL-ზე დაფუძნებული ადმინები უკეთესია, როცა რამდენიმე სერვერი გაქვს, რადგან ცვლილება ბაზაში ყველგან მოქმედებს - გლობალური ბანების სისტემები საზოგადოებებისთვის ამ ბაზის გაზიარებას ხსნის.

ნებისმიერი ამ ფაილის რედაქტირების შემდეგ sm_reloadadmins სერვერის კონსოლში მათ რესტარტის გარეშე ხელახლა კითხულობს.

SQL ადმინები ერთზე მეტი სერვერისთვის

SourceMod-ს მოყვება ბაზაზე დაფუძნებული ადმინების ნაწილები, ნაგულისხმევად გამორთული. გადაიტანე admin-sql-threaded.smx (ან admin-sql-prefetch.smx, რომელიც ყველაფერს რუკის დაწყებისას ტვირთავს) და sql-admin-manager.smx plugins/disabled-იდან plugins-ში, და დაამატე ჩანაწერი სახელით "admins" databases.cfg-ში ჰოსტით, ბაზით, მომხმარებლითა და პაროლით. შემდეგ სერვერის კონსოლიდან:

sm_create_adm_tablessm_sql_addgroup "Moderator" bcj 20sm_sql_addadmin "Jan" steam STEAM_0:1:5555555 "" 0sm_sql_setadmingroups steam STEAM_0:1:5555555 "Moderator"

პირველი ბრძანება ცხრილებს ქმნის, დანარჩენები კი ჯგუფს და ადმინს, რომელიც მას ეკუთვნის. ყველა სერვერი, რომელიც იმავე ბაზაზე მიუთითებს, ერთსა და იმავე ადმინებს ხედავს, ასე რომ ვინმეს დაწინაურება ან მოშორება ერთხელ ხდება და არა თითო სერვერზე ცალ-ცალკე. ფაილები ბაზის გვერდით კვლავ მუშაობს, რაც მოსახერხებელია მფლობელის ჩანაწერის ლოკალურად შესანახად იმ შემთხვევისთვის, თუ ბაზა მიუწვდომელი გახდება - და მიზეზია, რომ ორივე ადგილი შეამოწმო, როცა ვინმეს ისეთი უფლებები აქვს, რომლებიც არ უნდა ჰქონდეს. თუ ადმინების ვებ-ინტერფეისით მართვა გირჩევნია, SourceBans++-ის პანელს შეუძლია ბანების გარდა ადმინებისა და ჯგუფების მართვაც იმ სერვერებისთვის, რომლებიც მისთვის ცნობილია.

ფლაგები და რას იძლევა თითოეული სინამდვილეში#

ამათგან ორი პრაქტიკულად სხვა სახელით root-ია და იგივე სიფრთხილეს იმსახურებს, რაც z:

• `m` (rcon) ნებისმიერ კონსოლის ბრძანებას უშვებს. ეს მოიცავს rcon_password-ს, exec-ს, quit-ს და ყველაფრის შეცვლას, რასაც SourceMod სხვა შემთხვევაში დაიცავდა. ვისაც m აქვს, ყველაფერ დანარჩენს თავადვე მისცემს თავს.
• `h` (cvar) ფართოა. ბევრი პლაგინი მთლიანად cvar-ებით იმართება, ასე რომ h ადმინს მათი გადაკონფიგურირების საშუალებას აძლევს, მათ შორის ლოგირების ან იმ პლაგინების გამორთვის, რომლებიც ამას შეამჩნევდნენ.

n ის ფლაგია, რომელიც საჯარო სერვერებს ასრულებს: ჩართული ჩიტები ნიშნავს noclip-ს და გაჩენას ყველასთვის, ვისაც ბრძანებები აქვს.

b ის ფლაგია, რომელიც ხალხს ავიწყდება. ადმინის ბრძანებებისა და პლაგინების უმეტესობა ელის, რომ ადმინს ის აქვს, ხოლო ადმინ-მენიუს (sm_admin) ის სჭირდება. ადმინი cd-ით, მაგრამ b-ს გარეშე, ხშირად აღმოაჩენს, რომ ბრძანებები მას აშკარა მიზეზის გარეშე უარს ეუბნება.

მორგებული ფლაგები o-დან t-მდე არაფერს ნიშნავს, სანამ პლაგინი მათ არ გამოიყენებს. პლაგინის დოკუმენტაცია ამბობს, რომელს ამოწმებს, ხოლო admin_overrides.cfg მისი შეცვლის საშუალებას გაძლევს.

რეზერვირებული სლოტები და ფლაგი a

ფლაგი a ის ერთადერთი ფლაგია, რომელიც ხშირად ეძლევა ადამიანებს, რომლებიც სტაფი საერთოდ არ არიან: დონორებს, მუდმივ მოთამაშეებს, კლანის წევრებს. ის არაფერს აკეთებს, სანამ რეზერვირებული სლოტები cfg/sourcemod.cfg-ში არ მოეწყობა, SourceMod-თან ერთად მომავალი reservedslots.smx პლაგინით:

sm_reserved_slots 2     // how many slots are kept for flag asm_hide_slots 0         // 1 hides the reserved slots from the visible maxsm_reserve_type 0       // 0, 1 or 2, see below

sm_reserve_type 0-ით ბოლო სლოტები რეზერვირებული მოთამაშეებისთვის ინახება: როცა საჯარო სლოტები სავსეა, ჩვეულებრივ მოთამაშეებს უარს ეუბნება, a-ს მქონე მოთამაშეებს კი შესვლა ისევ შეუძლიათ. 1-ით სერვერი შეიძლება სრულად შეივსოს, და როცა რეზერვირებული მოთამაშე სავსე სერვერზე შემოდის, ვინმე რეზერვირებული წვდომის გარეშე გარეთ ვარდება - ყველაზე მაღალი ლატენტობის მოთამაშე, ან სხვა წესით, პარამეტრების მიხედვით - ადგილის გასათავისუფლებლად. 2 იქცევა როგორც 1, მაგრამ გაგდებას წყვეტს, როცა ადმინების გარკვეული რაოდენობაა ონლაინ. ტიპი 0 მოთამაშეებისთვის ყველაზე ნაკლებად მოულოდნელია; ტიპი 1 სერვერს სავსეს ინარჩუნებს, მაგრამ ხალხს თამაშის შუაში აგდებს, და თუ იყენებ, ეს შენს წესებში უნდა თქვა.

რადგან a სხვა მოთამაშეებზე ძალას არ იძლევა, მისი ფართოდ გაცემა უსაფრთხოა. ის ამავე დროს ყველაზე სავარაუდო ფლაგია, რომელიც ვინმეს შეიძლება ჰქონდეს, ვინც მოგვიანებით სტაფი ხდება, ამიტომ ადამიანის მეორედ დამატებამდე არსებული ჩანაწერები შეამოწმე.

იდენტობები: SteamID, IP და სახელი#

ადმინის ჩანაწერი იდენტობით იწყება. სამი სახე არსებობს:

• SteamID, მაგალითად STEAM_0:1:123456. ერთადერთი სახე, რომელსაც Steam ამოწმებს, და ის, რომელიც უნდა გამოიყენო.
• IP მისამართი, დაწერილი წინ !-ით, მაგალითად "!203.0.113.5". აზრი აქვს მხოლოდ ფიქსირებული მისამართისთვის, რომელსაც აკონტროლებ, მაგალითად სერვერისთვის, რომელიც საკუთარ თავს ესაუბრება.
• სახელი პაროლით. ადმინის სახელი თამაშში, პაროლით, რომელსაც კლიენტი აწვდის.

SteamID-ის ფორმატი იმას უნდა ემთხვეოდეს, რასაც სერვერი ხედავს. უსაფრთხო მეთოდია, ადამიანი შემოვიდეს, სერვერის კონსოლში status გაუშვა და ID ზუსტად ისე დააკოპირო, როგორც დაიბეჭდა - Source-ის სხვადასხვა თამაში ოდნავ განსხვავებულ ფორმებს ბეჭდავს, ხელახლა აკრეფა კი შეცდომებს იწვევს.

სახელით ადმინები კლიენტის პარამეტრით მოწმდება. addons/sourcemod/configs/core.cfg-ში PassInfoVar მას ასახელებს (ნაგულისხმევია _password), ადმინი კი შესვლამდე თავის კონსოლში კრეფს setinfo _password "their-password". სისუსტე ის არის, რომ setinfo მნიშვნელობები ყველა სერვერს ეგზავნება, რომელსაც მოთამაშე უერთდება, და ნებისმიერ მათგანს მათი წაკითხვა შეუძლია. სახელითა და პაროლით ადმინები უკანასკნელი საშუალებაა სერვერებისთვის, სადაც Steam-ის შემოწმება მიუწვდომელია.

admins_simple.ini სრულად#

ფორმატი, SourceMod-ის საკუთარი დოკუმენტაციიდან, ასეთია:

// "<SteamID, !IP or name>" "[immunity:]<flags or @group>" ["password"]"STEAM_0:1:1111111"   "99:z"              // owner"STEAM_0:0:2222222"   "@Senior Admin"     // flags and immunity from the group"STEAM_0:1:3333333"   "40:bcdefgjk"       // admin without rcon or cvars"STEAM_0:0:4444444"   "20:bcj"            // moderator: kick and chat"!127.0.0.1"          "z"                 // local tools only"Night Shift Tom"     "bcj"   "a-long-password"

წესები:

• იმუნიტეტი არასავალდებულოა. "bcj" რიცხვის გარეშე ნიშნავს იმუნიტეტს 0.
• @Group Name ფლაგების ნაცვლად ყველაფერს იღებს ამ ჯგუფიდან admin_groups.cfg-ში, მისი იმუნიტეტის ჩათვლით.
• პაროლის ველი მხოლოდ სახელით ჩანაწერებს ეხება.
• კომენტარები //-ით იწყება, ხოლო გამოტოვებული ბრჭყალი მთელ ფაილს აფუჭებს. თუ რედაქტირების შემდეგ ადმინს უფლებები მოულოდნელად აღარ აქვს, შეამოწმე ბრჭყალები ყოველ ხაზზე, შემდეგ კი შეცდომა addons/sourcemod/logs/-ში მოძებნე.

ჯგუფები, admins.cfg და ჯგუფის იმუნიტეტი#

ჯგუფები როლებს მართვადს ხდის. "Moderator"-ს ერთხელ განსაზღვრავ და ერთხელ ცვლი.

Groups{	"Senior Admin"	{		"flags"		"bcdefgijk"		"immunity"	"60"	}	"Moderator"	{		"flags"		"bcj"		"immunity"	"20"		"Overrides"		{			"sm_map"		"deny"			"sm_slap"		"allow"		}	}}

შემდეგ ადმინები ჯგუფზე მიუთითებენ, ან @Moderator-ით admins_simple.ini-ში, ან admins.cfg-ში:

Admins{	"Anna"	{		"auth"		"steam"		"identity"	"STEAM_0:0:2222222"		"group"		"Senior Admin"	}	"Jan"	{		"auth"		"steam"		"identity"	"STEAM_0:1:5555555"		"group"		"Moderator"		"flags"		"k"	}}

Jan იღებს Moderator-ის ფლაგებს პლუს k-ს კენჭისყრებისთვის. ჯგუფებიდან და ადმინის საკუთარი ჩანაწერიდან მიღებული ფლაგები ერთმანეთს ემატება.

ჯგუფის იმუნიტეტს ორი ფორმა აქვს. რიცხვი წევრებზე მხოლოდ მაშინ ვრცელდება, თუ იმაზე მაღალია, რაც მათ უკვე აქვთ, ასე რომ ჯგუფს იმუნიტეტის აწევა შეუძლია, დაწევა კი არასოდეს. მნიშვნელობა, დაწერილი როგორც `@GroupName`, წევრებს კონკრეტულად ამ ჯგუფისგან აძლევს იმუნიტეტს, რიცხვების მიუხედავად - სასარგებლოა წესისთვის "მოდერატორებს არასოდეს შეუძლიათ უფროსი ადმინების დამიზნება", თუნდაც ვინმემ მოგვიანებით შეცდომით მოდერატორს მაღალი რიცხვი მისცეს.

ჯგუფის Overrides ბლოკი წევრებისთვის კონკრეტულ ბრძანებებს უშვებს ან კრძალავს. ის ფლაგებს არ ცვლის: მაგალითში მოდერატორებს sm_map აკრძალული აქვთ, თუნდაც სხვა ჩანაწერი მათ g-ს აძლევდეს, და sm_slap დაშვებული აქვთ, თუმცა f არ აქვთ.

იმუნიტეტი: ვის შეუძლია ვისი დამიზნება#

იმუნიტეტი წყვეტს, შეუძლია თუ არა ერთი ადმინის ბრძანებას სხვა ადმინზე იმოქმედოს - გაგდება, ბანი, slay. ის ჩვეულებრივ მოთამაშეებზე არ მოქმედებს, რომლებსაც იმუნიტეტი არ აქვთ და მათი დამიზნება ყოველთვის შეიძლება.

ქცევა მოდის sm_immunity_mode-იდან cfg/sourcemod.cfg-ში:

ნაგულისხმევი 1-ის პირობებში ორ მოდერატორს იმუნიტეტით 20 ერთმანეთის გაგდება შეუძლია, და ვერცერთი ვერ შეეხება უფროს ადმინს 60-ით. 2-ის პირობებში თანაბრები ერთმანეთისგანაც დაცულია, რაც ერგება სერვერებს, სადაც სტაფს შორის დავები ყოფილა. root ადმინები (z) იმუნიტეტს სრულად აიგნორებენ, და ეს კიდევ ერთი მიზეზია, რომ z რაც შეიძლება ნაკლებ ადამიანს მისცე.

განლაგება, რომელიც საზოგადოებების უმეტესობისთვის მუშაობს:

m, h, i და n მფლობელთან დატოვე, თუ კონკრეტულ ადამიანს კონკრეტული საჭიროება არ აქვს, და იმუნიტეტის რიცხვებს შორის ხარვეზები დატოვე, რომ მოგვიანებით როლი ყველას გადანომრვის გარეშე დაამატო.

Override-ები: რომელ ფლაგს მოითხოვს ბრძანება#

პლაგინები თითოეული ბრძანებისთვის ნაგულისხმევ ფლაგს ირჩევენ. როცა ეს ნაგულისხმევი შენი სტაფის სტრუქტურას არ ერგება, admin_overrides.cfg მას პლაგინის რედაქტირების გარეშე ცვლის:

Overrides{	"sm_map"		"k"     // let vote-trusted staff change the map	"sm_rcon"		"z"     // rcon only for root, not for flag m	"sm_chat"		""      // anyone can message admins}

ცარიელი სტრიქონი ნიშნავს, რომ ბრძანების გამოყენება ნებისმიერს შეუძლია. @-ით დაწყებული სახელი, მაგალითად "@CSDM" "m", ბრძანებების ჯგუფია, რომელსაც ზოგიერთი პლაგინი არეგისტრირებს, რომ რამდენიმე დაკავშირებული ბრძანების override ერთდროულად იყოს შესაძლებელი; პლაგინის დოკუმენტაცია ჯგუფს ასახელებს, თუ ასეთი აქვს.

Override-ები ის ადგილია, სადაც კითხვების უმეტესობას "რატომ შეუძლია ჩემს მოდერატორს ეს?" პასუხი ეძებნება, ამიტომ თითოეულის გვერდით მოკლე კომენტარი დატოვე, რატომ არსებობს.

შემოწმება და პრობლემების მოგვარება#

ბრძანებები, რომლებიც გეუბნება, რას ფიქრობს SourceMod სინამდვილეში:

sm_who                  // connected players and their admin flagssm_reloadadmins         // re-read every admin filesm plugins list         // confirm admin-flatfile.smx is loadedsm_dump_admcache        // write the full admin cache to a file for inspection

ადმინს საერთოდ არ აქვს უფლებები. SteamID არ ემთხვევა (დააკოპირე status-იდან), ხაზს სინტაქსის შეცდომა აქვს, ან admin-flatfile.smx არ არის ჩატვირთული ან plugins/disabled-შია გადატანილი. addons/sourcemod/logs/-ში parse-ის შეცდომები მოძებნე.

უფლებები რუკის შეცვლის შემდეგ მუშაობს, მაგრამ არა მაშინვე. ფაილი დაარედაქტირე, მაგრამ sm_reloadadmins არ გაუშვი.

ადმინს შეუძლია სხვა ადმინის გაგდება, რომელიც არ უნდა შეეძლოს. მათი იმუნიტეტის მნიშვნელობები თანაბარია და sm_immunity_mode არის 1. აწიე ერთ-ერთი, გადადი რეჟიმ 2-ზე, ან გამოიყენე ჯგუფის იმუნიტეტი @GroupName-ით.

პლაგინის ბრძანება უარს ეუბნება ადმინს, რომელსაც ფლაგი აქვს. მას აკლია b, ან override-მა მოთხოვნილი ფლაგი შეცვალა. ჩაიხედე admin_overrides.cfg-ში და მისი ჯგუფის ნებისმიერ Overrides ბლოკში.

ვიღაცას აქვს უფლებები, რომლებიც არასოდეს მიგიცია. შეამოწმე admins_simple.ini-ც და admins.cfg-იც, ყველა ჯგუფი, რომელსაც ეკუთვნის, და SQL ადმინების ცხრილები, თუ იყენებ. თუ მაინც ვერ ხსნი, მოეპყარი როგორც გატეხვას - რა ქნა, როცა შენი სერვერი გატეხეს სამუშაოს თანმიმდევრობას შეიცავს.

ადმინების ქმედებები, ლოგები და ხილვადობა#

SourceMod ადმინების ქმედებებს addons/sourcemod/logs/-ში ლოგავს, ყოველდღიური ფაილებით, ასე რომ ხედავ, ვინ ვინ გააგდო ან დაბლოკა და როდის. წაიკითხე ისინი, როცა მოთამაშე სტაფის წევრზე ჩივის, და დროდადრო მაშინაც, როცა არავინ ჩივის.

sm_show_activity cfg/sourcemod.cfg-ში განსაზღვრავს, როგორ ცხადდება ადმინის ქმედებები თამაშში. ის მნიშვნელობების ჯამია: 1 აჩვენებს აქტივობას არა-ადმინებს ანონიმურად, 2 მათთვის ადმინების სახელებს ამატებს, 4 აჩვენებს აქტივობას ადმინებს ანონიმურად, 8 ადმინებისთვის სახელებს ამატებს, ხოლო 16 root ადმინებს სახელებს ყოველთვის აჩვენებს. ნაგულისხმევი 13 ნიშნავს, რომ მოთამაშეები ხედავენ, რომ "ადმინმა" რაღაც გააკეთა, ადმინები კი ხედავენ ვინ. ბევრი საზოგადოება აყენებს 15-ს, რომ მოთამაშეებმა დაინახონ, რომელმა ადმინმა იმოქმედა, რაც ბოროტად გამოყენებას აფერხებს.

RE:NODE-ზე პანელის კონსოლი ყველა ამ ბრძანებას RCON კლიენტის გარეშე უშვებს, ხოლო subuser-ებს შეიძლება მიეცეთ კონსოლზე წვდომა ფაილებზე წვდომის გარეშე - ასე რომ მოდერატორს შეუძლია გაუშვას sm_reloadadmins ან წაიკითხოს sm_who ისე, რომ ადმინ-ფაილების რედაქტირება არ შეეძლოს. Team Fortress 2-ს, Garry's Mod-სა და Counter-Strike 1.6-ს საკუთარი გვერდები აქვთ თამაშის სერვერების ქვეშ, ხოლო Team Fortress 2-ის SourceMod პლაგინები SourceMod-ის ნულიდან დაყენებას ხსნის.

FAQ#

რა განსხვავებაა ფლაგ b-სა და ფლაგ z-ს შორის?

b ვინმეს ადმინად აქცევს განსაკუთრებული ძალის გარეშე; ყოველი სხვა ფლაგი კონკრეტულ ძალას ამატებს. z ყველა ფლაგია ერთდროულად, იმ ფლაგების ჩათვლით, რომლებსაც პლაგინები მოგვიანებით დაამატებს, და ის იმუნიტეტს აიგნორებს. b მთელ სტაფს მიეცი, z კი მფლობელს.

შემიძლია ადმინს მხოლოდ ერთ ბრძანებაზე მივცე წვდომა?

კი. მიეცი b, შემდეგ გამოიყენე ჯგუფის Overrides ბლოკი "command" "allow"-ით, ან admin_overrides.cfg-ში ბრძანების მოთხოვნილი ფლაგი შეცვალე მორგებულ ფლაგზე, რომელიც მხოლოდ მას აქვს.

იცავს იმუნიტეტი ადმინებს კენჭისყრებისგან?

თავისთავად არა. იმუნიტეტი ეხება ადმინის ბრძანებებს, რომლებიც მოთამაშეს უმიზნებს. შეუძლია თუ არა vote kick-ს ადმინის მოშორება, კენჭისყრის პლაგინზეა დამოკიდებული, რომელთაგან ბევრი იმუნიტეტს ან ფლაგებს ცალკე ამოწმებს.

admins_simple.ini გამოვიყენო თუ admins.cfg?

admins_simple.ini რამდენიმე ადმინისთვის ერთ სერვერზე. admins.cfg ჯგუფებით, როცა როლები გაქვს. მონაცემთა ბაზა, როცა რამდენიმე სერვერი გაქვს საერთო სტაფით.

რატომ ინარჩუნებს ადმინი უფლებებს მას შემდეგ, რაც წავშალე?

ადმინების ქეში ჯერ კიდევ ჩატვირთულია. გაუშვი sm_reloadadmins და შეამოწმე, ხომ არ არის ის ასევე განსაზღვრული მეორე ადმინ-ფაილში ან ჯგუფებზე დაფუძნებულ SQL მოწყობაში.