Puncte:0

Cum să porniți un serviciu fără a fi nevoie să schimbați parola

drapel ng

Am dezvoltat un software de rezervă pentru un server SQL (2019) care rulează pe un Windows Server 2019 pentru un client.
Aplicația (.net Windows Forms) are o interfață pentru a configura copiile de rezervă (de exemplu, selectați zilele pentru backup, orele de rezervă în fiecare zi și așa mai departe) și configurații ulterioare (date către serverul SMTP, lista de distribuție a e-mailului și așa mai departe). În plus, clientul conține funcții pentru restaurarea bazei de date. Backup-urile sunt pornite cu un temporizator.
Aplicația funcționează bine, dar trebuie să ruleze 24/7/365.
Descrierea problemei:
Aplicația rulează pe un server de client, iar clientul nu permite conturi în care parola nu expiră niciodată.
În plus, serverul este (cel puțin) repornit automat la fiecare două săptămâni. Deci... trebuie să accesăm serverul și să ne pornim clientul nou cel puțin o dată la două săptămâni, ceea ce nu este frumos.
Prin urmare, ne gândim să „împărțim” aplicația de rezervă în două părți:

  • Client Windows (cu funcții de backup și e-mail dezactivate)
  • Serviciu Windows (citiți fișierele de configurare la pornire, faceți copii de siguranță, trimiteți e-mailuri)

=> Țintă: Serviciul pentru backup este pornit automat după o repornire a serverului (nu este nevoie să porniți manual).
Are nevoie:
Pentru să poată trimite e-mailuri.
După cum s-a menționat mai sus, ținta este utilizarea unui „cont de sistem” fără parola (care trebuie schimbată periodic).
Suntem dezvoltatori, nu ingineri de sistem... prin urmare, „întrebarile de pornire”:
Din câte știm, există conturi de sistem pentru „Sistem local”, „Serviciul local” și „Serviciul de rețea” (poate sunt mai multe...).
Întrebare:
Unul dintre conturile menționate mai sus are toate drepturile necesare (sau există altul)?

Mulțumiri!

Puncte:1
drapel cn

Da, trebuie neapărat să aveți părțile interactive de „configurare” și „de service” separate. Partea de service trebuie să ruleze tot timpul, partea de configurare doar după cum este necesar.

Ideea de a avea o aplicație care rulează „pe consola” unui server Windows în zilele noastre este supărătoare, în cel mai bun caz, și devine mai grea cu fiecare versiune de Windows. După ce am produs Servicii Windows care sunt încă în producție după 20 de ani, sunt puțin surprins că nu ați întâlnit această „provocare” în timpul dezvoltării și testării.

Dar oricum ...

Aplicația rulează pe un server de client, iar clientul nu permite conturi în care parola nu expiră niciodată.

Având în vedere că Windows acceptă numeroase conturi „de sistem” a căror parolă nu expiră niciodată, aceasta este o „cerință” ciudată pe care trebuie să o ai aplicației tale.

Întrebare: Este aceasta „cerință” de fapt relevante?
Pentru a utiliza aplicația de „configurare”, ar trebui să vă conectați la mașină, astfel încât să utilizați orice acreditări care vi s-au dat în acest scop - acele acreditări interactive, specifice utilizatorului ar trebui să expiră periodic.

Partea „service” ar trebui să ruleze și să facă lucruri.
Dacă aceste conturi de sistem ar avea parole care expiră, ecosistemul Windows ar fi complet inutilizabil.

Serviciul trebuie să aibă acces la discul local (citește fișierul de configurare (.ini), stochează copiile de rezervă) ...

Da, absolut.
Oricare dintre conturile „Servicii” ar trebui să aibă acest nivel de acces.

... și către SMTP-Server ... pentru a putea trimite e-mailuri.

Accesul la orice „în afara” casetei necesită a Conștient de rețea cont.
Serviciul de rețea este probabil cel mai bun pariu.

... la SQL-Server (instalat pe același server) ...

Pericol, Will Robinson!
Vrei să spui serios că utilitarul tău „de rezervă” ia și depozitarea Backup-uri SQL Server pe aceeași mașină ca și instanța SQL Server în sine?

Acest lucru vă subminează întreaga soluție.

Dacă ai pierdut mașina pe care rula SQL Server, atunci ai pierde și copii de rezervă de asemenea a bazei de date și, din moment ce numai Motivul pentru care există copii de rezervă este acela de a garanta că puteți recupera baza de date, indiferent ce merge oribil, groaznic de prost, atunci „soluția ta de rezervă” este complet compromisă.
Tu absolut trebuie sa scoate backup-urile de pe acel server și pe o altă mașină, bine departe din bazele de date pe care le protejează.

FredyWenger avatar
drapel ng
Multumesc pentru raspuns. Deci... cred că ar trebui să merg cu Serviciul de Rețea. În ceea ce privește backup-urile de pe aceeași mașină: Aveți dreptate în principal, dar serverul este un server VIRTUAL care se face backup în fiecare oră din IT-ul clientului. Deci... am avea deja o copie de rezervă (a întregului server), dar IT-ul clientului obligatoriu a dorit un backup logic în prealabil. Deci backup-ul copiilor de siguranță este garantat.
Phill  W. avatar
drapel cn
Baza de date != Fișier. O copie de rezervă a serverului este bună numai din momentul în care a fost luat. Backup-urile SQL Server permit /mult mai fină/ granularitatea recuperării. Și doar pentru că ceva este un VM Guest NU îl protejează de *VM Controller* care decide, într-o zi, să „mâzgăleze” aleatoriu pe toate discurile sale - aceleași discuri care dețin imaginile de disc ale mașinilor VM Guest care rulează, distrugându-le complet în acest proces! Am fost acolo. L-am vazut. Deloc dragut. Aș sugera că strategia dvs. de recuperare are nevoie de un pic de „ajustare fină”.
FredyWenger avatar
drapel ng
Am dezvoltat cu succes serviciul Windows acum și îl pornesc sub serviciul de rețea. Orice funcționează, dar a trebuit să acord serviciului de rețea în plus niște drepturi în sistemul de fișiere. Am acceptat răspunsul tău acum. Multumesc din nou.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.