ఒకే బాక్స్లో Pi-hole మరియు VPN ఉన్నప్పుడు రెండు విషయాలు కలిసిపోతాయి: మీరు ఇన్స్టాల్ చేసిన పంపిణీ కుటుంబం మరియు భాగాలు నిజంగా మద్దతిచ్చే విడుదల మరియు నిర్మాణం. ఇమేజ్ను బూట్ చేసే బోర్డు కర్నెల్ నడుస్తుందని నిరూపిస్తుంది; Pi-hole యొక్క FTL బైనరీ మరియు మీ VPN ఇన్స్టాలర్ ఒకే వినియోగదారు-స్థలాన్ని లక్ష్యంగా చేసుకుంటాయని నిరూపించదు. అసలైన పరీక్ష బోర్డ్ మద్దతు, విడుదల శాఖ, ప్యాకేజీ నిర్మాణం మరియు మీరే నడపగల అప్గ్రేడ్ మార్గం అనే నాలుగు వైపుల అతివ్యాప్తి. ఈ నాలుగింటిలో ఏదైనా ఒక కాలు తప్పినా పరికరం ఈ వారం పనిచేస్తుంది, తర్వాత వచ్చే భద్రతా నవీకరణలో మిమ్మల్ని వదిలేస్తుంది.

మద్దతును విడుదల శాఖ నిర్ణయిస్తుంది, కుటుంబం పేరు కాదు

ప్రాజెక్ట్ ఇంకా ఏ విడుదలకు వ్యతిరేకంగా పరీక్షిస్తోందో అడగండి, తర్వాత సమాధానాన్ని Debian కాదు, వెర్షన్ స్ట్రింగ్గా రాయండి. Pi-hole యొక్క అవసరాల పేజీ మద్దతు ఉన్న ఆపరేటింగ్ సిస్టమ్లను మరియు ముందే నిర్మించిన FTL నిర్మాణాలను రెండు వేర్వేరు అవసరాలుగా జాబితా చేస్తుంది, మద్దతును పంపిణీ స్వయంగా ఇంకా నిర్వహించే విడుదలలకు పరిమితం చేస్తుంది, మరియు మద్దతు జాబితా లోపల కూడా రకాలు లేదా అసాధారణ కాన్ఫిగరేషన్లు విఫలం కావచ్చని హెచ్చరిస్తుంది. ఆ పదబంధం ముఖ్యం: మద్దతు ఉన్న కుటుంబం దాని ప్రతి సభ్యుడిని కవర్ చేయదు.

మీ Pi పై ఇంకా బూట్ అయ్యే పాత ఇమేజ్ మద్దతుకు రుజువు కాదు. బోర్డ్ బాగానే ఉంది, ప్యాకేజీ సూచిక పాతది, మరియు విడుదల ఇకపై తీర్చలేని ఆధారాన్ని ఇన్స్టాలర్ లాగినప్పుడు అసమానత తర్వాత బయటపడుతుంది.

VPN వైపు ఎక్కువ భాగాలు ఉన్నాయి, ప్రతిదానికీ దాని స్వంత కిటికీ: టన్నెల్ డీమన్, దాని కాన్ఫిగరేషన్ రాసే ఇన్స్టాల్ సహాయకుడు, ప్రొవైడర్ క్లయింట్ యాప్ మరియు పంపిణీ యొక్క ఇంటిగ్రేషన్ ప్యాకేజీ నాలుగు వేర్వేరు ప్రాజెక్టులు. మీ పంపిణీని గుర్తించే ఇన్స్టాలర్ మరియు విడుదల నడపగల సేవను ఉత్పత్తి చేసే ఇన్స్టాలర్ రెండు వేర్వేరు వాదనలు. డీమన్ యొక్క స్వంత ప్లాట్ఫారమ్ జాబితాను చూడండి, తర్వాత మీరు నడపబోయే సహాయకుడు ఆ విడుదల తర్వాత తాకబడిందో లేదో చూడండి. ప్రాజెక్ట్ నిర్దిష్ట విడుదల వరకు మాత్రమే మద్దతు ప్రకటిస్తే, తదుపరిదాన్ని మీరే బూట్ చేసే వరకు పరీక్షించనిదిగా పరిగణించండి.

బైనరీ లక్ష్యాన్ని మీ వినియోగదారు-స్థలానికి సరిపోల్చండి

నిర్మాణం నిశ్శబ్ద వైఫల్యం. 32-బిట్ వినియోగదారు భూమితో 64-బిట్ కర్నెల్ అనేక బోర్డులపై నిజమైన, మద్దతు ఉన్న కలయిక, మరియు అది 32-బిట్ FTL బైనరీని ఫిర్యాదు లేకుండా నడుపుతుంది, arm64 కోసం మాత్రమే ప్రచురించబడినది మీరు ఇన్స్టాల్ చేసే క్షణం వరకు. ఇమేజ్ ఎంచుకునే ముందు రెండు సగాలను ముద్రించండి, మరియు అవుట్పుట్ను మీ నోట్స్ పక్కన ఉంచండి.

uname -m
dpkg --print-architecture
grep -E '^(PRETTY_NAME|VERSION_ID)=' /etc/os-release
apt-cache policy pihole-ftl

ఆ రెండు నిర్మాణ పంక్తులు సరిపోలకపోతే, మీరు మిశ్రమ సెటప్లో ఉన్నారు: ఒంటరిగా Pi-hole కోసం పనిచేస్తుంది, రెండవ సేవ స్థానిక లైబ్రరీలను కోరినప్పుడు సున్నితం. శుభ్రమైన 64-బిట్ ఇమేజ్కు మళ్లీ ఫ్లాష్ చేయడం సాధారణంగా అసమానతను సృష్టించిన టూల్చెయిన్ను తిరిగి నిర్మించడం కంటే వేగంగా ఉంటుంది.

బోర్డ్ మార్కెటింగ్ కూడా దీన్ని నిర్ణయించదు. మెమరీ పరిమాణం మరియు CPU మోడల్ మీ ప్యాకేజీలు ఏ libc తో లింక్ అవుతాయనే దాని గురించి ఏమీ చెప్పవు, కాబట్టి ముద్రించిన విలువల ఆధారంగా నిర్ణయించండి, ఎప్పుడూ ఉత్పత్తి పేజీ ఆధారంగా కాదు.

ఒక బాక్స్, రెండు సేవలు, నెట్వర్క్ యొక్క ఒకే యజమాని

మొదటి ప్యాకేజీ ఎక్కే ముందు చిరునామా, రిజాల్వర్ మరియు టన్నెల్ ఎవరివో నిర్ణయించండి, లేకపోతే రెండు సేవలు ఒకే కర్తవ్యాన్ని దావా చేస్తాయి మరియు ఏదీ శుభ్రంగా గెలవదు. Pi కి మీ రౌటర్ ఇచ్చే DHCP పూల్ వెలుపల స్థిర చిరునామా ఇవ్వండి, మరియు టన్నెల్ను దాని సొంత సబ్నెట్లో ఉంచండి: Pi కి 192.168.50.10 మరియు టన్నెల్కు 10.42.0.0/24 ఒక పనిచేసే విభజన, మరియు సంఖ్యలు తాము ఏకపక్షం, అవి మీ రౌటర్ ఇప్పటికే అందిస్తున్న దానితో ఢీకొననంత వరకు. తర్వాత ఏ భాగం పోర్ట్ 53 పై సమాధానమిస్తుంది, మీరు ఉపయోగిస్తే ఏది DHCP పంపిణీ చేస్తుంది, మరియు టన్నెల్ పైన ఉన్నప్పుడు ఏది డిఫాల్ట్ మార్గాన్ని కలిగి ఉంది అని రాయండి. స్క్రీన్ లేని ఇమేజ్పై ఆ చివరి పని NetworkManager లేదా systemd-networkd ది, మరియు రిజాల్వర్ కాన్ఫిగరేషన్ను కూడా తిరిగి రాసే ప్రొవైడర్ క్లయింట్ను ఇన్స్టాల్ చేయడం ప్రజలు సజీవ టన్నెల్ మరియు మృత DNS తో ముగిసే మార్గం.

బాక్స్ పంచుకోవడం మంచిది. పాత్రను పంచుకోవడం కాదు. Pi-hole పోర్ట్ 53 పై ఏకైక శ్రోతగా ఉండాలని కోరుతుంది, మరియు VPN డీమన్ తన DNS సెట్టింగ్ను క్లయింట్లకు నెట్టాలని కోరుతుంది, కాబట్టి క్లయింట్లు ఇద్దరిలో ఎవరిని నమ్మాలో ఎంచుకోండి మరియు మరొకటి దారి నుండి తప్పుకోవడానికి కాన్ఫిగర్ చేయండి.

వీలైనప్పుడు నిర్వహణ మార్గాన్ని టన్నెల్ వెలుపల ఉంచండి. రిజాల్వర్ మరియు టన్నెల్ కలిసి విఫలమైనా, LAN చిరునామాలో SSH అందుబాటులో ఉండాలని మీరు ఇంకా కోరుతారు, మరియు దాని అర్థం నిర్వహణ సేవ రెండింటిలో దేనిపైనా ఆధారపడకూడదు.

తదుపరి అప్గ్రేడ్ను ఎంపికలో భాగం చేయండి

మీరు అప్గ్రేడ్ చేయలేని విడుదల అంటే మీరు ఇప్పటికే అంగీకరించిన మద్దతు పైకప్పు. పరికరం మీ ఇంటి DNS ను మోసుకెళ్లే ముందు అదనపు కార్డ్పై అప్గ్రేడ్ యాంత్రికతను పరీక్షించండి, మరియు ప్యాకేజీ అప్గ్రేడ్ సరిపోతుందని ఊహించడం బదులు శాఖల మధ్య దూకడం గురించి ప్రాజెక్టులు ఏమి చెబుతాయో చదవండి.

sudo apt update
apt-mark showhold
sudo apt full-upgrade
pihole -up

అప్గ్రేడ్ విజయవంతమైనట్లు కనిపించి ఏమీ మారని సాధారణ కారణం హోల్డ్ చేసిన ప్యాకేజీలు. హోల్డ్లను ఉద్దేశపూర్వకంగా ఒక్కొక్కటిగా తీసివేయండి, మరియు ఏ సేవకు పిన్ అవసరమైందో గుర్తించండి.

దూకే ముందు Pi-hole కాన్ఫిగరేషన్, స్థిర లీజ్లు మరియు ఏదైనా టన్నెల్ ప్రొఫైల్లను ఎగుమతి చేయండి, మరియు కొత్త ఇమేజ్పై వాటిని పునరుద్ధరించగలరని నిర్ధారించుకోండి. దూకిన తర్వాత సాధారణ క్లయింట్ DNS, టన్నెల్ వెనుక ఉన్న ప్రైవేట్ వనరు, తిరిగి కనెక్ట్, మరియు గేట్వేపై ఏదైనా ఫార్వార్డింగ్ నియమాన్ని పరీక్షించండి. బూట్ అయి ping కి సమాధానమిచ్చే బాక్స్ దాదాపు ఏమీ పాస్ కాలేదు.

ఏ ఒక్క విడుదల రెండు సేవలకూ సరిపోకపోతే

కొన్నిసార్లు అతివ్యాప్తి ఖాళీగా ఉంటుంది: VPN సహాయకుడు మీరు ఇన్స్టాల్ చేయగల Pi-hole ప్యాకేజీ కంటే కొత్త విడుదలకు మారాడు, లేదా బోర్డ్ విక్రేత ఇమేజ్ రెండింటి కంటే వెనుక ఉంది. ఆ సందర్భంలో ఇన్స్టాలర్ను సంతృప్తి పరచడానికి విడుదల మెటాడేటాను సవరించడం బదులు పాత్రలను వేరు చేయండి. రెండు చిన్న పరికరాలు, లేదా ఒక పరికరం మరియు రెండవ సేవ కోసం ఒక కంటైనర్, మద్దతు కథ అబద్ధంపై నిలిచిన పరికరం కంటే తక్కువ ఖర్చు.

వెర్షన్ను నకిలీ చేయడం నేరుగా తిరస్కరించాల్సిన ఏకైక షార్ట్కట్. ప్యాకేజీ నిర్వాహకులు విడుదల ఫైల్ చెప్పేదాన్ని నమ్ముతారు, కాబట్టి నకిలీ గుర్తింపు రెండు ప్రాజెక్టులలో ఏదీ డీబగ్ చేయడంలో సహాయపడని ఇన్స్టాల్ను ఇస్తుంది.

ప్రస్తుత రెండు విడుదలలు అన్నింటినీ తీరుస్తే, ఊహించకుండా అప్గ్రేడ్ నోట్స్ను అనుసరించగల ఒకదాన్ని ఎంచుకోండి, మరియు వెతకడం ఆపండి. తర్వాత వెర్షన్, నిర్మాణం, సేవా యజమానులు మరియు పునరుద్ధరణ దశను ఒకే చోట నమోదు చేయండి, ఎందుకంటే SD కార్డును తర్వాత తాకే వ్యక్తికి నాలుగూ అవసరం.

సంబంధిత వ్యాసాలు