Utilizzare SQL Express edition
Andrew
macchina dedicata. Sulla macchina mi viene fornito Windows 2003 Web
Edition, sulla quale - ho chiesto in MS- è possibile installare SQL
Express Edition.
Una volta installato l'OS, Il .net framework 2, e il pacchetto SQL
Express edition ... la macchina è pronta per utilizzare db mdf con le
user instance e (annessi problemi) o devo fare altro?
Grazie
Andrea
Luca Bianchi
> Express edition ... la macchina è pronta per utilizzare db mdf con le
> user instance e (annessi problemi) o devo fare altro?
Non devi far altro se non preoccuparti dei futuri problemi che ti daranno le
User Instance.
Posso chiederti da dove nasce la tua volontà di utilizzare le UI?
> Grazie
> Andrea
Bye
--
Luca Bianchi
Microsoft MVP - SQL Server
http://blogs.aspitalia.com/lucabianchi
Andrea Montanari
in aggiunta alle perplessita' di Luca che fortemente condivido, la "macchina
e' pronta ad utilizzare le user instances" solo se questa feature sia stata
abilitata, al momento dell'installazione ovvero successivamente via
sp_configure 'user instances enabled', '1';
saluti
--
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz http://italy.mvps.org
DbaMgr2k ver 0.21.0 - DbaMgr ver 0.65.0 and further SQL Tools
--------- remove DMO to reply
Andrew
Quindi dato che il server sarebbe dedicato ad un cliente solo ...
penso che posso pure pagare lo scotto delle user instances.
Però una cosa non mi torna. User instances mica vuol dire che si
collega un utente per volta.
Cioè ... webbisticamente parlando ... sarà un utente ... quello
asp.net che si collegherà al sito e che lavorerà con il db.
Per quello che ho potuto vedere di persona le UI mi hann0oo creato
problemi se l'utente asp.net utilizzava il sito e io con VS o con SSMS
non potevo alterare / visualizzare il contenuto del db.
Essendo un sito da utilizzare ... quale potrebbe essere il problema
ulteriore?
Ciao
ANdrea
Lorenzo Benaglia
> Beh comprare una licenza SQL non è che sia decisamente economico.
> Quindi dato che il server sarebbe dedicato ad un cliente solo ...
> penso che posso pure pagare lo scotto delle user instances.
Ciao Andrew,
Guarda che SQL Server 2005 Express Edition supporta anche connessioni
"standard"... :-)
Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo
http://italy.mvps.org
Andrea Montanari
Lorenzo ti ha gia' dato un'informazione "vitale".. :D
Andrew wrote:
> Beh comprare una licenza SQL non è che sia decisamente economico.
> Quindi dato che il server sarebbe dedicato ad un cliente solo ...
> penso che posso pure pagare lo scotto delle user instances.
IMVHO
io non ci penso lontanamente a pagare questo scotto, che vuol dire, molto
spesso, "farsi molto male"
tu pensa come stai usando SQL Server... nessuna gestione dei privilegi,
nessuno "studio" architetturale di protezione... distribuisci la tua
applicazione e va tutto bene..
poi ti viene detto che il cliente non ha SQLExpress ma una edizione "piena"
di SQL Server 2005, oppure ha esigenze di FullText (quindi SQLExpress with
Advanced Services) e non vuole installare altre istanze..
in entrambi i casi le user instance non funzionano piu'..
bello vero?
allora decidi di "migrare" al supporto "completo" di SQL Server... non hai
implementato nessuna politica di "protezione", visto che la user instance e'
in definitiva un sysadmin.. e qui cominciano i guai :D
ti lascio andare avanti nel ragionamento da solo, ma, sempre IMVHO, ci si
ritrova sempre nella situazione di Aldo Giovanni e Giacomo... ed intendo
quella dove c'e' un personaggio vestito tutto di nero con un sospensorio ed
una bottiglia in mano... :D
> Però una cosa non mi torna. User instances mica vuol dire che si
> collega un utente per volta.
> Cioè ... webbisticamente parlando ... sarà un utente ... quello
> asp.net che si collegherà al sito e che lavorerà con il db.
le user instance vengono "generate" a livello utente... quindi,
correttamente, nel contesto dell'account che esegue l'application server..
ricorda anche che, malgrado siano soluzioni "multiutente", la multiutenza e'
limitata alla macchina locale, visto che non sono utilizzabili connessioni
remote..
e qui si potrebbe ritornare allo scenario di cui sopra.. magari il cliente
chiedera' anche di poter accedere sia tramite web clients (quindi
application server, tutto ok), che da win clients "remoti".. e mi viene
sempre in mente Giacomo :D
Andrew
Appunto, userò SQL Express solo perchè è gratis :) non ho detto che
voglio usare le user instances :)
Ne ho le balle piene.
> tu pensa come stai usando SQL Server... nessuna gestione dei privilegi,
> nessuno "studio" architetturale di protezione... distribuisci la tua
> applicazione e va tutto bene..
Quando parli di privilegi, esattamente a cosa ti riferisci? Al fatto
che non posso declassare il sysadmin
e togliergli un pò di permessi? Permessi a livello db, o permessi
utente che si collega al db e quindi
utente windows.
In un post addietro mi avete detto che la gestione utenti di SQLE è
identica a SQL normale.
Quindi anche qua non mi tornano i conti.
> poi ti viene detto che il cliente non ha SQLExpress ma una edizione "piena"
> di SQL Server 2005, oppure ha esigenze di FullText (quindi SQLExpress with
> Advanced Services) e non vuole installare altre istanze..
No, perchè il cliente manco sa che cosa è SQL Server :) Sono io che
gli sto facendo un sito
e ovviamente non volevo usare access.
> in entrambi i casi le user instance non funzionano piu'..
> bello vero?
> allora decidi di "migrare" al supporto "completo" di SQL Server... non hai
> implementato nessuna politica di "protezione", visto che la user instance e'
> in definitiva un sysadmin.. e qui cominciano i guai :D
Che intendi per polica di protezione? Va a finire che sono tutte cose
che ho già fatto ma non
le chiamo con lo stesso nome :P
> > Però una cosa non mi torna. User instances mica vuol dire che si
> > collega un utente per volta.
> > Cioè ... webbisticamente parlando ... sarà un utente ... quello
> > asp.net che si collegherà al sito e che lavorerà con il db.
>
> le user instance vengono "generate" a livello utente... quindi,
> correttamente, nel contesto dell'account che esegue l'application server..
> ricorda anche che, malgrado siano soluzioni "multiutente", la multiutenza e'
> limitata alla macchina locale, visto che non sono utilizzabili connessioni
> remote.
L'unica connessione remota sarà quella web. Sempre e cmq
> e qui si potrebbe ritornare allo scenario di cui sopra.. magari il cliente
> chiedera' anche di poter accedere sia tramite web clients che da win clients "remoti"..
> e mi viene sempre in mente Giacomo :D
E a me verrà in mente di presentargli il preventivo per l'acquisto di
SQL :=)
Ciao
Andrea
Andrea Montanari
Andrew wrote:
>> Lorenzo ti ha gia' dato un'informazione "vitale".. :D
>
> Appunto, userò SQL Express solo perchè è gratis :) non ho detto che
> voglio usare le user instances :)
> Ne ho le balle piene.
stress da week end? :D
dai che tra un po' (forse) arrivano le ferie :D
>
>> tu pensa come stai usando SQL Server... nessuna gestione dei
>> privilegi,
>> nessuno "studio" architetturale di protezione... distribuisci la tua
>> applicazione e va tutto bene..
>
> Quando parli di privilegi, esattamente a cosa ti riferisci? Al fatto
> che non posso declassare il sysadmin
> e togliergli un pò di permessi? Permessi a livello db, o permessi
> utente che si collega al db e quindi
> utente windows.
parlo del fatto che, una User Instance e' effettivamente "diversa" sotto il
profilo della sicurezza...
per capirci, l'account che esegue l'applicazione si connette in qualita' di
sysadmin visto che, nelle intenzioni di Microsoft, una User Instance non
puo' fare male che a se stessa (e solo all'utente corrente, visto che, in
contesto di Windows forms [ma non nel caso di application server] ogni
diverso utente avrebbe la sua "replica" di database nella propria cartella
\Document & Settings\NomeUtente\...) e quindi non c'e' bisogno di politiche
di sicurezza...
> In un post addietro mi avete detto che la gestione utenti di SQLE è
> identica a SQL normale.
> Quindi anche qua non mi tornano i conti.
per quanto riguarda SQLExpress sicuramente si, ma diversa e' la
funzionalita' delle User Instances.. che, tra l'altro, ripeto, NON sono
disponibili nelle altre edizioni di SQL Server 2005..
>> poi ti viene detto che il cliente non ha SQLExpress ma una edizione
>> "piena"
>> di SQL Server 2005, oppure ha esigenze di FullText (quindi
>> SQLExpress with
>> Advanced Services) e non vuole installare altre istanze..
>
> No, perchè il cliente manco sa che cosa è SQL Server :) Sono io che
> gli sto facendo un sito
> e ovviamente non volevo usare access.
benissimo.. andrebbe benissimo anche il JET engine.. non discuto
assolutamente su questo..
personalmente discuto le User Instances che, bada bene, sono sicuramente una
funzionalita' "eccezionale", ma, sempre personalmente, non le userei mai...
>> in entrambi i casi le user instance non funzionano piu'..
>> bello vero?
>> allora decidi di "migrare" al supporto "completo" di SQL Server...
>> non hai implementato nessuna politica di "protezione", visto che la
>> user instance e'
>> in definitiva un sysadmin.. e qui cominciano i guai :D
>
> Che intendi per polica di protezione? Va a finire che sono tutte cose
> che ho già fatto ma non
> le chiamo con lo stesso nome :P
non so se le hai implementate, ma un po' dubito.. sicuramente avrai
implementato delle "protezioni di accesso" lato "client", dove magari hai
salvato in una tabella cosa l'utente "x" puo' fare e cosa non puo' fare, lo
stesso per tutti gli altri utenti, ma non l'hai fatto a livello di database
e di istanza.. ripeto, l'utente interattivo e' qualificato nel ruolo di un
sysadmin e puo' fare effettivamente qualsiasi cosa all'interno
dell'istanza.. che poi la tua interfaccia utente non preveda la possibilita'
di eseguire un DROP TABLE dbo.Ordini e' altra cosa, ma ricorda che ci si
puo' sempre "collegare" con strumenti diversi dall'applicazione di contesto,
e che quindi la sicurezza non andrebbe pianificata esclusivamente a livello
di business layer bensi' anche (e soprattutto) a livello di data layer..
volendo fare l'avvocato del diavolo, potrei recuperare la pipe di
connessione alla user instance, connettermi con SSMSE o altro, ed eseguire
la famigerata DROP TABLE dbo.Ordini.. queste sono valutazioni da tenere in
considerazione, a mio parere.. l'importante e' sapere cosa si vuole fare,
questo e' ovvio..
piu' sotto dici:
>> ... magari il cliente
>> chiedera' anche di poter accedere sia tramite web clients che da win
>> clients "remoti"..
>
> E a me verrà in mente di presentargli il preventivo per l'acquisto di
> SQL :=)
benissimo, ma in questo caso dovrai affrontare (a progetto definito, e
quindi sicuramente dovendo mettere "pezze") cio' che prima non avevi
"bisogno" di affrontare.. la politica di protezione degli accessi in un
contesto non direttamente legato al business layer.. questa modifica
potrebbe quindi essere sostanziale..
poi, ripeto, la decisione e' sicuramente personale...
Andrew
> > voglio usare le user instances :)
> > Ne ho le balle piene.
>
> stress da week end? :D
> dai che tra un po' (forse) arrivano le ferie :D
Ho confermato il volo giusto stamattina :P
Ok cerchiamo di ricapitolare, altrimenti mi sento e mi fai passare per
tordo :)
Forse su alcuni argomenti posso pure esserlo, ma siamo qua tutti per
imparare.
> > Quando parli di privilegi, esattamente a cosa ti riferisci? Al fatto
> > che non posso declassare il sysadmin
> > e togliergli un pò di permessi? Permessi a livello db, o permessi
> > utente che si collega al db e quindi
> > utente windows.
>
> parlo del fatto che, una User Instance e' effettivamente "diversa" sotto il
> profilo della sicurezza...
> per capirci, l'account che esegue l'applicazione si connette in qualita' di
> sysadmin visto che, nelle intenzioni di Microsoft, una User Instance non
> puo' fare male che a se stessa (e solo all'utente corrente, visto che, in
> contesto di Windows forms [ma non nel caso di application server] ogni
> diverso utente avrebbe la sua "replica" di database nella propria cartella
> \Document & Settings\NomeUtente\...) e quindi non c'e' bisogno di politiche
> di sicurezza...
Web Form o Windows form, in questo caso non cambierebbe alcunchè.
utilizzando le user instances, sysadmin è l'utente con il quale viene
aperta la pipe.
Questa di default ha pieno diritto di fare quel che accidenti gli pare
sul db aperto.
Drop e non drop. Ma nulla mi viene, a livello di db, di dire che quel
sysadmin ha qualche
diritto in meno, quindi per capirci togliergli tutte le drop di mezzo.
Credo si possa fare. O magari quando mi ci ricollego la volta dopo,
viene creato un nuovo
sysadmin di default che fa tutto quello che gli pare?
Detto questo, come giustamente diceva luca, non sono obbligato ad
utilizzare SQL Express
e le user instances. Posso usare Express e una connessione nominativa
con un utente DB
a permessi limitati. Credo che questo risolva buona parte dei problemi
che mi stai enemurando.
O sbaglio?
> non so se le hai implementate, ma un po' dubito.. sicuramente avrai
> implementato delle "protezioni di accesso" lato "client", dove magari hai
> salvato in una tabella cosa l'utente "x" puo' fare e cosa non puo' fare, lo
> stesso per tutti gli altri utenti, ma non l'hai fatto a livello di database
Certo.
Ma anche a livello di db sono solito far fare il login
all'applicazione al mio
utente con un utente db vero a cui ho attribuito permessi sugli
oggetti del db.
Credo sia questo quello a cui ti stai riferendo. Giusto?
Ciao
Andrea
Andrea Montanari
Andrew wrote:
>>> Appunto, userò SQL Express solo perchè è gratis :) non ho detto che
>>> voglio usare le user instances :)
>>> Ne ho le balle piene.
>>
>> stress da week end? :D
>> dai che tra un po' (forse) arrivano le ferie :D
>
> Ho confermato il volo giusto stamattina :P
fortunello..
>
> Web Form o Windows form, in questo caso non cambierebbe alcunchè.
> utilizzando le user instances, sysadmin è l'utente con il quale viene
> aperta la pipe.
si e no..., l'utente e' quello "normale" di Windows, quindi non
necessariamente e' un sysadmin (e spero che i tuoi utenti interattivi non lo
siano :D), ma in effetti l'account ha privilegi di sysadmin all'interno
della user instance..
> Questa di default ha pieno diritto di fare quel che accidenti gli pare
> sul db aperto.
> Drop e non drop. Ma nulla mi viene, a livello di db, di dire che quel
> sysadmin ha qualche
> diritto in meno, quindi per capirci togliergli tutte le drop di mezzo.
non puoi neanche farlo :)
> Credo si possa fare. O magari quando mi ci ricollego la volta dopo,
> viene creato un nuovo
> sysadmin di default che fa tutto quello che gli pare?
non so se stiamo dicendo la stessa cosa... la login di Windows che esegue
l'applicazione, ripeto, ha i normali privilegi che gli derivano dall'OS, ma,
all'interno della user instace ha privilegi amministrativi..
> Detto questo, come giustamente diceva luca, non sono obbligato ad
> utilizzare SQL Express
> e le user instances. Posso usare Express e una connessione nominativa
> con un utente DB
> a permessi limitati. Credo che questo risolva buona parte dei problemi
> che mi stai enemurando.
> O sbaglio?
no, e' corretto.. con questo, ripeto, non intendo dire che le User Instances
siano "il male", e sicuramente hanno posizionamenti strategici nel loro
utilizzo.. dico solo che "a me" non "piacciono" per un insieme di motivi,
che in un qualche modo spero di aver fatto comprendere... ciononostante, si
possono tranquillamente utilizzare nei limiti delle loro funzionalita'.. e
l'importante e' poi ricordare che non probabilmente non basta modificare la
stringa di connessione per passare ad un utilizzo tradizionale di SQL
Server..
>> non so se le hai implementate, ma un po' dubito.. sicuramente avrai
>> implementato delle "protezioni di accesso" lato "client", dove
>> magari hai salvato in una tabella cosa l'utente "x" puo' fare e cosa
>> non puo' fare, lo stesso per tutti gli altri utenti, ma non l'hai
>> fatto a livello di database
>
> Certo.
>
> Ma anche a livello di db sono solito far fare il login
> all'applicazione al mio
> utente con un utente db vero a cui ho attribuito permessi sugli
> oggetti del db.
se ho capito cio' che intendi, non e' possibile, visto che la stringa di
connessione prevede una connessione trusted e non con mixed mode
authentication.. quindi il potenziale utente guest che possa eseguire
l'applicativo generera' al propria user instance ed i suoi privilegi saranno
comunque amministrativi, in quel contesto..
se utilizzi invero SQL Server\SQLExpress in modo "tradizionale", invece e'
sicuramente corretto cio' che hai detto.. una login non autorizzata alla
connessione potra' eseguire l'applicazione fino alla prima connessione alla
base dati.. visto che la connessione non sara' garantita, l'applicazione non
potra' procedere oltre. questo nel "normale" mondo di utilizzo di database
server..
> Credo sia questo quello a cui ti stai riferendo. Giusto?
si e no, ripeto che non so se stiamo dicendo la stessa cosa... all'interno
della user instance, a prescindere di chi si colleghi all'istanza, sia
questi un admin, uno user o addirittura un guest che possa eseguire
l'applicazione, questi, all'interno della stessa avra' privilegi elevati e
non dipendenti da quanto definito a livello di OS, quindi a tutti gli
effetti al gestione dei privilegi sui dbobjects e' inutile.. anzi,
tendenzialmente, all'interno di scenari con user instances questi concetti
non vengono ne' "insegnati" ne' richiesti visto che comunque i privilegi
sono a livello amministrativo.. e' come definire una politica di protezione
quando tutti si connettano come "sa"..