C'est de toute manière le fonctionnement de SQLite quelque soit la technique utilisée au dessus... À moins que le serveur ne groupe lui même les requêtes ce qui serait dangereux car pourrait bloquer un SELECT.
Il semble que ce produit (je me suis procuré une beta récente) permette les écritures concurrentielles sans risque d'aucune sorte (basé sur MVCC). ça mérite tout de même le coup d'oeil (avant de dire que c'est nul) et du coup, explique peut-être le prix...
Vu que les requêtes se comptent en millisecondes, ça ne se voit pas au niveau de quelques utilisateurs.
Oui ça on m'a déjà fait le coup, et une simple facturation à 6 postes connectés a fait exploser ce genre d'argument...
Encore une fois, je n'ai pas d'actions de cette boite. M'en tape que ce soit super ou pas. La question était de savoir s'il existait un server simplissime à installer, au dessus d'un moteur type SQLite: il semble que oui. A creuser pour qui est éventuellement intéressé. Pour le reste, je n'ai pas d'états d'âmes: si ce n'est que faire le Client/Server DB avec Soap... c'est encore bien pour récupérer la température qu'il fait à Melbourne ou le cours de l'action Google.. mais pour faire une appli de bases de données, c'est pas sérieux. Mais ce n'est qu'un avis... pas une déclaration de principe ;-)
SQLite ne support pas le MVCC à la base... Je ne vois pas comment un truc au dessus pourrait le lui apporter ??? D'autant que HFS+ n'a pas de techno de Snapshot ! À moins d'avoir bidouillé les sources de SQLite pour avoir un fichier journal par connexion, mais dans ce cas la licence les aurait obligés à fournir les modifications.
Oui ça on m'a déjà fait le coup, et une simple facturation à 6 postes connectés a fait exploser ce genre d'argument...
ça dépend du nombre de connexion fait par client à la seconde aussi... Là pour son cas, c'est au grand maximum pas plus de quelques connexions par minute, faut pas exagérer
S'agissant de SQLite, il y a un éditeur qui a développé un serveur au dessus de ce moteur. Serveur qui s'installe en un clic, et qui permet d'encrypter les fichiers de bases de données (et les communications client/serveur) :
Pour le reste, je n'ai pas d'états d'âmes: si ce n'est que faire le Client/Server DB avec Soap... c'est encore bien pour récupérer la température qu'il fait à Melbourne ou le cours de l'action Google.. mais pour faire une appli de bases de données, c'est pas sérieux. Mais ce n'est qu'un avis... pas une déclaration de principe ;-)
Pour ça par contre, détrompe toi... J'ai bossé sur une appli de backup CDP qui utilise gSOAP avec un MSSQL server derrière et qui peut bien supporter 1000 posts clients qui balancent des requêtes rapidement et simultanément :fouf):
Who's using gSOAP?
Adobe Systems, AOL, BEA, Boeing, Cisco Systems, CNR, eBay, Ericsson, Exxon/Mobile, HP, IBM, Intel, Microsoft, Nokia, Pfizer, Siemens, WindRiver, Xerox, and many others (whose names we cannot disclose).
Je suppose qu'il y en a plusieurs dans le tas qui l'utilisent avec des bases de données diverses et variées...
Heu les gars j'avais pas réalisé que vous parliez de RealSQL, mais c'est un truc propre à RealBasic (un logiciel et langage de prog un peu à la VisualBasic mais orienté cross-plateform) ! C'est une solution propriétaire de RealSoftware pour RealBasic, et je ne pense vraiment pas que ce soit la solution vers laquelle se tourner
Je ne sais pas si c'est la bonne solution, mais moi aussi, croyant que c'était propre à REALbasic, j'ai récupéré l'archive et il y a bien un SDK C qui n'a rien à voir avec REALbasic.
Par ailleurs, j'ai obtenu une beta de la version 2009 qui est bien MVCC et qui tourne nickel avec plusieurs clients écrivant dans la base. Cette base est bien une base SQLite (j'ai pu l'ouvrir et la manipuler sans problème dans SQLite Maestro).
Maintenant, en effet, ce n'est pas opensource, et ce n'est peut-être pas la solution recherchée initialement, même si ce serveur s'installe et est fonctionnel en un seul clic, comme recherché au départ...
Encore une fois, je suis de loin un meilleur supporter de PostgreSQL.
Alors là franchement, je serais très intéressé de faire des tests... Prendre une base avec 1 M d'enregistrements, et 4 clients qui initient en même temps une transaction et insèrent chacun 10 000 enregistrements, puis commitent. À voir les performances et la tronche de la base après.
Il y a PostgreSQL, qui respecte la norme SQLxx, et les autres. Les autres sont tous plus ou moins merdiques, plus ou moins payant (à terme) et ne respectent pas la norme SQLxx.
Il est faux de dire qu'il est plus compliqué d'installer et d'administrer pgsql que les autres. Il y a de très bons outils, dont pgadmin sur mac.
Mais, je ne comprends pas pourquoi il n'y a pas une interface, robuste, stable et simple, cocoa-pgsql ?
Je suis prêt à participer à un groupe, qui s'intéresserait à une telle interface, pusique je constate que la demande existe.
Après moultes réflexions j'opte pour PostgreSQL, mais je suis totalement bloqué :crackboom:- le blocage n'est pas lié à Cocoa (je suis donc hors sujet... désolé), et à mon avis pas lié non plus à postgreSQL mais à Macos X... Je m'explique :
PostgreSQL installe un dossier "data" contenant entre autre un fichier pg_hba.conf qui contient les autorisations, les règles (mot de passe ou mode trust, codage md5...). Dès que je touche à ce fichier le serveur ne démarre plus, et là je viens de faire une manip assez troublante.... Je vais finir par croire qu'il existe une poupée vaudou quelque part à mon nom...
- La fenêtre du dossier "data" est ouverte, je déplace pg_hba.conf sur le bureau. Plus de fichier pg_hba.conf dans "data" le serveur ne démarre plus, ok, normal.
- Je remet le fichier pg_hba.conf sans y avoir touché. OK le serveur redémarre, normal. Ca parait idiot mais attendez la suite.
- Je le remet sur le bureau (donc l'enlève de "data"), le duplique, j'en fais une copie, apparait d'ailleurs cette copie sur le bureau avec "-copie". Je place cette copie dans le dossier "data" et renomme en pg_hba.conf, sans "-copie" : plus de démarage du serveur !!!! C'est exactement le même fichier je ne l'ai pas modifié !!!
- J'enlève cette copie remet l'original (bien que les 2 fichiers soient rigoureusement identiques) et ... le serveur remarche !!!
Argh.. Je deviens fou là ??? Quelqu'un a une idée de génie ?? Merci
PS : je sais que je suis un peu hors sujet par rapport à ce forum mais comme je l'ai déjà dis je pense que c'est ici que se trouve les cerveaux les plus aptes à trouver des solutions aux problèmes qui me rendent fou... Et si tout ça abouti à une utilisation de postgreSQL avec Cocoa et sans souffrance...
Tu dois avoir tes logs à consulter pour voir pourquoi PGSQL n'arrive pas à se lancer.
Sinon, avec ta manip du fichier conf dupliqué, regarde les droits de la copie, et éventuellement, autorise cette copie pour tout le monde (sous Finder, affiche les infos du fichier conf-copie, et dans la section des autorisations, autorise lecture et écriture à tout le monde. Puis réessaie de démarrer PGSQL avec la copie).
Il y a quelque chose à laquelle tu n'as peut-être pas pensé... Si la machine sur laquelle il faut installer le serveur fait déjà tourner un server PostgreSQL, tu fais comment ? Tu bousilles son installation et ses bases avec ton installateur ? :P Ou tu fais tourner un autre serveur PostgreSQL sur un autre port et avec les bases intallées à un autre endroit ?
Je savais bien que je ne me trompais pas de forum, que des belles idées
Alors Schlum tu mets le doigts sur un point auquel je n'ai absolument pensé et dont il faut absolument que je tienne compte...Merci
No, que dire, tu viens de résoudre un casse-tête auquel je ne voyais aucune solution, qui était incompréhensible, merci, merci, merci (je l'écrirais bien 1000 fois mais ça va faire long :P ) <br />Bon par contre bizarre mac os x... Lorsque je sauvegarde mon fichier, dans les autorisations il enlève l'utilisateur postgres !!! A la place je retrouve 2 fois admin !!!! Faut dire que postgres est un utilisateur postgres et pas de mon système, ceci dit si je veux créer un utilisateur postgres pour mon système il refuse en me disant qu'il y en a déjà un, ce qui est faux et que je peux vérifier dans le listing des utilisateurs, vraiment bizarre ce comportement...
Mais si mac os x fait un peu n'importe quoi là , pas très grave suffit après avoir modifié le fichier remettre l'autorisation postgres et ça devrait être bon, je vais essayer, tout en ligne de commande, restera plus qu'à tout passer en cocoa... Si je peux avec NSTask envoyer un fichier de ligne de commande au shell ce serait impec mais il y a des sudo...
Heu attention il y a plusieurs "types d'utilisateurs" MacOSX. - Les utilisateurs au sens UNIX, qui ont un uid, un (ou plusieurs ?) groupes avec un gid, et un nom court - Les utilisateurs au sens OSX, c'est à dire ceux qui ont des comptes dans MacOSX, affichés dans les préférences système "Comptes", et auxquels est associé une "petite maison" pour chacun.... et un utilisateur UNIX associé aussi
Du coup dans les préférences système "Compte" tu ne vois que les comptes utilisateurs "pratiques", ceux qui ont une petite maison et peuvent ouvrir une session quand tu démarres MacOSX ou revient sur la fenêtre de login OSX. Mais sous le capot, côté UNIX, côté droits sur les fichiers, il y a bien plus d'utilisateurs UNIX qu'il peut le laisser paraà®tre. Par exemple il peut y avoir l'utilisateur "root", l'utilisateur "system", l'utilisateur "www" associé à Apache, l'utilisateur "postgres" associé à PostgreSQL, et j'en passe un sacré paquet.
Donc après ce que tu décris est tout à fait normal : - l'utilisateur "postgres" existe bel et bien, c'est pour ça qu'il te le dit d'ailleurs quand tu essayes de le recréer (pas avec les préférences système j'espère ?! va pas créer tout un compte OSX avec une petite maison et tout pour cet utilisateur... qui de toute façon existe déjà , alors qu'il lui suffit d'une entrée dans la base NetInfo avec des droits associés). Il n'apparaà®t pas dans les préférences système "Comptes" mais il existe en tant qu'utilisateur UNIX - Comme tu sembles éditer ton fichier avec ton compte "Admin", auquel est associé l'utilisateur UNIX "admin", quand tu resauves le fichier c'est cet utilisateur qui prend la possession et applique les droits sur le fichier, c'est normal. Il suffit de remettre "postgres" comme utilisateur du fichier ensuite
Au passage comme on l'a mentionné précédemment dans un autre post, si tu veux modifier des fichiers de postgres lors de l'installation de ton logiciel, le mieux est un script shell (utilisant sed par exemple) que tu fais exécuter comme script postflight à ton installeur. Installeur qui aura pris soin de demander à l'utilisateur qui l'exécute son mot de passe admin et aura les privilèges admin pour faire ce qu'il faut.
Sinon tous ce résume à cette ligne non ? (raccourci de lignes de commande que tu m'avais communiqué). [glow=yellow,2,300]sudo -u postgres sed s/trust/md5/ /Library/PostgreSQL8/data/pg_hba.conf[/glow]
Il ne devrait alors pas toucher à l'utilisateur du fichier, non ?
Merci pour toutes ces infos sur les utilisateurs, j'avoue que pour moi la persévérance remplace la compétence pour l'instant :P
2 questions : - Si je coche comme conseillé par wisky je peux virer les sudo ? - Vu que l'avant-dernière ligne remet postgres comme utilisateur du fichier, cela supprime-t'il admin ? Si oui comment cela se fait-il que la dernière ligne passe ? Grace au sudo ? Ou bien l'admin a toujours le même accès donné à tous via la première ligne (a+rwx), accès perdu cette fois pour de bon juste après grace au -rwx.
Enfin dernière question, comment intégrer ça en cocoa, car il faut que mon projet cré un nouvel utilisateur et donne un mot de passe à ce-dernier et à l'utilisateur postgres avant d'exécuter toutes ces lignes.
- Vu que l'avant-dernière ligne remet postgres comme utilisateur du fichier, cela supprime-t'il admin ? Si oui comment cela se fait-il que la dernière ligne passe ? Grace au sudo ? Ou bien l'admin a toujours le même accès donné à tous via la première ligne (a+rwx), accès perdu cette fois pour de bon juste après grace au -rwx.
Avec les droits "sudo", l'admin a accès à tout et by-passe tous les droits (ACL comprises).
Enfin dernière question, comment intégrer ça en cocoa, car il faut que mon projet cré un nouvel utilisateur et donne un mot de passe à ce-dernier et à l'utilisateur postgres avant d'exécuter toutes ces lignes.
ça n'a absolument rien à voir avec Cocoa puisque c'est fait au niveau des scripts dans l'installateur (preflight et postflight).
Grande nouvelle, ça y est ce satané postgreSQL fonctionne, enfin il faut que je cré le package d'instal mais ce ne doit pas être bien compliqué, et confirmez moi, via ce package je peux en fin d'installation lancer l'exécution de plusieurs lignes de commandes shell ?
Si oui, tout ça ne fut pas une mince affaire, le résultat semble tout simple, mais quel travaille que d'en arriver là .
- Installer postgreSQL grace au package postgreSQL 8.3.0. Ca évite beaucoup de travail, toute l'initialisation du serveur, et met les fichiers où il faut notament postgreSQL dans les StarupItem pour un démarrage du serveur au démarrage du mac.
- Après l'installation :
#Démarrer le serveur fraichement installé Ordinateur:~ admin$ sudo /Library/StartupItems/PostgreSQL/PostgreSQL start #Ouvrir l'accès au dossier data, sinon seul l'utilisateur postgreSQL "postgre" peut y accéder. Ordinateur:~ admin$ sudo -u postgres chmod -R a+rwx /Library/PostgreSQL8/data #Modification de pg_hba.conf pour activer la sécurisation de la base par mots de passe cryptés Ordinateur:~ admin$ cd /Library/PostgreSQL8/data Ordinateur:data admin$ mv pg_hba.conf pg_hba.conf.bak Ordinateur:data admin$ sed s/trust/md5/ pg_hba.conf.bak >pg_hba.conf #Remettre postgres comme utilisateur de data Ordinateur:data admin$ sudo chown -R postgres /Library/PostgreSQL8/data #Retirer les autres accès à data Ordinateur:data admin$ sudo chmod -R go-rwx /Library/PostgreSQL8/data
et encore une fois il a été précisé ici que les sudo sont inutiles à partir du moment où l'on coche l'option d'identification lors de la création du package d'install.
et encore une fois il a été précisé ici que les sudo sont inutiles à partir du moment où l'on coche l'option d'identification lors de la création du package d'install.
Ben oui et du coup tes deux chmod aussi devrait être inutiles je pense... Et puis heu... si tu modifies la conf, faut p'tet mieux le faire AVANT de démarrer le serveur postgresql non ? Donc ton script shell devrait plutôt faire juste ça (dans l'ordre) : mv, sed, puis start.
Je fais remonter le sujet juste pour témoigner de l'efficacité de PostgreSQL sur Mac. Le moteur ne bouffe quasiment aucune ressource. Je fais "tourner" trois bases avec une dizaine de clients connectés au serveur (un vieux MacMini G4 avec 1 Go de RAM).
Concernant l'installation d'une application avec un serveur PostgreSQL, je ne m'y suis pas attelé mais Cogilog réalise cela de façon totalement transparente avec sa suite de logiciels de gestion (Paye, compta, gestion, TVA, immo, etc.) qui se connectent tous sur la même base. L'installeur permet d'installer une version monoposte ou serveur sans manipulation particulière. Il y a des versions de démonstration sur le site de l'éditeur. On doit pouvoir scruter le contenu du paquet et y trouver des trésors.
Pour ma part, la seule difficulté que j'ai trouvée est la quasi absence de framework pour accéder à la base avec Cocoa. La plupart des trucs sont des enrobages des lib C, des Frameworks au tarif exorbitant (699€HT) et qui ne sont même pas mis à jour (ne fonctionne plus avec Leopard et machine Intel).
J'utilise le PGSQLkit qui semble éternellement en version alpha non documentée.
Sinon, Realbasic, qui a été évoqué, propose un plugin pour accéder à une base PostgreSQL. ça fonctionne très bien, j'ai développé trois applications dédiées à mon métier avec. J'en suis content mais je regrette son interface vieillotte et le fait qu'il utilise encore Carbon. La version 2009 devrait enfin s'ouvrir à Cocoa.
Je me suis mis à Cocoa il y a quelques mois, j'ai mis longtemps à comprendre les concepts du couple objective-C/Cocoa mais le déclic a eu lieu et je progresse enfin beaucoup plus vite. Merci beaucoup aux contributeurs du forum.
Réponses
Dans la même phrase SQLite et payant c'est sûr ça fait bizarre :P
Il semble que ce produit (je me suis procuré une beta récente) permette les écritures concurrentielles sans risque d'aucune sorte (basé sur MVCC). ça mérite tout de même le coup d'oeil (avant de dire que c'est nul) et du coup, explique peut-être le prix...
Oui ça on m'a déjà fait le coup, et une simple facturation à 6 postes connectés a fait exploser ce genre d'argument...
Encore une fois, je n'ai pas d'actions de cette boite. M'en tape que ce soit super ou pas. La question était de savoir s'il existait un server simplissime à installer, au dessus d'un moteur type SQLite: il semble que oui. A creuser pour qui est éventuellement intéressé. Pour le reste, je n'ai pas d'états d'âmes: si ce n'est que faire le Client/Server DB avec Soap... c'est encore bien pour récupérer la température qu'il fait à Melbourne ou le cours de l'action Google.. mais pour faire une appli de bases de données, c'est pas sérieux. Mais ce n'est qu'un avis... pas une déclaration de principe ;-)
Pinus
D'autant que HFS+ n'a pas de techno de Snapshot !
À moins d'avoir bidouillé les sources de SQLite pour avoir un fichier journal par connexion, mais dans ce cas la licence les aurait obligés à fournir les modifications.
ça dépend du nombre de connexion fait par client à la seconde aussi... Là pour son cas, c'est au grand maximum pas plus de quelques connexions par minute, faut pas exagérer
Rien ne dit dans la page que ça utilise SQLite au fait :P
[Edit] C'est dit ici :
http://www.macgeneration.com/news/voir/121743/lancement-de-real-sql-server
Mais supporte-t-il l'encryption ? Mystère...
Pour ça par contre, détrompe toi... J'ai bossé sur une appli de backup CDP qui utilise gSOAP avec un MSSQL server derrière et qui peut bien supporter 1000 posts clients qui balancent des requêtes rapidement et simultanément :fouf):
Je suppose qu'il y en a plusieurs dans le tas qui l'utilisent avec des bases de données diverses et variées...
Par ailleurs, j'ai obtenu une beta de la version 2009 qui est bien MVCC et qui tourne nickel avec plusieurs clients écrivant dans la base. Cette base est bien une base SQLite (j'ai pu l'ouvrir et la manipuler sans problème dans SQLite Maestro).
Maintenant, en effet, ce n'est pas opensource, et ce n'est peut-être pas la solution recherchée initialement, même si ce serveur s'installe et est fonctionnel en un seul clic, comme recherché au départ...
Encore une fois, je suis de loin un meilleur supporter de PostgreSQL.
Pinus.
À voir les performances et la tronche de la base après.
Il y a PostgreSQL, qui respecte la norme SQLxx, et les autres. Les autres sont tous plus ou moins merdiques, plus ou moins payant (à terme) et ne respectent pas la norme SQLxx.
Il est faux de dire qu'il est plus compliqué d'installer et d'administrer pgsql que les autres. Il y a de très bons outils, dont pgadmin sur mac.
Mais, je ne comprends pas pourquoi il n'y a pas une interface, robuste, stable et simple, cocoa-pgsql ?
Je suis prêt à participer à un groupe, qui s'intéresserait à une telle interface, pusique je constate que la demande existe.
Bien à vous
PostgreSQL installe un dossier "data" contenant entre autre un fichier pg_hba.conf qui contient les autorisations, les règles (mot de passe ou mode trust, codage md5...). Dès que je touche à ce fichier le serveur ne démarre plus, et là je viens de faire une manip assez troublante.... Je vais finir par croire qu'il existe une poupée vaudou quelque part à mon nom...
- La fenêtre du dossier "data" est ouverte, je déplace pg_hba.conf sur le bureau. Plus de fichier pg_hba.conf dans "data" le serveur ne démarre plus, ok, normal.
- Je remet le fichier pg_hba.conf sans y avoir touché. OK le serveur redémarre, normal. Ca parait idiot mais attendez la suite.
- Je le remet sur le bureau (donc l'enlève de "data"), le duplique, j'en fais une copie, apparait d'ailleurs cette copie sur le bureau avec "-copie". Je place cette copie dans le dossier "data" et renomme en pg_hba.conf, sans "-copie" : plus de démarage du serveur !!!! C'est exactement le même fichier je ne l'ai pas modifié !!!
- J'enlève cette copie remet l'original (bien que les 2 fichiers soient rigoureusement identiques) et ... le serveur remarche !!!
Argh.. Je deviens fou là ??? Quelqu'un a une idée de génie ?? Merci
PS : je sais que je suis un peu hors sujet par rapport à ce forum mais comme je l'ai déjà dis je pense que c'est ici que se trouve les cerveaux les plus aptes à trouver des solutions aux problèmes qui me rendent fou... Et si tout ça abouti à une utilisation de postgreSQL avec Cocoa et sans souffrance...
Sinon, avec ta manip du fichier conf dupliqué, regarde les droits de la copie, et éventuellement, autorise cette copie pour tout le monde (sous Finder, affiche les infos du fichier conf-copie, et dans la section des autorisations, autorise lecture et écriture à tout le monde. Puis réessaie de démarrer PGSQL avec la copie).
Si la machine sur laquelle il faut installer le serveur fait déjà tourner un server PostgreSQL, tu fais comment ? Tu bousilles son installation et ses bases avec ton installateur ? :P
Ou tu fais tourner un autre serveur PostgreSQL sur un autre port et avec les bases intallées à un autre endroit ?
Alors Schlum tu mets le doigts sur un point auquel je n'ai absolument pensé et dont il faut absolument que je tienne compte...Merci
No, que dire, tu viens de résoudre un casse-tête auquel je ne voyais aucune solution, qui était incompréhensible, merci, merci, merci (je l'écrirais bien 1000 fois mais ça va faire long :P )
Mais si mac os x fait un peu n'importe quoi là , pas très grave suffit après avoir modifié le fichier remettre l'autorisation postgres et ça devrait être bon, je vais essayer, tout en ligne de commande, restera plus qu'à tout passer en cocoa... Si je peux avec NSTask envoyer un fichier de ligne de commande au shell ce serait impec mais il y a des sudo...
- Les utilisateurs au sens UNIX, qui ont un uid, un (ou plusieurs ?) groupes avec un gid, et un nom court
- Les utilisateurs au sens OSX, c'est à dire ceux qui ont des comptes dans MacOSX, affichés dans les préférences système "Comptes", et auxquels est associé une "petite maison" pour chacun.... et un utilisateur UNIX associé aussi
Du coup dans les préférences système "Compte" tu ne vois que les comptes utilisateurs "pratiques", ceux qui ont une petite maison et peuvent ouvrir une session quand tu démarres MacOSX ou revient sur la fenêtre de login OSX. Mais sous le capot, côté UNIX, côté droits sur les fichiers, il y a bien plus d'utilisateurs UNIX qu'il peut le laisser paraà®tre. Par exemple il peut y avoir l'utilisateur "root", l'utilisateur "system", l'utilisateur "www" associé à Apache, l'utilisateur "postgres" associé à PostgreSQL, et j'en passe un sacré paquet.
Donc après ce que tu décris est tout à fait normal :
- l'utilisateur "postgres" existe bel et bien, c'est pour ça qu'il te le dit d'ailleurs quand tu essayes de le recréer (pas avec les préférences système j'espère ?! va pas créer tout un compte OSX avec une petite maison et tout pour cet utilisateur... qui de toute façon existe déjà , alors qu'il lui suffit d'une entrée dans la base NetInfo avec des droits associés). Il n'apparaà®t pas dans les préférences système "Comptes" mais il existe en tant qu'utilisateur UNIX
- Comme tu sembles éditer ton fichier avec ton compte "Admin", auquel est associé l'utilisateur UNIX "admin", quand tu resauves le fichier c'est cet utilisateur qui prend la possession et applique les droits sur le fichier, c'est normal. Il suffit de remettre "postgres" comme utilisateur du fichier ensuite
Au passage comme on l'a mentionné précédemment dans un autre post, si tu veux modifier des fichiers de postgres lors de l'installation de ton logiciel, le mieux est un script shell (utilisant sed par exemple) que tu fais exécuter comme script postflight à ton installeur. Installeur qui aura pris soin de demander à l'utilisateur qui l'exécute son mot de passe admin et aura les privilèges admin pour faire ce qu'il faut.
Sinon tous ce résume à cette ligne non ? (raccourci de lignes de commande que tu m'avais communiqué).
[glow=yellow,2,300]sudo -u postgres sed s/trust/md5/ /Library/PostgreSQL8/data/pg_hba.conf[/glow]
Il ne devrait alors pas toucher à l'utilisateur du fichier, non ?
Merci pour toutes ces infos sur les utilisateurs, j'avoue que pour moi la persévérance remplace la compétence pour l'instant :P
Ordinateur:~ admin$ sudo -u postgres chmod -R a+rwx /Library/PostgreSQL8/data
#"Password:"
Ordinateur:~ admin$ cd /Library/PostgreSQL8/data
Ordinateur:data admin$ mv pg_hba.conf pg_hba.conf.bak
Ordinateur:data admin$ sed s/trust/md5/ pg_hba.conf.bak >pg_hba.conf
Ordinateur:data admin$ sudo chown -R postgres /Library/PostgreSQL8/data
Ordinateur:data admin$ sudo chmod -R go-rwx /Library/PostgreSQL8/data
2 questions :
- Si je coche comme conseillé par wisky je peux virer les sudo ?
- Vu que l'avant-dernière ligne remet postgres comme utilisateur du fichier, cela supprime-t'il admin ? Si oui comment cela se fait-il que la dernière ligne passe ? Grace au sudo ? Ou bien l'admin a toujours le même accès donné à tous via la première ligne (a+rwx), accès perdu cette fois pour de bon juste après grace au -rwx.
Enfin dernière question, comment intégrer ça en cocoa, car il faut que mon projet cré un nouvel utilisateur et donne un mot de passe à ce-dernier et à l'utilisateur postgres avant d'exécuter toutes ces lignes.
Oui, je sais ça fait 3 questions
Oui
Avec les droits "sudo", l'admin a accès à tout et by-passe tous les droits (ACL comprises).
ça n'a absolument rien à voir avec Cocoa puisque c'est fait au niveau des scripts dans l'installateur (preflight et postflight).
Si oui, tout ça ne fut pas une mince affaire, le résultat semble tout simple, mais quel travaille que d'en arriver là .
- Installer postgreSQL grace au package postgreSQL 8.3.0. Ca évite beaucoup de travail, toute l'initialisation du serveur, et met les fichiers où il faut notament postgreSQL dans les StarupItem pour un démarrage du serveur au démarrage du mac.
- Après l'installation :
#Démarrer le serveur fraichement installé
Ordinateur:~ admin$ sudo /Library/StartupItems/PostgreSQL/PostgreSQL start
#Ouvrir l'accès au dossier data, sinon seul l'utilisateur postgreSQL "postgre" peut y accéder.
Ordinateur:~ admin$ sudo -u postgres chmod -R a+rwx /Library/PostgreSQL8/data
#Modification de pg_hba.conf pour activer la sécurisation de la base par mots de passe cryptés
Ordinateur:~ admin$ cd /Library/PostgreSQL8/data
Ordinateur:data admin$ mv pg_hba.conf pg_hba.conf.bak
Ordinateur:data admin$ sed s/trust/md5/ pg_hba.conf.bak >pg_hba.conf
#Remettre postgres comme utilisateur de data
Ordinateur:data admin$ sudo chown -R postgres /Library/PostgreSQL8/data
#Retirer les autres accès à data
Ordinateur:data admin$ sudo chmod -R go-rwx /Library/PostgreSQL8/data
et encore une fois il a été précisé ici que les sudo sont inutiles à partir du moment où l'on coche l'option d'identification lors de la création du package d'install.
Et puis heu... si tu modifies la conf, faut p'tet mieux le faire AVANT de démarrer le serveur postgresql non ?
Donc ton script shell devrait plutôt faire juste ça (dans l'ordre) : mv, sed, puis start.
- Pour le start, heu... ui, bon ok, d'accord, pas faux...
Concernant l'installation d'une application avec un serveur PostgreSQL, je ne m'y suis pas attelé mais Cogilog réalise cela de façon totalement transparente avec sa suite de logiciels de gestion (Paye, compta, gestion, TVA, immo, etc.) qui se connectent tous sur la même base. L'installeur permet d'installer une version monoposte ou serveur sans manipulation particulière. Il y a des versions de démonstration sur le site de l'éditeur. On doit pouvoir scruter le contenu du paquet et y trouver des trésors.
Pour ma part, la seule difficulté que j'ai trouvée est la quasi absence de framework pour accéder à la base avec Cocoa. La plupart des trucs sont des enrobages des lib C, des Frameworks au tarif exorbitant (699€HT) et qui ne sont même pas mis à jour (ne fonctionne plus avec Leopard et machine Intel).
J'utilise le PGSQLkit qui semble éternellement en version alpha non documentée.
Sinon, Realbasic, qui a été évoqué, propose un plugin pour accéder à une base PostgreSQL. ça fonctionne très bien, j'ai développé trois applications dédiées à mon métier avec. J'en suis content mais je regrette son interface vieillotte et le fait qu'il utilise encore Carbon. La version 2009 devrait enfin s'ouvrir à Cocoa.
Je me suis mis à Cocoa il y a quelques mois, j'ai mis longtemps à comprendre les concepts du couple objective-C/Cocoa mais le déclic a eu lieu et je progresse enfin beaucoup plus vite. Merci beaucoup aux contributeurs du forum.