Reconfig Fedora 14
Fermé
akalook
Messages postés
29
Date d'inscription
mardi 21 juillet 2009
Statut
Membre
Dernière intervention
4 mars 2012
-
Modifié par akalook le 27/08/2011 à 19:27
akalook Messages postés 29 Date d'inscription mardi 21 juillet 2009 Statut Membre Dernière intervention 4 mars 2012 - 23 oct. 2011 à 20:04
akalook Messages postés 29 Date d'inscription mardi 21 juillet 2009 Statut Membre Dernière intervention 4 mars 2012 - 23 oct. 2011 à 20:04
A voir également:
- Reconfig Fedora 14
- Android 14 - Guide
- Fifa 14 - Télécharger - Sport
- Macos 14 - Guide
- Iphone 14 simple - Guide
- Faux iphone 14 pro max - Guide
4 réponses
synopsis8
Messages postés
1364
Date d'inscription
dimanche 15 mars 2009
Statut
Membre
Dernière intervention
1 juin 2013
243
Modifié par synopsis8 le 27/08/2011 à 20:49
Modifié par synopsis8 le 27/08/2011 à 20:49
Bonsoir Akalook,
Ta question est TRÈS pertinente.
Non, il n'existe pas de moyens de revenir à un instant donné X, si ce n'est de faire une restauration de la partie système.
En revanche, tu soulèves ici la nécessité d'un process encore trop peu abordé en école d'Ingénieurs car les professeurs n'ont eux-mêmes souvent qu'une connaissance théorique du sujet.
À savoir le
Le change management fait partie de la norme ITIL qui décrit les best-practices dans un système d'informations.
La norme ITIL contient plusieurs process, si tu te destines à un métier d'ingénieur système, tu seras confronté aux modules du groupe "Service support" de la norme ITIL.
En priorité, je te recommande de TRÈS bien t'informer sur les modules suivants :
- Incident management (les request en font partie, c? se traite comme des incidents, avec des business impact, et des priorités)
- Problem management
- Change management
- Release management
- Configuration management (s'il te reste du temps).
Et aussi, il te faut connaitre un peu comment on implémente ces modules
Les autres modules, tu pourras les apprendre plus tard.
Cela ne va rien faire d'autre que conditionner ta capacité à intégrer un grand groupe ou non lors de ton entrée sur le marché.
1 ) Soit tu connais les modules que je t'ai cité de la norme ITIL, et tu auras la possibilité de demander un stage dans un grand groupe en fin de cycle universitaire.
2 ) Soit, tu ne connais pas ITIL, et quand tu chercheras du boulot, tu n'auras pas d'autre choix que de te faire recruter par une SSII dont le directeur régional aura une arrogance inversement proportionnelle au salaire qu'il te donnera.
Moi, un CV où je ne vois pas ITIL marqué dessus, je lis en verticale et encore si je suis bien luné.
Pour être franc avec toi, quand tu sortiras de l'école, ton CV de base ne présentera aucun intérêt pour un DSI qui obtiendra sans soucis un indien qui bossera à n'importe quelles heures depuis Bangalore avec un salaire 12 fois inférieur à tes prétentions, une expérience professionnelle acquise et un meilleur niveau technique que le tien (parce qu'il aura lui suivi des tas de formations payantes délivrées par IBM ou je ne sais qui, et qui parlera l'Anglais comme deuxième langue maternelle puisque c'est la 2eme langue officielle en Inde.
Si en revanche, tu es capable de montrer que tu sais comprendre le langage d'une équipe technique, donc la problématique est de délivrer largement plus de 99% dans les décimales en disponibilité système, et si tu t'y prends à l'avance, tu pourras espérer un stage dans un grand groupe et éventuellement un poste à la clé, pourquoi pas.
Je te le souhaite en tout cas.
Vieux Core 2 Duo cadencé à 3GHZ avec 6 GB de Ram.
Ta question est TRÈS pertinente.
Non, il n'existe pas de moyens de revenir à un instant donné X, si ce n'est de faire une restauration de la partie système.
En revanche, tu soulèves ici la nécessité d'un process encore trop peu abordé en école d'Ingénieurs car les professeurs n'ont eux-mêmes souvent qu'une connaissance théorique du sujet.
À savoir le
change management,et sa traçabilité.
Le change management fait partie de la norme ITIL qui décrit les best-practices dans un système d'informations.
La norme ITIL contient plusieurs process, si tu te destines à un métier d'ingénieur système, tu seras confronté aux modules du groupe "Service support" de la norme ITIL.
En priorité, je te recommande de TRÈS bien t'informer sur les modules suivants :
- Incident management (les request en font partie, c? se traite comme des incidents, avec des business impact, et des priorités)
- Problem management
- Change management
- Release management
- Configuration management (s'il te reste du temps).
Et aussi, il te faut connaitre un peu comment on implémente ces modules
Les autres modules, tu pourras les apprendre plus tard.
Cela ne va rien faire d'autre que conditionner ta capacité à intégrer un grand groupe ou non lors de ton entrée sur le marché.
1 ) Soit tu connais les modules que je t'ai cité de la norme ITIL, et tu auras la possibilité de demander un stage dans un grand groupe en fin de cycle universitaire.
2 ) Soit, tu ne connais pas ITIL, et quand tu chercheras du boulot, tu n'auras pas d'autre choix que de te faire recruter par une SSII dont le directeur régional aura une arrogance inversement proportionnelle au salaire qu'il te donnera.
Moi, un CV où je ne vois pas ITIL marqué dessus, je lis en verticale et encore si je suis bien luné.
Pour être franc avec toi, quand tu sortiras de l'école, ton CV de base ne présentera aucun intérêt pour un DSI qui obtiendra sans soucis un indien qui bossera à n'importe quelles heures depuis Bangalore avec un salaire 12 fois inférieur à tes prétentions, une expérience professionnelle acquise et un meilleur niveau technique que le tien (parce qu'il aura lui suivi des tas de formations payantes délivrées par IBM ou je ne sais qui, et qui parlera l'Anglais comme deuxième langue maternelle puisque c'est la 2eme langue officielle en Inde.
Si en revanche, tu es capable de montrer que tu sais comprendre le langage d'une équipe technique, donc la problématique est de délivrer largement plus de 99% dans les décimales en disponibilité système, et si tu t'y prends à l'avance, tu pourras espérer un stage dans un grand groupe et éventuellement un poste à la clé, pourquoi pas.
Je te le souhaite en tout cas.
Vieux Core 2 Duo cadencé à 3GHZ avec 6 GB de Ram.
akalook
Messages postés
29
Date d'inscription
mardi 21 juillet 2009
Statut
Membre
Dernière intervention
4 mars 2012
3
28 août 2011 à 18:16
28 août 2011 à 18:16
Merci pour les conseils.Je ne le savais pas, et je vous promets que je m y mets pour savoir ce qui ce cache derrière.
je vous dis de mes nouvelles bientôt...
je vous dis de mes nouvelles bientôt...
akalook
Messages postés
29
Date d'inscription
mardi 21 juillet 2009
Statut
Membre
Dernière intervention
4 mars 2012
3
23 oct. 2011 à 20:04
23 oct. 2011 à 20:04
Bonjour,
juste mettre dans le mode non graphique et vous pourrez voir les processus en cours d'exécution. J'ai pu remarquer que le processus send mail était trop lent au démarrage et je l'ai supprimé...Et maintenant cela marche nickel
a+
juste mettre dans le mode non graphique et vous pourrez voir les processus en cours d'exécution. J'ai pu remarquer que le processus send mail était trop lent au démarrage et je l'ai supprimé...Et maintenant cela marche nickel
a+
jeanbi
Messages postés
15118
Date d'inscription
samedi 9 décembre 2006
Statut
Contributeur
Dernière intervention
6 février 2023
2 181
28 août 2011 à 19:03
28 août 2011 à 19:03
bonjour,
juste comme ça en passant , sur fedora , il me semble que si je modifie un fichier de configuration une copie est créer par le system
de plus il me semble que lorsque l'on bricole des fichiers de configuration la moindre des choses est d'en faire une copie ce qui me semble être la base de toute modification d'un systeme sans risque de perte de données
ce qui revient à dire que si je doit modifier par exemple mon /etc/fstab
il est judicieux avant de le modifier de taper par exemple
cp /etc/fstab /etc/fstaboriginal
ce qui de plus permet de comprendre ce qui a été modifier
a+
juste comme ça en passant , sur fedora , il me semble que si je modifie un fichier de configuration une copie est créer par le system
de plus il me semble que lorsque l'on bricole des fichiers de configuration la moindre des choses est d'en faire une copie ce qui me semble être la base de toute modification d'un systeme sans risque de perte de données
ce qui revient à dire que si je doit modifier par exemple mon /etc/fstab
il est judicieux avant de le modifier de taper par exemple
cp /etc/fstab /etc/fstaboriginal
ce qui de plus permet de comprendre ce qui a été modifier
a+
