-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jaboatão dos Guararapes, PE, 24 de setembro de 2014. Assunto: GnuPG (versão 2.0.26) - Configurações - Parte IV (emit-version) Percebi que o comportamento do aplicativo GnuPG mudou com a instalação da versão 2.0.26. Antes, com a versão 2.0.22, a informação de versão era colocada automaticamente, por padrão, na assinatura emitida no modo 'armor', conforme o exemplo abaixo: - -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJUC7pbAAoJECrgJcAIqGGAIEcH/i7N272Biy8QCmPYfxhnCDN6 K3TyMLMhUp6TrmrQdN5AQ+ULr0rVAk/87u9wwc9Cc8fF8FLr+OA6klje5+7SqqLj mBPTHWRpHTO+3Ixae1yGj4VEeCySjg0JSkEtN6tZ7lFZDk5pEtURZSn919XPWepK 9AHoYab8VJ7xv6amL7j+mVf6OmTbYXcx8Ik3AAdzsVP0BVh2InG3zky2+j99AWOo ewZ6lU3lttpNs+4i/kXMnmMslFVIGHE2CCU6SN9receozBzaFnl+ITz4XfFjLCgC hUL6HB1I/VuaNl7imifpFljadNFVCxCA+KhkJ8lhiQQhmYjFV435wo2aPIEyLeI= =4bGK - -----END PGP SIGNATURE----- - -------------- Agora, com a versão 2.0.26 do software, a saída _padrão_ é semelhante a esta: - -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUIw2uAAoJECrgJcAIqGGAhUQIAIMje8l/43l4jcHz56L79bNo GwttwnvHlQrC6Y73TWb+gvy3R216XE12CiVYLgaUH8F+TVimn5X255cnDfjYJH0a TEAojjds0He4L2G6rHbRpATPBod/cjFeJaYwRdeZlaW2keIVx/4zC/CljGSMq2Qe 2jt1ifbM8pgFaonQNDCXh/YnwftpjCmt0KyZgCUPm8PIuv3WqUeTFi8FrjMaUwMW MxgRtXgk9gPR6Cgmy/HWV83bRKFEnz9GMIRRh43dowEk3ctTGbi+W50MlPZDeKk1 hi76uXvTECGG9B66H9G/bVxoDknlsS38PB9rj8wB/pisyN5AOCsERSPlxNTf3iM= =4yCB - -----END PGP SIGNATURE----- - -------------- Pergunta: Como obter a informação de versão completa como antes? Resposta: com a opção de configuração (emit-version) incluída no arquivo de configuração do GnuPG (por padrão ~/.gnupg/gpg.conf). Obs.: curiosamente, é obrigatório que se coloque a opção 'emit-version' _três vezes_ no arquivo de configuração para se ter a informação de versão efetivamente _completa_. - -------------- Se colocar apenas _duas_, então a saída se parecerá com isto (retirou a informação de Sistema Operacional): - -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.26 iQEcBAEBCAAGBQJUIw/4AAoJECrgJcAIqGGAzVgH/Azxn7Nz3A6qRhlnM8wEIWLd RGR0mbfcn4tSnyZdtAJDKPV6mYnd+ZhlkLws27BL3nUqkd7afoqF9D3lHSABCQxF VM+X12Ot8zeqAf1zHLWnjTZYDU2p55qMJPMVTrTblP3/MzKboGcOEqDQsABsZNaJ y6y88GyE8kHZbcyRHdiSNTunfDkjLl4vZPvs0gBTLTJrw44/TQiwC7qWAjMr7TQE S+yOiqREo9jr7rvD/E9R64meuW2h7KIOYG6G6LU1ZyMXjTF7H/N4AJb96RTEEv1o 0wV2DphYuhIJ7cxIeI56deSniGsC8v3wxdy+AzCBXb+ZEiU0z+lAv2Es22ZdHAU= =N3nc - -----END PGP SIGNATURE----- - -------------- Se colocar apenas _uma_, então a saída se parecerá com isto (retirou a informação de versão chamada 'número menor'): - -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 iQEcBAEBCAAGBQJUIxCPAAoJECrgJcAIqGGA28oH/2EPQQ3GNy8J+PVbLhy8smZU RGHSymuSN8FMo5M5pj9VodRJePDckvQto9dE4KjHCSvFsL2/GHE5Pp1Jrbuolmqx 7hS6FZnTIUj8PexoUSckgQ6ZkRvSYpC8qAhYr0QT1s5hLknROKrGEh3Yrc6IiRZJ vxVJ7WV1IFqVCfngValJWjh3MYbfLzyxtqZREkkj2hJG6DFHprqQEnoCjZBjacab osrMwuPTn2qVC8jMn/J/IxLc8fZgm5mXN6C3sMm78qm5o37tVMM518ddyrvJIw9c sh57sVMdQhyTXM/55uZdhdBEKDaKYbA73fybLajgO/NgZ6utJgrCfZ+LnSzU4no= =pTvI - -----END PGP SIGNATURE----- - -------------- Informando-se _três_ vezes a opção 'emit-version', a saída da assinatura no modo 'armor' voltará a ser _completa_: - -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.26 (GNU/Linux) iQEcBAEBCAAGBQJUIxEbAAoJECrgJcAIqGGAjBMH/3fRVUgT5PVN8BT7Q2kwmXXm 24c9kuIAG5PrbNOEnczcK1+xMG1Wa4U0tS7xdiO2WbxJz3drkUxRw5ckQx92OrT/ +DRNwpYYiqaO6qw3C/cjLdQVcr/YK+c+WYYq2wqQ6r9qIzjDd98Vhiw1T5a/43y/ Cd8AAfm0XUy1OtNMzr0J+xgCGXi8GG7BFNnoYEdmax0qr8UyuQkojXqZq+E0npnn Y9vbkz5JPUaTUl5gVk2SSy5J/dHWl7AielgblsqVqV+oMB15PeYm9tc0FmYr81zA imh0ksipq9m/x1IlaiY3amgrJhEJvk921JHV73yKbxqxX75wplGn/QF4OJLfjWo= =7ErL - -----END PGP SIGNATURE----- - -------------- Agora, você decide qual 'layout' mais te agrada (eu ainda prefiro a informação _completa_, como antes). Jamenson Ferreira Espindula de Almeida Melo Usuário Linux nº 166197 https://linuxcounter.net/cert/166197.png Impressão digital da chave: 234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.26 (GNU/Linux) iQEcBAEBCAAGBQJUIxTaAAoJECrgJcAIqGGAxWQH/if65aDpsKue/k3v/v0lio0x w4gpnq9hPp1xfesAkwjZ6V3GwVOm0keKfbup/0Nt4TJFREbt9/W8MRjHqtoRWPJL JcKZIMusVbe8VqggoLpaoIdKn6RHpONCKy2h5WsJDtNGV7yeuMxgI8kyta8/0N5/ u9rWJZq/Yz9az9+KjQJBjGV4X0PIwTzR1EJ5snq85Ksc7Utu1lFP5nM4yVhatnnS 5Q3pSBi/EjmKikHrcRwIDppimf+SzeMarPEAgpStLucXZHdY9iHGy8wThXaegpqL sZkBJx/aU/mAoSeX1VBZrBpvokcxOwO5999Uk/xTDDjXPDGchYU/M3L2Lx5bXRQ= =pKjE -----END PGP SIGNATURE-----
quarta-feira, 24 de setembro de 2014
GnuPG (versão 2.0.26) - Configurações - Parte IV (emit-version)
Minha Chave Pública (formato OpenPGP)
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQENBFOWq5sBCACooPQ0WA48y8taHmTuW0YE0nxm+s9dHpv8nDiNXvt8jSI8GcDj ha3WqxU7Gn/8WSsK6uMzyIDFiQ1jzFJwQelSN0+yg32vx+aCXWjizJk4ShKHGmFE rrsG1dOsgfEJrFv+3tURchRO87utHq8WAjFp/n3Xq1YTEqdrShvJJwtOl9hOejDM mYTtvxHYVRgOnEuY71sTL/gbYfM9R9ym5AWtZO1+f1zQC6QZKgpAsUt3vakxbslL 0WzHi1T2q2ep9EYd8kGHrJGYZmU4+EfRcyPTQ+Cnhbc7IzDZX3vzQkz88cIugsfb tbancEGmwwjyi616EMOsrKlq+CK4/7GldTd5ABEBAAG0ZUphbWVuc29uIEZlcnJl aXJhIEVzcGluZHVsYSBkZSBBbG1laWRhIE1lbG8gKEFkdm9nYWRvLiBSZWNpZmUs IFBlcm5hbWJ1Y28sIEJyYXNpbCkgPGphZmVzcEBnbWFpbC5jb20+iQFBBBMBAgAr AhsDBQkDw65MAh4BAheAAhkBBQJT/iXpBgsJCAcDAgYVCAIJCgsEFgIDAQAKCRAq 4CXACKhhgLNcB/4oYjI9a+D0kBqpM2tFOltwRSk5urK3pmX3Y/ImM2Cry6GiEVwA G4oXBIPbJPLxdRSX4syAfMz86D4R3EHIIPTE+ygVbm9Ce8GZp7+aWB8ZXz095Uhg fquFIqSJdE+LdcuNEK8KRTuP+qtD14O0aHa/nH7QiFLpQrpeBPjHJ/TFhbzdJKwH A9ML1FqXfxzSPv8uCkfz0Qk+wjTappcG++2gjvHljZONYFfvh7DCGw+6iMv45/ov 3UCIGv7Q3Kvz3kPAuO4cJZm0Sf4fyVxoUJ/JaC+MxmIgT9yiuR/g0Rt32+uI4F3d rDgEfFUL6ejNW7F3ZoppkTwYic9z5UdepDXjiQEiBBABAgAMBQJT/jB9BQMAEnUA AAoJEJcQuJvKV618HDYH/jIDgM6S3IbZbpwfpNzh8c6KCTFLqqMBmlmLUAM8cFVh SXM9XV+O8cj2+AViDyObg1e6qbziK4jyZsSfDN9Rom8lMnY3CtbG0hqWWPoeTnFB QA6tRhWAEPnG8olX3jYGBSENh7PFoJBEPaOSvT6MEKqbNxnKkrnT6tjK70NglVPk P6vOhcj3gN/I+eY2UxL80H6eZ/KKP7329X2bvneHi+LCNdY5TLo614UGCDmCq/fp 86eI1lgC7OuF8+tX8QySdGzG2BzcAeyvPGKjE2gpkS1Ut2VcmP/niE3ZjMUE9uDb swxGXC+769wXf8jpP3bJKXhqK6cEeqKDHNQ+KfD7PXvR0UrRSAEQAAEBAAAAAAAA AAAAAAAA/9j/4AAQSkZJRgABAQEAyADIAAD//gATQ3JlYXRlZCB3aXRoIEdJTVD/ 2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQERXRTc4 UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2NjY2Nj Y2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wgARCADM AJ8DAREAAhEBAxEB/8QAGgAAAgMBAQAAAAAAAAAAAAAAAgMAAQQFBv/EABcBAQEB AQAAAAAAAAAAAAAAAAABAgP/2gAMAwEAAhADEAAAAe2QhCFAJiMokM0mw0LZCEIQ sohCk5RyBBRCywzedoesIQshRAU4BzQSFllglhGg9AaVhZCFJRwTmEBLGABlEGSj Y49GNWyESjlHDKglMMsXYyUy4tUWVZpPRrZCIJ5YRLol1zWodS0zJstKCUIxi0wb x6Q1LCJmPLGvOujnb6bYyw6hRUCBKELOPrn1K6qwiYjzJ0Mb6M0ymWNsslSKBBlC FHG3z6Z1i1iZzyg/OuznbabYywiqkUUDKuVCcbWOrZ1yLEA8oa8b2NOsfYQZdQGF gCpbjm3PQ1npkWkyTfEZ150MrKCV0unUdZQjNylWNLMlz0bNKuso5nPrztY3RWdZ 9TFrPYztkadQRWbm1MNzsx01M49Z1TZrv3yiYMdcKahi0MsuhzYWFZdlSiSM6Mbd c6tYiY89M8WaaOyAyomjsIodc2UKlWltPuH2RETWHO7R6t1LRWdKV2oaJzXahoKq yXYa6tYMtBXNnWQbnTtQhU1izTpiAuzWWWBC4lzppllkSijBmrzt9sBsAKKW7GDA YWmjWXVZCFJRllx406aliVl02y4AJl5QpnduGWQiUQUcvG2Z02hVbRWRakfcmiyr noakLIRIUUcXOpnTxilQwQdRFQpD3npVZCESAnOOLnT819ah9rLILhUZ4qXndcem HkIYUxHLEEl6HPpVjrHBS3QIEoS0c3ry1nZNqmnjEFRAIdLn1dmqs0SnEqilIw6x m6cxDHnVPPgFFEN2N9DGwUxpYJRE5m8Z94ohYQtFrRCGrOutjocojAkFbQK5e+eb WRLS1sWgLZRB8vZx0dLJSshIuhTjbxm1kQktaP/EACUQAAIBAwMFAQEBAQAAAAAA AAABAgMQEQQSIBMhIjEyMEEUM//aAAgBAQABBQLk5KJPVQQ9ZI/1VBauZHVkK0Jf rV1ZOo5PPDIpFLUyiU6sai/BvCr6hzG7K/vhCbg6NVVFz1Go38f5gXrHe9OeyVOa muOsqYVsG0URowRWUoPds7yhtMDRp6mypwZWnvmkRp5FRFRTOlElp4n+dkKKinTN iQ4I6XedPsaeW6leu9tJlKO4UbLm7Mn9aJ9r6r/g/dB3X4y9S96P3ess0mUftCsv wn6f1o/d36msSoRwOSRGojcjPFyR1IjqK1ZeejXjd1e+ox1YfLg2dJHgRYpWbGyW BRps6aI9iv7oeFJTy7SRXXlFdpdiMHMSkbDGCLJDRUpZpwpN1EnForoj8xV5fVWP mjGTYYMWiO2DBttUWYx9QvU+5WV2NkRifBj9FO9RErK8xkR2VmMZgisK7pHpp3l3 Uk2U5NE5PENwrOyjuajjlVWJIQ2ZttNouxkV6frlWXZCtKSTVU6h1DeR7iHaPzym sxEIlBM2o8TxZsRGCVmLu/wnJOSYmbsLCa2IUEYMjZkozj1OeqrqMKcjdgjIQrtj ZKVt/nSqKpC8tVTRU1pKpKYzPkjBGZ1TqnUOoOQkVHiMfVGs6coauDIyUrZtntan 3VkbUbTF6/qPoyQqOLhrLS4UrNC4srH84vhSfeJgS4sre/5+MPqPNlf7fH//xAAd EQABBQADAQAAAAAAAAAAAAABABARIDACEkBg/9oACAEDAQE/AfnIUZwopFYRGA8g 8g8g1NetoUPFSoUU5MEWFTYuFyeaGs0LhFDcuGFAx17IUDxaUTpKnwwuq6rquqI0 HkFp2HkDRaFCOYpDQ/LMY8sxjyzCGBt//8QAHREAAgMBAQADAAAAAAAAAAAAAREQ IDAAQCFQYP/aAAgBAgEBPwH9Q5VVIwPkPkPkOoq6/PPnLqIdBIgiBxoaCguKqRQ4 DESYNDA1XGhh87LlY2XLU1fPnz+hNFy5VGJ8hwcDM4jM4jM4jM4i3//EACYQAAED AwMDBQEAAAAAAAAAAAEAICERMDECEBJAQXEiMlBRkWH/2gAIAQEABj8CdJoolYAX uXZTpWbtNH6pL6ZCizUqgjTaqF/bHEYuAhVDuIsy0fTiWTbDNR2m8QzV0Gpmrx0G ppCrtlZdlZYWQqjbKkqNSy2SvcwfaowbnkqcZUNMShUR4UY2qoaLx6mvS5dmngqV CzX4AXQ8hmNu28XCdOG4dx72KaTJRFvkPtDUGZr4XoFFJqyFO+doZCmoUGvSVC9Q /Pjhf//EACYQAAICAgIDAAIBBQAAAAAAAAABESEQMUFRIGFxgZEwobHB0fH/2gAI AQEAAT8h8l0q+ilv/QwqY72QPT9Cky2/An/UzTxfTr+RuFLFKf2iXOb9lyWaNE+8 Gxehkwe+V1/CtzIS5Hkno7GM4kQgQ7EDRaF1sM6eu15twrHL/wBY3Y0RUCXJFjsJ sUCV2RMzhm1IT2/jry76e/g2QISpk7SNx/QSlaFqhO0okKhOQEse1MXg0IY1udYG fiObukQXBcEzmBi4f4LCGiW0LWQ4nRt6Qu6VmmSPlKH4PTbgez4gpKBLBeDygWmJ YZ0qfgk4C+BCwXkxjww8uPV68ID7G47ilgovBGWhkm8CNMns/t/BZZHrBtEOStm1 Y6E3gIJkkjYltB9AkbJlSiGfZA3t+FlQrsmbktro1DGQoQaR/wCUh1LGnJAPY3VN TP8AI4ttiOhrGSL2uBeA9HKuydnMECoZoShpqlxJCcVurKRCfQgRAxIqUjklIyxQ 3MCHM/RiSpK10NelEDTyugxtepFsZKDlCxcM1KsicHMgRCxLuEl/M0+i0emLZqRj TIujiFh5nNGreZ16CfsTHE8NRREYIwIeV4HQ9Ciy1JM+g7F1iTwoL4bQBHFhrv7I FDb2ZVZM5g51+Vx2MPhiO/AEGlDHsTz3HWDm2bcKeoIckOBqOnplGMcix5nfgmMU GEwk9CK1AjQkJnCNGSwwsK7F/By0cq1lYpKBg6BBDgsLM6/CvNuCJ1109Itb9wzD rTHJRKysNCdSxPJ0NSRyMbXT8NO3yGw19THsu+hnyxQQshunIjCRcjlppfSvB/Bo xzVDmZPG4m1lynoo0b+xNK09YuPVj4iRjjBEMjyh9SIdIiuB7FSGFHExWJQNMVEf nwa8pjitEZqLDQkaDWLfEkkkyWeeTUNByRAQQQR4bOOM85ZWHsShYQxDEGGmeMf/ 2gAMAwEAAgADAAAAENsln233lltlsm1pIlutslt+BDTaE9kl/wCm0msqp5J9ny9V B6XJJtYjpOceaNJu2ksCO3ltZ+u2NRu3+vp/8xNRZ7VNpt8Ytge8Ndr3ZxI784Td pWL8EqsSOmJ4gZTNi67zJr4f6FRo0w7mLS4xs+e25zBFL5iCnjJ9syEuGnFBLfp9 uV2pcZJ9kaRMWIEbJtsCudx53JLvssWUtpzJL7Zm2ofXltNrKh0oELjLdJK/iQAP xLLrY4qR52pPL7E4FGvNbNb/xAAgEQACAgMBAAIDAAAAAAAAAAAAARARICEwMUBB UFFh/9oACAEDAQE/EOFlll9r4X+VoocJFQdChrghWKGoe4KLinEQUPNQx8THxYxc LcPgxrifFZvA1TFFCSKDglYkGpcEzG6VwhMTYkJZdeFOxtbLsaEJj2JMS/YxiG1L WhPBF0f0aLFBeDLLWB6HpS+pnKEhiGsfs+h5fdD8xJJQ1gvSxu8PA2Gg2hqxUNDl mjLMkKKLLhYsscMeaFDFcpgGIUPkUJlmzY2N3DHyJiZ6WXCxwxvjuNVCeFlwkP3G y5bYlYxUuLCoNSHF5obUUUUGkUKjxjeT/ALBxfCI9DS8Ge8v/8QAHxEBAQEBAAMB AQADAAAAAAAAAQARECAhMDFAQVFg/9oACAECAQE/EP8Aid+mw2xxbZYbYfhszV/I HjMtbJOEvcvguEeb0+Ij4PD4gjzSbYfgI+K+bNu829zNRRly1atjOxxoQHqcst7X q/0WZL1xkAWjL3EWw99TrIE/LOPCe4LJHxA7+omOtvDD1nme/MD4Pzh4PGb/ABw8 GjLYesYxOoWLbee0fALeZ0zxPgeFsdDB6R5s8JhLS04HT4ieb4HM4vB8v7zI8GbY /PiNJhtttYZbEuw1j4sPDW1temPg8M/xxPc/g/iTzPN//8QAKBABAAICAQMEAgID AQAAAAAAAQARITFBUWFxECCBkaGxwfAw0eHx/9oACAEBAAE/EPV9LlSN1VTEL9Qj MecHCCjYPUwgK8Xp9RCGDl/if9ylCXvoP+M2QA5YOC3pfoiLrErisrl3Mb2bZaL6 5mjQmsVSUaof0uB8EZd/4QUBWrRGzgaBvvf9SwVmVLUsxUUZrEqJdLAJWjUzP4mU AgLTxFalz27wRSA3/k7e82UAZVjo6vmzqw9oTFuOI5lxqIJTswvwEsFOYZZyQSHL qPXohUltxEwBKZrbp56werZnkuj7WUrINv8ASIwFOLX8Rs1EAC7zcdAvlihTV1M6 zULRbAjWF77f9m/nV+YxhVUz74xLuJcV0fZ5/UQgnssXoR8aLwriKi7hS6OUFqMG txSxeA4YG7DUtxeGB1O48PBDFMu+84mATU6idek3EU5hwMnTcI++QG+pn7kXUx7N JBh84/mUReoeEBUxKijiHEoQqpQxizF9DkvWAkmyUCBuKXpQd9P6IetBq8DvuQWO hAvyjv1xD0YkfUBV6gd0xjsD+fZ3Jq+oNu04ocxNHWJi4KlGVKjFdYh6FyEDaoMK BgbEwH8oejO9BUxw/qGCvmHiUuyBlgmgR8wrwktN+nIhhlmjHlmmN4iKH4RNwIwj JQC/zET4f1/2HoxqBW1hcVjARHLk/H5m1oor6lrIt+pSK0fEFVrdUWj4eNG0xBEE sjRHKmDbK2tOggBrpMy9sp3nQZo/mAm1WOy+vxUGqhejfpul9YXSC7tROsMcqgPx EVGeIEjZXOHDEZdDybfzqojgAXlvmmOrz8xxhtBzLzI4LqaOclB8hAs2VUK6Y3Gq V8JdEbClpTKD9woIyC9pWuxuEYo+IrB8zp87lAuGhoZwBeyIZmBbliAzHeENLxAA SbWNRhxArsuIoqUo2Z+pehg1xK8T0MdfQZf74mMu7JiJVgFSo6iwodwIYhhms59F QVFiEUPOIJhgEF9e+jKkluD4lILdGZCWVMEvrKajuUKJGFYQFLK25cWI8TKrVcMa 0/creW3z6gESx2QcTOirfuBfbska6lxLouMgNMv6shQiJ8NMfCpcuJvI7oK+pinM vEWI7jo4UYxCoqx7GMpQYF/NzMSw3KGri2DLAvUTRZHFowQW1B60z4SPMZAF+VYH sYy4vKvv/wAjpmFlZoyuycQIweWDBUe4xpwPKw92DfSJG6XYv016pUO1w9j6MZsW eTMIWOPaAWM3ufPIDMy5TyQrsFdoiyfiL/qJmVHaGWNFpMuWUXyqCgPaxjNzhg8N NP3Mu9TIZjLVqCqG43dofMgcAQoBtcS5biNxsnV1aeazD3ALWjqxXeu13WcaeIfF OEGgu7g44I4oG9kwgYIckYONEu1AWWeZsGHMTlSpxWpUUUq7yHsxf9I5qIA9D2/W v3G/d7sPHSKR+jpBaAA/LGdtIgTM4RHrFsIiYrdbRBz3KlqkXlC8sz0K9WYU5SiX zvEJtYIrL+0ZlPyhZQ+TP4nd6iuXFNjq+J+4GIq4ImadoQdaqLpKxHmwsKHyRNIX gJjzZ4l/A81AtAglrxQ0NxRJAIRyKRIQobP4f9zPTEVB0l41FlmJrqEzSxjUNCVI g8So9MBDJOLwR03WD1mSwrDvqWXFRW9I4m+YYEzb9yKxMazUgql0I2xUK1iCxlQk vHzDKGFgwNzWIwmoZ+5tGsVKD4YVIRlAzPj0AXMAEAGNhwFxYzm5wsCCf//ZiQE+ BBMBCgAoAhsDBQkDw65MAh4BAheABQJT/iXwBgsJCAcDAgYVCAIJCgsEFgIDAQAK CRAq4CXACKhhgFgKCACQlazypR23xa8UBChVGRoVtqj4YMNZQEbbkX2JwAxSOCaU 6CiPXNgCgkXUL5YKcK0dhtELHt36NRwTEgizmSj5L+Zu9PKXDVA1HjbzRIA0uIYn icnVawkOwLxhVybS/lb4GrOdvkf/verHZPAVwVftYgMEi0/X/3OFSHJsTvaaVoKZ s8P2eKZzeT/aFHqcq8vHmi3tqB5amjMg+sxrWOMp5/SxX8VbNNnjouiEwerkf9K6 RoIMXeufewhUnXyW78uLQif8s8qRC79xkp6yiYNXwpIjFHXtAHpqF6AoGCXnmE25 Q7fbee2QllVwwznan1n2mxTpnMYjiWJuOn5PM1xKtGhKYW1lbnNvbiBGZXJyZWly YSBFc3BpbmR1bGEgZGUgQWxtZWlkYSBNZWxvIChBZHZvZ2Fkby4gUmVjaWZlLCBQ ZXJuYW1idWNvLCBCcmFzaWwpIDxqYW1lbnNvbkBib2wuY29tLmJyPokBPgQTAQIA KAIbAwUJA8OuTAIeAQIXgAUCU/4l8AYLCQgHAwIGFQgCCQoLBBYCAwEACgkQKuAl wAioYYB8Ywf/VmTmfdtnzNNcnyJvv39nQUxL3E8YEjxDdrGoZBCyLFNbp/wQMcoH 4cG14IDWDvEzyJUWfkiVTc+pbiHrj5Fd+pWSTowJd54wcPN32vlKMixbAcr54fIN o/pD0hhlOO+CI9mMo2qLhLT6HNMGhMM5cTTDT5QKI0+1zosb7Oh3uzPXz7q2WBeo Dt/dQk2r+kxmp9v26vKm2Z5VSXYPuA0p9xo73BWxUinCJ0YaRdTitB/wdJmCHosj p8/XTV6W4sFFQIBF4nWq6QwCYTaBaD419NOd/tZ7XatIaQJ/pn/G7PUZnL9u78CV EcMa5PQSAy79bPJAlR54rumeyildYZFAjYkBIgQQAQIADAUCU/4wfQUDABJ1AAAK CRCXELibyletfGvJB/4i6N4GdmzQTfkHYV+RisDwTy55jNRTbB5V/3w5Bja/rPNY eKKeiVO24AhHzBk4My7ZAKce+/kn8mcupEkoqL9kDRRFcDvZq/l0e7G2TsUtNyuZ inyQM/1vs7tliCA+fImS6W4kwBxFGrsyG/IdGk6fnKQycJBfFrL9wcACPpowTkI1 wXOIAkfGm9WFJ+1f12t3vu0B5yUxw0Qpody3DL8AyzCXik88cqr7yGRtnIQoJZqo bvoQE5EFe2FAHbU97Y1o3RRdq+2GAoJd3DJ5NHbWD7WIyth0AuRNy6qHFffjMlnu j0nEee+DdEsOg5+xj4msPJe3n8VXT6agFPzbbyHStHJKYW1lbnNvbiBGZXJyZWly YSBFc3BpbmR1bGEgZGUgQWxtZWlkYSBNZWxvIChBZHZvZ2Fkby4gUmVjaWZlLCBQ ZXJuYW1idWNvLCBCcmFzaWwpIDxqYW1lbnNvbmVzcGluZHVsYUBob3RtYWlsLmNv bT6JAT4EEwECACgCGwMFCQPDrkwCHgECF4AFAlP+JfAGCwkIBwMCBhUIAgkKCwQW AgMBAAoJECrgJcAIqGGAfc8H/Rp1XXHhDAZkH56EqjDaCG1ndC0Scz8i3/L/qojL EhPZ6rKEVw3kB/bthk6mHtFSm/KWJjQjpnlx5QhbcsyJU5ywNiBGe0QNWxQJ0ynT zGlibbyKcoEJuK/uYULPf8/hcLhoARtwqxKzwLfJdIbksiaedDom80zwt7j7sFuw XkA4Aogq73s0+lTx3a+GlBbUFbOnfYBeSk4TynUKupHJ0tY+X12Nsvr/GQ6h4bvP rWJGJ/+L0w3sZWykEROna0tpya66X4a9/ylLn2xBkfEwfDGKI7rfoDHRzakN2LpS l1q/Bio9ORfI/UaYGHo3PUYmxq7tdgd1n1y6XFZhz0kWHc6JASIEEAECAAwFAlP+ MH0FAwASdQAACgkQlxC4m8pXrXy4jQf/TnPTC5Lri2SHLg0q/RxL7HIxc0hA8B/K 9YdZFwnA9RwnlOPQGU9d67od4vSiZ1UHefysu15TkLOXZpBZCyaKwrXWXvG4J1DD TVrxqqZ9JFbcWxHME+ExD2paHK3s/bTXl7S9x0SZ/nVFSgN/5/wV4Ur8jK+hqWRC onQV91KoQnINJP9meh9uH5DsKKLA9aTAUpQuye3zi1CN2/7Y1s2E3k3N9GqwdbJn 0lw3klghVoZcQQ+nTZdxDNx6zOve7TiFYKk7Nop/Xt40aD6Dagzez/WYe5cz8UA0 YeZDFtj12bJf70BPtmMYIqj4vNaEg8vbZ/xCSUvn3siW4MZIew6TYbkBDQRTlqub AQgAtbDZqSvE6JWq2MVJ3gAABENinpmfe6tLyoC+YDLbAUSFb/MkU1YbODesPX1O PxHV9r3SCc+BNrO9O1B4QeUFtOsho3EB/jfbdwUaorEyWCONzfzbCQOVgqNdta+R KXsDxNWKxEomZprhua7EqixGV1b4D/A/0cPf10zPtsv+d7vzGNKXf3NDo6PQJwtY bbDw50hQzWTdGNUL3wbDmMlNixqsID1VkXnaEb6S++s3QSB9tUiO9GFCNJ1l+Ubk RWD7n5ewmN0F3gQu+S7C6edqdat5U0eIS8NdEGm7bsN8u2IwdpMPCqM01zOB64FT QGuwyrWyzWBBJ1BBLYw8/M9wCwARAQABiQElBBgBAgAPAhsMBQJTmBBfBQkDw8uy AAoJECrgJcAIqGGA1M0IAISE2wjMq6r0qFHDOQi+fKbLz7v1N7v6A1g0s6vYGzYE QArv7SX+08pKyUTZ4q4IPyIh0CxpxW7yMvNIICaa0fy6Q0cvS/8xzmQ9L87zjddA sIv2DcxCJbh+CKFJX6Dvo/3RXlhDbNo+intrhqj1ll5Ug5ZysvsniJIict/iEZgk ousIkxjntblaS3XZDTCvrVigePiUnFzWD3UnWqWibepgEBecTsPTs1gk/J+jKzMo T6cnfXWv/pLD3DGczQtGxOLjb7P0KL74Wd2KhtKe9m8G17s1zvKG78paNieGXN/B EaD2V9S0KGtuV4RVz4ZgBz8RSk4d3qE/NKtOYz5DJpI= =zY2T -----END PGP PUBLIC KEY BLOCK-----
terça-feira, 16 de setembro de 2014
GnuPG - Configurações - Parte III (no-greeting)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jaboatão dos Guararapes, PE, 16 de setembro de 2014.
Assunto: GnuPG - Configurações - Parte III
Quando se executa um comando como <gpg --edit-key usuário> entra-se no
ambiente para edição dos atributos par de chaves do usuário informado.
Logo na entrada do ambiente, é exibida uma informação de direitos
autorais. Tem gente que _não_ gosta da exibição de tal mensagem.
Então, a opção <no-greeting>, quando presente e _habilitada_ no arquivo
de configuração do GnuPG (em regra, ~/.gnupg/gpg.conf), faz com que tal
mensagem _não_ seja exibida.
Para _não_ exibir a informação sobre direitos autorais:
no-greeting
Antes, _sem_ a opção no-greeting ...
______________
jamenson@lfs-comp01: ~/Documentos $ gpg --edit-key jamenson
gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Chave secreta disponível.
pub 2048R/0x2AE025C008A86180 created: 2014-06-10 expires: 2016-06-10 usage: SC
trust: ultimate validity: ultimate
sub 2048R/0x7ED08E2C60833F3C created: 2014-06-10 expires: 2016-06-10 usage: E
[ultimate] (1). Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jafesp@gmail.com>
[ultimate] (2) [jpeg image of size 4599]
[ultimate] (3) Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamenson@bol.com.br>
[ultimate] (4) Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamensonespindula@hotmail.com>
gpg>
______________
Após, _com_ a opção no-greeting ...
______________
jamenson@lfs-comp01: ~/Documentos $ gpg --edit-key jamenson
Chave secreta disponível.
pub 2048R/0x2AE025C008A86180 created: 2014-06-10 expires: 2016-06-10 usage: SC
trust: ultimate validity: ultimate
sub 2048R/0x7ED08E2C60833F3C created: 2014-06-10 expires: 2016-06-10 usage: E
[ultimate] (1). Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jafesp@gmail.com>
[ultimate] (2) [jpeg image of size 4599]
[ultimate] (3) Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamenson@bol.com.br>
[ultimate] (4) Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamensonespindula@hotmail.com>
gpg>
______________
Agora, você decide qual das duas configurações mais te agrada (eu gosto da primeira!).
Importante:
Versões testadas:
GnuPG v1.4.12 (GNU/Linux) --> Debian Wheezy
GnuPG v2.0.22 (GNU/Linux) --> Linux From Scratch 7.5
Jamenson Ferreira Espindula de Almeida Melo
Usuário Linux nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJUGA3nAAoJECrgJcAIqGGArCkH/27/CJjJceEOfFbLUdj20OZz
0xqWUjtJ7hYCwiDPYWRYQU9iDpV2Y/Pyrapf11heyyK81tm1/PvQCMEt2WcST3ja
1XvhWIV7E0Ey7wzpZqbdEYyRUm27WNAEjdT8mQop6mnBCCuyZebl3K065zdEqEF9
Zk5dMjQW86HdcXQyK0IjdDslbfomtua1EtrS+0nOxbG8F8BnoqdCbu8gCgZM3q6e
unQluetrdwQpVT1EAnsx+NppdauZ9P28yWvwQONIXsA0awlDL+9Y9r4sFgqJ6GR7
iyRpOHERQqK1G+cKJi+tG1Cf8G7eqnjZKkL6wqugzQQlgIpd/xeULjJWN8rMoLQ=
=k4z2
-----END PGP SIGNATURE-----
quarta-feira, 10 de setembro de 2014
Assunto: GnuPG - Configurações - Parte II (keyid-format)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jaboatão dos Guararapes, PE, 10 de setembro de 2014.
Assunto: GnuPG - Configurações - Parte II (keyid-format)
Resumo: série de postagens acerca de configurações do aplicativo GnuPG
em seu arquivo de configuração (por padrão, ~/.gnupg/gpg.conf):
Observe abaixo a saída do comando [gpg --list-key 08A86180]:
pub 2048R/0x2AE025C008A86180 2014-06-10 [expires: 2016-06-10]
Key fingerprint = 234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jafesp@gmail.com>
uid [ultimate] [jpeg image of size 4599]
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamenson@bol.com.br>
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamensonespindula@hotmail.com>
sub 2048R/0x7ED08E2C60833F3C 2014-06-10 [expires: 2016-06-10]
A informação 0x2AE025C008A86180 é a chamada "Identidade da Chave" ("key ID").
Para que a Identidade da Chave seja exibida no formato mostrado acima,
coloque a seguinte linha no arquivo de configuração (por padrão, ~/.gnupg/gpg.conf):
keyid-format 0xlong
_______________________________
Sem a opção em foco (ou com ela configurada para "short"), a saída do
comando [gpg --list-key 08A86180] se parece com isto:
pub 2048R/08A86180 2014-06-10 [expires: 2016-06-10]
Key fingerprint = 234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jafesp@gmail.com>
uid [ultimate] [jpeg image of size 4599]
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamenson@bol.com.br>
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamensonespindula@hotmail.com>
sub 2048R/60833F3C 2014-06-10 [expires: 2016-06-10]
_______________________________
Abaixo a saída do mesmo comando, agora com a opção configurada para
"0xshort":
pub 2048R/0x08A86180 2014-06-10 [expires: 2016-06-10]
Key fingerprint = 234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jafesp@gmail.com>
uid [ultimate] [jpeg image of size 4599]
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamenson@bol.com.br>
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamensonespindula@hotmail.com>
sub 2048R/0x60833F3C 2014-06-10 [expires: 2016-06-10]
_______________________________
Com a opção setada para "long", a saída do comando muda para isto:
pub 2048R/2AE025C008A86180 2014-06-10 [expires: 2016-06-10]
Key fingerprint = 234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jafesp@gmail.com>
uid [ultimate] [jpeg image of size 4599]
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamenson@bol.com.br>
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamensonespindula@hotmail.com>
sub 2048R/7ED08E2C60833F3C 2014-06-10 [expires: 2016-06-10]
_______________________________
Agora, basta você escolher qual dos quatro formatos da informação
"keyid-format" mais te agrada.
Jamenson Ferreira Espindula de Almeida Melo
Usuário Linux nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJUD9DCAAoJECrgJcAIqGGAXKoH+wR68XXErhOO8wNtMNlY7Uej
wdu7LFtdJ2UzcjwlNH7PvWDPNcBUSZK/4QWXnGdip5ok8w0aOVkxeKIJtKIOXsSu
wCYk40ESYOfBIZdMUTRAE69VQwbCP090OVcFgg3FYw+i0KzODQJFjy9dzrJatD34
j6dx0sgUdaD2YWL5uAlanfJtdybvLTax8im/QmC8ZomSMwovtJ9C1zRDBxWwyzkI
+QVCDT6OvU8HfZxAylyJ8/r0nJq2oP7xE+YFh01CIxSXdIY0HG1BRjFIlXvIuT/9
SSV2ZOKaicR8hjf4rU/uenWR9x8H+R7z7dNX2KBAlml5AIWRNKcZYX/kIMRWfuw=
=aNYe
-----END PGP SIGNATURE-----
domingo, 7 de setembro de 2014
O Console Framebuffer (Antonino Daplas)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jaboatão dos Guararapes, PE, 07 de setembro de 2014.
Eis uma tradução livre para a lingua portuguesa falada no Brasil do
texto da autoria de Antonino Daplas "The Framebuffer Console". Tal
texto vem junto com os códigos fontes do kernel Linux, estando o arquivo
localizado sob o diretório Documentation/fb/fbcon.txt
O Console Framebuffer
=====================
O console framebuffer (fbcon), como o nome implica, é um console
de texto sendo executado no topo do dispositivo framebuffer. Tem a
funcionalidade de qualquer driver de console de texto padrão, tal qual o
console VGA, com as características adicionadas que podem ser atribuídas
à natureza gráfica do framebuffer.
Na arquitetura x86, o console framebuffer é opcional, e alguns
até mesmo o tratam como um brinquedo. Para outras arquiteturas, é o
único dispositivo de exibição disponível, texto ou gráfico.
Quais são as características de fbcon? O console framebuffer
suporta altas resoluções, variação de tipos de fontes, rotação de
display, multicabeça primitivo, etc. Teoricamente, fontes
multi-coloridas, blending, aliasing, e qualquer característica feita
disponível pela placa gráfica subjacente também é possível.
A. Configuração
O console framebuffer pode ser habilitado utilizando sua
ferramenta de configuração de kernel favorita. Está sob Device
Drivers->Graphics Support->Support for framebuffer devices->Framebuffer
Console Support. Selecione 'y' para compilar o suporte estaticamente,
ou 'm' para suporte de módulo. O módulo será fbcon.
Para ativar o fbcon, pelo menos um driver framebuffer é exigido,
então escolha um dos numerosos drivers disponíveis. Para sistemas x86,
eles quase universalmente tem placas VGA, de forma que vga16fb e vesafb
sempre estarão disponíveis. Entretanto, a utilização de um driver
específico para o chipset da placa te dará mais velocidade e
características, tais como a habilidade de mudar o modo de vídeo
dinâmicamente.
Para exibir o logotipo do pinguim, escolha qualquer logotipo
disponível em Logo Configuration->Boot up logo.
também, você precisará selecionar pelo menos uma fonte
compilada-internamente, porém se você não fizer nada, a ferramenta de
configuração de kernel selecionará uma para você, usualmente uma fonte
8x16.
TRUQUE: Um relato comum de bug é a habilitação do framebuffer sem
habilitar o console framebuffer. Dependendo do driver, você poderá
obter uma exibição preta ou truncada, porém o sistema ainda inicializa
por completo. Se você estiver com sorte em ter um driver que não
altere o chip gráfico, então você ainda obterá um console VGA.
B. Carregamento
Cenários possíveis:
1. Driver e fbcon são compilados estaticamente
Usualmente, fbcon automaticamente se apossará do seu console.
A notável exceção é vesafb. Ele precisa ser explicitamente
ativado com o parâmetro de opção de inicialização vga=. [Nota
do tradutor: conforme a documentação do GNU GRUB, o parâmetro
"vga=" foi substituído por "resolution="]
2. Driver é compilado estaticamente, fbcon é compilado como um módulo
Dependendo do driver, você obtém ou um console padrão, ou
uma exibição truncada, conforme mencionado acima. Para obter um
console framebuffer, faça um 'modprobe fbcon'.
3. Driver é compilado como um módulo, fbcon é compilado estaticamente
Você obtém seu console padrão. Uma vez que o driver seja
carregado com 'modprobe xxxfb', fbcon automaticamente se
apossa do console com a possível exceção do uso da opção
fbcon=map:n. Veja abaixo.
4. Driver e fbcon são compilados como um módulo.
Você pode carregá-los em qualquer ordem. Uma vez que ambos
estejam carregados, fbcon se apossará do console.
C. Opções de inicialização
O console framebuffer tem várias, largamente desconhecidas,
opções de inicialização que podem modificar-lhe o
comportamento.
1. fbcon=font:<name>
Seleciona a fonte inicial para uso. O valor 'name' pode ser
qualquer das fontes compiladas-internamente: VGA8x16, 7x14,
10x18, VGA8x8, MINI4x6, RomanLarge, SUN8x16, SUN12x22,
ProFont6x11, Acorn8x8, PEARL8x8.
Nota, nem todos os drivers podem lidar com fontes cujo tamanho
não seja divisível por 8, tais como vga16fb.
2. fbcon=scrollback:<value>[k]
O buffer de rolagem é a memória que é utilizada para preservar o
conteúdo da exibição o qual já foi rolado ao passado de sua
visualiação. Isso é acessado utilizando a combinação de teclas
Shift-PageUp. O valor 'value' é qualquer inteiro. O padrão é
32KB. O sufixo 'k' é opcional, e multiplicará o 'value' por
1024.
3. fbcon=map:<0123>
Esta é uma opção interessante. Ela diz qual driver é mapeado
para qual console. O valor '0123' é uma sequência que é
repetida até que o comprimento total seja 64 que é o número
total de consoles disponíveis. No exemplo acima, ela é
expandida para 012301230123... e o mapeamento será:
tty | 1 2 3 4 5 6 7 8 9 ...
fb | 0 1 2 3 0 1 2 3 0 ...
('cat /proc/fb' deveria te dizer o que são os números
fb)
Um efeito colateral que pode ser útil é utilizar um valor de
mapa que exceda o número de drivers fb carregados. Por
exemplo, se apenas um driver estiver disponível, fb0,
adicionar fbcon=map:1 diz a fbcon para não se apossar do
console.
Mais tarde, quando você quiser mapear o console para o
dispositivo framebuffer, você pode utilizar o utilitário
con2fbmap.
4. fbcon=vc:<n1>-<n2>
Essa opção diz ao fbcon para apossar-se apenas de um intervalo
de consoles conforme especificado pelos valores 'n1' e 'n2'.
O restante dos consoles fora do intervalo dado ainda serão
controlados pelo driver de console padrão.
NOTA: Para máquinas x86, o console padrão é o console VGA
o qual tipicamente está localizado na mesma placa de vídeo.
Assim, os consoles que são controlados pelo console VGA serão
truncados.
4. fbcon=rotate:<n>
Essa opção altera o ângulo de orientação da exibição do console.
O valor 'n' aceita o seguinte:
0 - orientação normal (0 graus)
1 - orientação horária (90 graus)
2 - orientação de cabeça para baixo (180 graus)
3 - orientação anti-horária (270 graus)
O ângulo pode ser alterado a qualquer tempo afterwards
'ecoando' os mesmos números para quaisquer um dos 2 atributos
encontrados em
/sys/class/graphics/fbcon
rotate - rotaciona a exibição do console ativo
rotate_all - rotaciona a exibição de todos os consoles
A rotação de console apenas se tornará disponível se o Console
Rotation Support estiver compilado em seu kernel.
NOTA: Isto é puramente rotação de console. Quisquer outras
aplicações que utilizem framebuffer permanecerão em suas
orientações 'normais'. Atualmente, o driver fb subjacente é
totalmente ignorante acerca da rotação de console.
C. Anexando, Desanexando e Descarregando
Antes de ir adiante sobre como anexar, desanexar e descarregar o console
framebuffer, uma ilustração das dependências pode ajudar.
A camada do console, como ocorre com a maioria dos subsistemas, precisa
de um controlador que interaja com o hardware. Assim, em um console
VGA:
console ---> controlador VGA ---> hardware.
Presumindo que o controlador VGA pode ser descarregado, uma pessoa deve
primeiro desvincular o controlador VGA da camada de console antes de
descarregar o controlador. O controlador VGA não pode ser descarregado
se ele estiver ainda vinculado à camada de console. (Veja
Documentation/console/console.txt para mais informação).
Isso é mais complicado no caso do console framebuffer (fbcon), pois
fbcon é uma camada intermediária entre o console e os drivers:
console ---> fbcon ---> controladores fbdev ---> hardware
Os controladores fbdev não podem ser descarregados se eles estiverem
vinculados ao fbcon, e fbcon não pode ser descarregado se ele estiver
vinculado à camada de console.
Assim, para descarregar os controladores fbdev, uma pessoa deve primeiro
desvincular fbcon do console, então desvincular os controladores fbdev
do fbcon. Felizmente, a desvinculação de fbcon da camada de console
automaticamente desvinculará os controladores framebuffer do fbcon.
Assim, não existe necessidade de desvincular explicitamente os
controladores fbdev do fbcon.
Então, como nós desvinculamos fbcon do console? Parte da resposta está
em Documentation/console/console.txt. Para resumir:
Ecôe um valor para o arquivo de vínculo que representa o controlador de
console framebuffer. Assim, presumindo que vtcon1 representa fbcon,
então:
echo 1 > sys/class/vtconsole/vtcon1/bind - anexa o console framebuffer
à camada de console
echo 0 > sys/class/vtconsole/vtcon1/bind - desanexa o console framebuffer
da camada de console
Se fbcon for desanexado da camada de console, seu controlador de
inicialização de console (o qual é usualmente modo de texto VGA)
assumirá o controle. Uns poucos controladores (rivafb e i810fb)
restaurarão o modo de texto VGA para você. Com o resto, antes de
desanexar fbcon, você deve tomar uns poucos passos adicionais para ter
certeza de que seu modo texto VGA está restaurado adequadamente. O
seguinte é um dos vários métodos que você pode fazer:
1. Download ou instale vbetool. Esse utilitário está incluído na
maioria das distribuições atuais, e é usualmente parte da ferramenta de
suspender/restaurar.
2. Na configuração de seu kernel, assegure-se de que
CONFIG_FRAMEBUFFER_CONSOLE está configurado para 'y' or 'm'.
Habilite um ou mais dos seus controladores de framebuffer preferidos.
3. Inicialize no modo texto e como root execute:
vbetool vbestate save > <arquivo estado vga>
O comando acima salva o conteúdo dos registradores do seu
hardware gráfico para <arquivo estado vga>. Você precisa fazer
esse passo apenas uma vez, já que o arquivo de estado pode ser
reutilizado.
4. Se fbcon for compilado como um módulo, carregue fbcon fazendo:
modprobe fbcon
5. Agora, para desanexar fbcon:
vbetool vbestate restore < <arquivo estado vga> && \
echo 0 > /sys/class/vtconsole/vtcon1/bind
6. Isso é tudo, você está de volta ao modo VGA. E se você compilou
fbcon como um módulo, você pode descarregá-lo com 'rmmod fbcon'
7. Para reanexar fbcon:
echo 1 > /sys/class/vtconsole/vtcon1/bind
8. Uma vez que fbcon estiver desvinculado, todos os controladores
registrados no sistema também se tornarão desvinculados. Isso
significa que aquele fbcon e controladores individuais framebuffer podem
ser descarregados ou recarregados à vontade. Recarregar os
controladores ou fbcon automaticamente vinculará o console, fbcon e os
controladores juntos. Descarregar todos os controladores sem
descarregar fbcon tornará impossível para o console vincular fbcon.
Notas para usuários vesafb:
==========================
Infelizmente, se a sua linha de comando de inicialização incluir um
parâmetro vga=xxx que configura o hardware em modo gráfico, tal como
quando carregar vesafb, vgacon não carregará. Em vez disso, vgacon
substituirá o console de inicialização padrão por dummycon, e você não
obteria qualquer display após desanexar fbcon. Sua máquina ainda está
viva, então você pode reanexar vesafb. Entretanto, para reanexar
vesafb, você precisa fazer um dos seguintes:
Variação 1:
a. Antes de desanexar fbcon, faça
vbetool vbemode save > <arquivo estado vesa> # faça uma vez
para cada modo
vesafb,
# o arquivo pode
ser reutilizado
b. Desanexe fbcon como no passo 5.
c. Anexe fbcon
vbetool vbestate restore < <arquivo estado vesa> && \
echo 1 > /sys/class/vtconsole/vtcon1/bind
Variação 2:
a. Antes de desanexar fbcon, faça:
echo <ID> > /sys/class/tty/console/bind
vbetool vbemode get
b. Tome nota do número do modo
b. Desanexe fbcon como no passo 5.
c. Anexe fbcon:
vbetool vbemode set <número do modo> && \
echo 1 > /sys/class/vtconsole/vtcon1/bind
Amostras:
========
aqui estão 2 amostras de scripts bash que você pode utilizar para
vicular ou desvincular o controlador de console framebuffer se você
estiver em uma caixa X86
- - ---------------------------------------------------------------------------
#!/bin/bash
# Desvincula fbcon
# Mude isto para onde seu arquivo vgastate atual estiver localizado
# Ou Utilize VGASTATE=$1 para indicar o arquivo de estado em tempo de execução
VGASTATE=/tmp/vgastate
# caminho para a ferramenta vbe
VBETOOL=/usr/local/bin
for (( i = 0; i < 16; i++))
do
if test -x /sys/class/vtconsole/vtcon$i; then
if [ `cat /sys/class/vtconsole/vtcon$i/name | grep -c "frame buffer"` \
= 1 ]; then
if test -x $VBETOOL/vbetool; then
echo Unbinding vtcon$i
$VBETOOL/vbetool vbestate restore < $VGASTATE
echo 0 > /sys/class/vtconsole/vtcon$i/bind
fi
fi
fi
done
- - ---------------------------------------------------------------------------
#!/bin/bash
# Vincula fbcon
for (( i = 0; i < 16; i++))
do
if test -x /sys/class/vtconsole/vtcon$i; then
if [ `cat /sys/class/vtconsole/vtcon$i/name | grep -c "frame buffer"` \
= 1 ]; then
echo Unbinding vtcon$i
echo 1 > /sys/class/vtconsole/vtcon$i/bind
fi
fi
done
- - ---------------------------------------------------------------------------
- - --
Antonino Daplas <adaplas@pol.net>
Jamenson Ferreira Espindula de Almeida Melo
Usuário Linux nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJUDAZOAAoJECrgJcAIqGGARYEH+wU6XL+cf03EhATGkPBCsUOt
clzKY9qS2OSsnnTCdyv/cBRyZzbF3dzKBYWLDwm0duNhAwPCZ+sx1hCCFw+s8j+b
O6a0ZjhUpOCHukYdKWp9hZ3SRrGfHDWjEimZ9G1BCfbRQ4GQa/PGPCIupN+10aWI
0wpWyD+Fu8gxOdOvBSCZQ9s4nCghNo7XOu9Eif4Td+1gGhy3CXidiY4nwVvf7dKc
ggHANj3FprQQgcYc9E1deGc/j/kIDxUzus4Kx0Xg/lUpigEDP9dJ7s7apgS0tk5B
HXzh0085Lnn9Fv4p/hLbClVoqe1R7IoPkJ3tFeuj7lWXoACuiit/f7SBwzlLTBk=
=X/BN
-----END PGP SIGNATURE-----
sábado, 6 de setembro de 2014
GnuPG - Configurações - Parte I
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jaboatão dos Guararapes, PE, 06 de setembro de 2014. Assunto: GnuPG - Configurações - Parte I Para mudar o chamado "Algoritmo de Dispersão" (Em criptografia, um algoritmo de hashing ou dispersão é um método de cifrar dados de forma a manter a sua integridade - http://pt.wikipedia.org/wiki/Algoritmo_de_dispers%C3%A3o) do GnuPG: personal-digest-preferences sha256 Antes ... - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Depois ... - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Importante: Versões testadas: GnuPG v1.4.12 (GNU/Linux) --> Debian Wheezy GnuPG v2.0.22 (GNU/Linux) --> Linux From Scratch 7.5 Jamenson Ferreira Espindula de Almeida Melo Usuário Linux nº 166197 https://linuxcounter.net/cert/166197.png Impressão digital da chave: 234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJUC7pbAAoJECrgJcAIqGGAIEcH/i7N272Biy8QCmPYfxhnCDN6 K3TyMLMhUp6TrmrQdN5AQ+ULr0rVAk/87u9wwc9Cc8fF8FLr+OA6klje5+7SqqLj mBPTHWRpHTO+3Ixae1yGj4VEeCySjg0JSkEtN6tZ7lFZDk5pEtURZSn919XPWepK 9AHoYab8VJ7xv6amL7j+mVf6OmTbYXcx8Ik3AAdzsVP0BVh2InG3zky2+j99AWOo ewZ6lU3lttpNs+4i/kXMnmMslFVIGHE2CCU6SN9receozBzaFnl+ITz4XfFjLCgC hUL6HB1I/VuaNl7imifpFljadNFVCxCA+KhkJ8lhiQQhmYjFV435wo2aPIEyLeI= =4bGK -----END PGP SIGNATURE-----
terça-feira, 2 de setembro de 2014
Permissões de Arquivos do Unix (Perderabo, 28/05/2005)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jaboatão dos Guararapes, PE, 02 de setembro de 2014.
Aqui está, em tradução livre para a língua portuguesa falada no Brasil, o texto postado por Perderabo "Permissões de Arquivos do Unix".
Unix File Permissions (Perderabo, 28/05/2005 - http://www.unix.com/tips-and-tutorials/19060-unix-file-permissions.html)
Introdução
Eu tenho visto alguma informação errada relativamente às permissões de arquivo do Unix. Eu tentarei esclarecer as coisas. Dá uma olhada neste exemplo de alguma saída do ls:
$ ls -ld /usr/bin /usr/bin/cat
drwxrwxr-x 3 root bin 8704 Sep 23 2004 /usr/bin
- -r-xr-xr-x 1 bin bin 9388 Jul 16 1997 /usr/bin/cat
$
Na primeira linha, aquele "root" diz que o diretório é propriedade do usuário chamado "root". E que "bin" ś o grupo do diretório. Você precisará entender usuários e grupos e eu presumirei que você entende. Meu objetivo é explicar aquelas "drwxrwxr-x" e "-r-xr-xr-x" coisas. Aquele campo é uma combinação do tipo do arquivo e permissão de acesso. Coletivamente, essa informação é algumas vezes chamada de modo do arquivo. E algumas vezes ela é chamada de permissões. Um bom lugar para começar é dando uma rápida olhada em como essa informação é atualmente armazenada no disco. A forma como ela é armazenada afeta um número de decisões que devem ser tomadas ao longo dos anos.
Como o "Modo do Arquivo" é armazenado.
No disco, informação acerca de um arquivo é armazenada em uma estrutura chamada um "inode". Cada arquivo tem o seu próprio inode. Um item de dados em um inode é chamado de "modo" e ele se parece com isto:
|---modo do arquivo---|
| |
|
| |--completo---|
|
|-tipo| | |-básico--|
| | | | |
oo0 000 000 000 000 000
... ... ... ... ... ...
| | | | |
| | | | |---- rwx para outros
| | | |
| | | |-------- rwx para grupo
| | |
| | |------------ rwx para usuário
| |
| |---------------- configura uid, configura gid, sticky bit
|
|---------------------- tipo do arquivo: comum (-)
diretório (d)
carácter especial (c)
bloco especial (b)
fifo (p)
ligação simbólica (l)
socket (s)
Eu entendo que o "modo" realmente significa simplesmente as permissões e que o tipo do arquivo foi enfiado para dentro para economizar espaço. Porém, o autor do aplicativo ls está tratando o modo como um item único. Eis o porque de o tipo do arquivo ser o primeiro carácter da sequência de permissão no saída de "ls -l". O tipo do arquivo usualmente será um dos sete tipos que eu mostrei acima. Algumas versões de Unix adicionarão alguns mais. A única outra coisa a saber a partir do formato é que não existe mais compartimento para adicionar mais bits de permissão.
Representando aquelas permissões em octal
O aplicativo ls pode exibir, digamos, "rwxrwxrwx" para as permissões em um arquivo. Também é muito comum utilizar um número octal para expressar as permissões em um arquivo. E como você vê acima, assim é como elas são armazenadas. Você pode escutar alguém dizer que alguns tem permissões 777. Isso é o mesmo que "rwxrwxrwx" e muito mais fácil de pronunciar. Então você precisa saber como convertê-los. Três dígitos binários ou bits correspondem a um dígito octal:
421
rwx
Assim, o bit de leitura tem valor 4, o bit de escrita tem valor 2, e o bit de execução tem valor 1. Você simplesmente adiciona tais valores para obter um dígito octal. Então, "-rwxrwxrwx" é 777. E "-rwxr-x---" é 750. Se você ainda não consegue ver como ir de "r-x" para 5, talvez esta tabela ajude:
- --- = 0
- --x = 1
- -w- = 2
- -wx = 3
r-- = 4
r-x = 5
rw- = 6
rwx = 7
Perceba que precisamos de 4 dígitos octais para exprimir todos os bits de permissões. Os primeiros três bits são especiais e são frequentemente zero. E você quase sempre aprende primeiro sobre os 9 bits seguintes. Algumas pessoas param aí e nunca aprendem aqueles primeiros três bits. Porém, existem 12 bits de permissão, não apenas 9. Dito isso, vamos agora dar uma olhada nos 9 bits seguintes.
Os Bits de Permissão Básicos
Nós temos 3 triplas: uma tripla para o usuário, uma tripla para o grupo, e uma tripla para outros. Algumas vezes o "usuário" é chamado de proprietário. E algumas vezes "outros" é chamado de "mundo" Eu utilizarei "usuário" e "outros" pois o comando chmod utiliza as letras "u", "g" e "o" para se referir àquelas triplas.
Qual Conjunto de Bits Aplica-se a Você?
Quando Unix decide o que você pode fazer, ele não utiliza todos os 9 bits. Unix pega a primeira tripla que aplica-se a você. Considere isto:
- ----rwxrwx 1 joe users 29 Mar 22 19:39 algumarquivo
Mesmo que joe seja dono desse arquivo, ele não pode acessá-lo. (Uma vez que joe é dono do arquivo, ele poderia dar acesso a ele próprio. Mais sobre isso depois). Também root é especial. A root é permitido rwx a todos os diretórios e rw a todos os arquivos. Em um arquivo, se quaisquer dos 3 bits estiverem configurados, root tem permissão de execução. Essa permissão especial é frequentemente desabilitada em sistemas de arquivos montados via rede.
O que "r", "w" e "x" realmente significam para um arquivo?
Para um arquivo, "read" [leitura] e "write" [escrita] são bastante intuitivos. O "x" para "execução" significa que o kernel pode tentar executar um arquivo. Para que isso funcione, o arquivo deve ser um executável (saída de um compilador) ou um script de shell com um "#!" na primeira linha. Para um diretório, as coisas são um pouco mais complexas. Com um diretório, a permissão "write" [escrita] significa que você pode criar novos arquivos em um diretório ou remover arquivos antigos. Ela as vezes surpreende as pessoas pois você pode remover um arquivo o qual você não pode ler. O comando rm do Unix testará tal situação e emitirá um alerta, porém você pode suprimir tal alerta com -f. E alertando ou não, se você deseja remover um arquivo ilegível de um diretório gravável, você pode. E rmdir não se preocupará em verificar de jeito nenhum.
O que "r", "w" e "x" realmente significam para um diretório?
Um diretório é um arquivo também, e a permissão "read" significa que você pode lê-lo. Porém você realmente não pode fazer muita coisa sem a permissão "x" também. Com diretórios, você usualmente tem ambas as permissões leitura e execução ou nenhuma. Em um diretório, aquele "x" é oficialmente chamado "permissão de busca". Você precisa de um "x" para utilizar um diretório em uma localização. Assim, se você tentar "cat /etc/passwd", você precisará do "x" em / e /etc. Você também precisa "x" para acessar o diretório com um cd. Suponha que você tenha permissão de leitura, mas não de busca (x) em um diretório. O que você pode fazer? Não muito. Você pode utilizar "ls" para visualizar os nomes de arquivos. Mesmo "ls -l" não funcionará. Acesso de leitura sem permissão de busca não é realmente útil. Ainda é melhor do que ter apenas permissão de escrita em um diretório... isso é completamente inútil. Eu não tenho visto qualquer outra documentação que declare isso explicitamente, de forma que permita-me repetir: escrita mas sem permissão de execução em um diretório não concede nada para ninguém. Suponha que você tenha permissão de busca (x), mas não permissão de leitura em um diretório. Agora você pode abrir arquivos em um diretório se acontecer de você saber o nome do arquivo. Você pode acessar o diretório [com cd]. E isso é tudo. Você não pode nem mesmo criar um arquivo novo. Adicionar permissão de escrita permitirá a você criar arquivos. E você pode então apagar arquivos se acontecer de você saber o nome deles.
Ligações Simbólicas São Especiais
As configurações de permissão em uma ligação simbólica são um pouco especiais também. Elas são completamente ignoradas. Muitas versões de Unix não tem um meio de mudá-las.
Os Bits Setuid e Setgid
Dá uma olhada nisto:
$ ls -l /etc/passwd /etc/shadow /usr/bin/passwd
- -r--r--r-- 1 root sys 14006 Jan 14 11:17 /etc/passwd
- -r-------- 1 root sys 8281 Jan 14 11:18 /etc/shadow
- -r-sr-sr-x 3 root sys 96244 Sep 5 2001 /usr/bin/passwd
O arquivo passwd é gravável apenas pelo root (lembre-se, root é especial. Ele pode gravar um arquivo que não tem permissões de escrita configuradas). O arquivo shadow, no qual senhas são armazenas, não pode nem mesmo ser lido por usuários comuns. Porém, joe deseja mudar a senha dele. Ele pode fazer isso executando /usr/bin/passwd. Perceba aquelas permissões r-s. O aplicativo passwd tem os bits suid e sgid configurados. Isso transforma os "x" em "s". Em octal, seria 6555. O aplicativo passwd é de propriedade do root. Quando joe o executa, ele não é executado como "joe". Ao invés disso, é executado como seu usuário que é o root. Assim, o aplicativo passwd pode mudar a senha de joe para ele. O bit sgid funciona da mesma maneira, exceto que ele faz com que o aplicativo passwd seja executado como grupo sys ao invés do grupo do joe. O suid e sgid não tem suas próprias posições no ls. Quando o bit suid está configurado, ls exibe um "s" no lugar de um "x" para a permissão de execução do proprietário. O que acontece se o bit suid estiver configurado, porém o bit de execução do proprietário estiver desligado? ls exibirá um "S" maiúsculo no caso. O bit sgid é exibido de uma maneira singular, exceto que ele interage com a permissão de execução do grupo. (O conceito do conjunto uid foi inventado por Dennis Ritchie quando ele estava desenvolvendo Unix).
Para expandir as coisas um pouco, enquanto que jos está executando o aplicativo suid-para-root passwd, "joe" é o uid real e "root" é o uid efetivo. O aplicativo passwd pode obter ambas dessas id's se ele desejar fazê-lo. Assim é como o aplicativo passwd sabe como permitir a joe mudar apenas a senha de joe.
O Bit Sticky
O padrão Posix diz que se o bit sticky estiver configurado para um diretório, a simples permissão de escrita no diretório não mais é suficiente para permitir que arquivos sejam removidos. Você deve adicionalmente ser dono do arquivo ou ser dono do diretório. root permanece sendo hábil para apagar de qualquer diretório independentemente das permissões. Antigamente esse bit servia a um outro propósito. Em alguns Sistemas Operacionais ele ainda serve. Eu completarei em um apêndice abaixo. O bit sticky afeta o bit de execução "outros" na exibição ls. Exceto pelo fato de que ele utiliza "t" e "T" no lugar de "s" e "S". Por exemplo:
drwxrwxrwt 5 root root 1024 Feb 11 20:43 /tmp
Naquele diretório /tmp acima, qualquer pessoa pode criar novos arquivos. Porém, por causa do bit sticky, um usuário não pode apagar os arquivos de um outro usuário.
Limitando Permissões de Arquivo com umask
Quando arquivos são criados, o aplicativo que os cria pode especificar a configuração inicial de permissão. Você pode sobrescrever isso com umask. O umask é um conjunto de bits de proibição. Existe um comando umask que te permite visualizar e mudar o umask. Por exemplo, "umask 022" proíbe escrita de grupo e escrita de outros em arquivos recém criados. Ou "umask 027" proíbe escrita de grupo e proíbe leitura, escrita e execução de outros. Você pode executar um "umask 0" para permitir que o aplicativo faça o que ele desejar a medida que ele cria aplicativos. Porém, você não pode ir mais além. Você não pode forçar um aplicativo a ligar um bit. A configuração de umask afeta arquivos, diretórios, pipes nomeados (também conhecidos como fifos), e arquivos especiais. Ele pode ou não pode afetar ligações simbólicas. Ele também afeta algumas formas de Comunicação Inter Processos (Inter Process Communication), mas isso está além do escopo deste artigo. E, acredite se quiser, sockets nomeados são imunes a umask. Essa imunidade é exigida por Posix.
Mudando Permissões de Arquivos com chmod
Apenas o proprietário de um arquivo pode mudar as permissões sobre um arquivo. Essa operação não é afetada de nenhuma maneira pela configuração de umask. Se você mudar as permissões sobre uma ligação simbólica, a ligação será seguida e você mudará o arquivo alvo. É possível que apenas o root tenha o poder de configurar um bit sticky de um arquivo. Como um exemplo, "chmod 700 algumarquivo" permitirá que o proprietário leia, escreva e execute o arquivo, enquanto que proíbe todo acesso a quaisquer outros usuários.
Utilizando Modo Simbólico com chmod e umask
Posix introduziu uma nova sintaxe para o comando chmod. A ideia foi que a nova sintaxe substituirá o uso de uma constante octal com o comando chmod. A constante octal ainda é válida e eu entendo que ela chegou para ficar. Porém, a nova sintaxe simbólica te permite mudar uns poucos bits sem o conhecimento do que os outros são. Por exemplo, digamos que eu deseje tornar um arquivo inacessível para outros, mas eu não desejo mudar o acesso para o usuário ou o grupo. Eu precisaria fazer:
ls -l arquivo
Olhar para o arquivo e descobrir as configurações atuais.
chmod 750 arquivo
Eu tive de determinar que os primeiros dois dígitos são atuais 7 e 5 antes que podesse executar meu comando chmod. Com a nova sintaxe, eu posso simplesmente fazer:
chmod o= arquivo
para desligar os 3 bits finais. Como um outro exemplo, "chmod u+x file" permitirá que o usuário execute o arquivo. Por outro lado, esses dois comandos são equivalentes:
chmod 750 arquivo
chmod u=rwx,g=rx,o= arquivo
e eu prefiro a primeira sintaxe.
O modo simbólico pode ser uma lista de especificações separada por vírgulas. Cada especificação tem três componentes: <quem><operação><bitlist>
A parte quem pode ser:
u (usuário)
g (grupo)
o (outros)
a (all - todos)
(o que seja permitido por umask (subconjunto de tudo))
A operação pode ser = ou - ou +
= (configura para bitlist)
- - (subtrai bitlist do bit atual
+ (adiciona bitllist aos bits atuais)
A bitlist pode ser uma das seguintes letras:
r (permissão de leitura - read)
w (permissão de escrita - write)
x (permissão de execução - execute)
X (permissão condicional de execução)
u (permissões atuais para o usuário)
g (permissões atuais para o grupo)
o (permissões atuais para outros)
s (configura uid ou configura gid)
t (sticky bit)
O "X" é o mesmo que "x" a menos que o arquivo seja um não-diretório e atualmente não tenha bits "x" configurados. O "s" (configura uid ou configura gid) pode apenas ser especificado para permissões de usuário ou de grupo. O "t" pode apenas ser especificado para permissões de usuário. Uns poucos exemplos com ajuda. Acima nós vimos que /usr/bin/passwd tinha 6555 (-r-sr-sr-x no ls). Aqui estão alguns caminhos para que aquilo seja alcançado:
chmod 6555 /usr/bin/passwd
chmod u=rxs,g=rxs,o=rx /usr/bin/passwd
chmod ug=rxs,o=rx /usr/bin/passwd
chmod a=rx,ug+s /usr/bin/passwd
E existem muitas outras maneiras de se fazer isso.
Para a maior parte, chmod é imune a umask em quaisquer daqueles bits que ele deseje configurar, não seja modificado por umask. Entretanto, sob uma condição, o comando chmod examinará a configuração atual de umask para determinar quais bits ele gostaria de configurar. Isso acontece quando você deixa o campo "quem" em branco. Como isso:
chmod =w algumarquivo
A diferença entre "a=w" and "=w" é sútil. Aqui está um exemplo que pode ajudar. Muitos aplicativos tentam criar arquivo com permissões 666 (-rw-rw-rw-). Porém, isso é modificado pelo umask. Suponha que você deseja configurar um arquivo para 666, porém modificado pelo umask atual. Nós poderíamos desligar todos os bits, então ligar os bits de leitura e escrita permitidos pelo umask atual:
chmod a=,=rw algumarquivo
E falando em umask, você pode utilizar argumentos simbólicos com o comando umask também. Entretanto, Posix, em sua sabedoria, decidiu que, nesse caso, a lógica seria reversa. Assim, se utilizar umask com um argumento octal, você especifica que os bits sejam proibidos. Porém, se você utiliza umask com um argumento simbólico, você especifica que os bits sejam permitidos. Então, esses são equivalentes:
umask 022
umask u=rwx,go=rx
Sumário
Neste ponto, você tem informação suficiente para entender a maior parte daqueles 12 bits de permissão. Existem vários casos especiais que eu ignorei ou camuflei. Nas postagens separadas abaixo, eu tratarei desses. A informação nesta primeira postagem é bastante universal. Um OS compatível com Posix deve suportar essas coisas. Isso cobre quase todas as versões de Unix lançadas nos últimos 10 anos. Os artigos seguintes discutem características que podem não serem universais.
Disponível em: <http://www.unix.com/tips-and-tutorials/19060-unix-file-permissions.html>. Acesso em: 01 set. 2014.
Jamenson Ferreira Espindula de Almeida Melo
Linux user nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJUBUtuAAoJECrgJcAIqGGAOSQIAILUDlkx0XJivgUEOh0newTr
DTxTWOOnHR2bf1NWUWWRzrFi/i3LJFH96IMOqfsSCQ5q/wopm4iN9Dvz5pnDd9nY
F24IJrSwiLQWQRSzmldRsCFaSfPth7s2cKMLdTYEIXkGCUmwFCnGDY43OCsoQVYC
Qz3sPXORXQCk3dsOvAJbJ75Zn3GeHa0LTRVLuQdn2slu3TvqyVXih5JqxkmHD0ld
D6ZtQBYfvk6z7Xug6GZFA52j7i8kZw+XBk3YgQuLTYpP8EkZlDsUDby/3SylDawU
6jpfTbU7c1es8EPqmEAjL/iC4LM9qJrnRcuTDqQyYCG5du+Y9UoBsm+FBros4Do=
=Gpfr
-----END PGP SIGNATURE-----
Hash: SHA1
Jaboatão dos Guararapes, PE, 02 de setembro de 2014.
Aqui está, em tradução livre para a língua portuguesa falada no Brasil, o texto postado por Perderabo "Permissões de Arquivos do Unix".
Unix File Permissions (Perderabo, 28/05/2005 - http://www.unix.com/tips-and-tutorials/19060-unix-file-permissions.html)
Introdução
Eu tenho visto alguma informação errada relativamente às permissões de arquivo do Unix. Eu tentarei esclarecer as coisas. Dá uma olhada neste exemplo de alguma saída do ls:
$ ls -ld /usr/bin /usr/bin/cat
drwxrwxr-x 3 root bin 8704 Sep 23 2004 /usr/bin
- -r-xr-xr-x 1 bin bin 9388 Jul 16 1997 /usr/bin/cat
$
Na primeira linha, aquele "root" diz que o diretório é propriedade do usuário chamado "root". E que "bin" ś o grupo do diretório. Você precisará entender usuários e grupos e eu presumirei que você entende. Meu objetivo é explicar aquelas "drwxrwxr-x" e "-r-xr-xr-x" coisas. Aquele campo é uma combinação do tipo do arquivo e permissão de acesso. Coletivamente, essa informação é algumas vezes chamada de modo do arquivo. E algumas vezes ela é chamada de permissões. Um bom lugar para começar é dando uma rápida olhada em como essa informação é atualmente armazenada no disco. A forma como ela é armazenada afeta um número de decisões que devem ser tomadas ao longo dos anos.
Como o "Modo do Arquivo" é armazenado.
No disco, informação acerca de um arquivo é armazenada em uma estrutura chamada um "inode". Cada arquivo tem o seu próprio inode. Um item de dados em um inode é chamado de "modo" e ele se parece com isto:
|---modo do arquivo---|
| |
|
| |--completo---|
|
|-tipo| | |-básico--|
| | | | |
oo0 000 000 000 000 000
... ... ... ... ... ...
| | | | |
| | | | |---- rwx para outros
| | | |
| | | |-------- rwx para grupo
| | |
| | |------------ rwx para usuário
| |
| |---------------- configura uid, configura gid, sticky bit
|
|---------------------- tipo do arquivo: comum (-)
diretório (d)
carácter especial (c)
bloco especial (b)
fifo (p)
ligação simbólica (l)
socket (s)
Eu entendo que o "modo" realmente significa simplesmente as permissões e que o tipo do arquivo foi enfiado para dentro para economizar espaço. Porém, o autor do aplicativo ls está tratando o modo como um item único. Eis o porque de o tipo do arquivo ser o primeiro carácter da sequência de permissão no saída de "ls -l". O tipo do arquivo usualmente será um dos sete tipos que eu mostrei acima. Algumas versões de Unix adicionarão alguns mais. A única outra coisa a saber a partir do formato é que não existe mais compartimento para adicionar mais bits de permissão.
Representando aquelas permissões em octal
O aplicativo ls pode exibir, digamos, "rwxrwxrwx" para as permissões em um arquivo. Também é muito comum utilizar um número octal para expressar as permissões em um arquivo. E como você vê acima, assim é como elas são armazenadas. Você pode escutar alguém dizer que alguns tem permissões 777. Isso é o mesmo que "rwxrwxrwx" e muito mais fácil de pronunciar. Então você precisa saber como convertê-los. Três dígitos binários ou bits correspondem a um dígito octal:
421
rwx
Assim, o bit de leitura tem valor 4, o bit de escrita tem valor 2, e o bit de execução tem valor 1. Você simplesmente adiciona tais valores para obter um dígito octal. Então, "-rwxrwxrwx" é 777. E "-rwxr-x---" é 750. Se você ainda não consegue ver como ir de "r-x" para 5, talvez esta tabela ajude:
- --- = 0
- --x = 1
- -w- = 2
- -wx = 3
r-- = 4
r-x = 5
rw- = 6
rwx = 7
Perceba que precisamos de 4 dígitos octais para exprimir todos os bits de permissões. Os primeiros três bits são especiais e são frequentemente zero. E você quase sempre aprende primeiro sobre os 9 bits seguintes. Algumas pessoas param aí e nunca aprendem aqueles primeiros três bits. Porém, existem 12 bits de permissão, não apenas 9. Dito isso, vamos agora dar uma olhada nos 9 bits seguintes.
Os Bits de Permissão Básicos
Nós temos 3 triplas: uma tripla para o usuário, uma tripla para o grupo, e uma tripla para outros. Algumas vezes o "usuário" é chamado de proprietário. E algumas vezes "outros" é chamado de "mundo" Eu utilizarei "usuário" e "outros" pois o comando chmod utiliza as letras "u", "g" e "o" para se referir àquelas triplas.
Qual Conjunto de Bits Aplica-se a Você?
Quando Unix decide o que você pode fazer, ele não utiliza todos os 9 bits. Unix pega a primeira tripla que aplica-se a você. Considere isto:
- ----rwxrwx 1 joe users 29 Mar 22 19:39 algumarquivo
Mesmo que joe seja dono desse arquivo, ele não pode acessá-lo. (Uma vez que joe é dono do arquivo, ele poderia dar acesso a ele próprio. Mais sobre isso depois). Também root é especial. A root é permitido rwx a todos os diretórios e rw a todos os arquivos. Em um arquivo, se quaisquer dos 3 bits estiverem configurados, root tem permissão de execução. Essa permissão especial é frequentemente desabilitada em sistemas de arquivos montados via rede.
O que "r", "w" e "x" realmente significam para um arquivo?
Para um arquivo, "read" [leitura] e "write" [escrita] são bastante intuitivos. O "x" para "execução" significa que o kernel pode tentar executar um arquivo. Para que isso funcione, o arquivo deve ser um executável (saída de um compilador) ou um script de shell com um "#!" na primeira linha. Para um diretório, as coisas são um pouco mais complexas. Com um diretório, a permissão "write" [escrita] significa que você pode criar novos arquivos em um diretório ou remover arquivos antigos. Ela as vezes surpreende as pessoas pois você pode remover um arquivo o qual você não pode ler. O comando rm do Unix testará tal situação e emitirá um alerta, porém você pode suprimir tal alerta com -f. E alertando ou não, se você deseja remover um arquivo ilegível de um diretório gravável, você pode. E rmdir não se preocupará em verificar de jeito nenhum.
O que "r", "w" e "x" realmente significam para um diretório?
Um diretório é um arquivo também, e a permissão "read" significa que você pode lê-lo. Porém você realmente não pode fazer muita coisa sem a permissão "x" também. Com diretórios, você usualmente tem ambas as permissões leitura e execução ou nenhuma. Em um diretório, aquele "x" é oficialmente chamado "permissão de busca". Você precisa de um "x" para utilizar um diretório em uma localização. Assim, se você tentar "cat /etc/passwd", você precisará do "x" em / e /etc. Você também precisa "x" para acessar o diretório com um cd. Suponha que você tenha permissão de leitura, mas não de busca (x) em um diretório. O que você pode fazer? Não muito. Você pode utilizar "ls" para visualizar os nomes de arquivos. Mesmo "ls -l" não funcionará. Acesso de leitura sem permissão de busca não é realmente útil. Ainda é melhor do que ter apenas permissão de escrita em um diretório... isso é completamente inútil. Eu não tenho visto qualquer outra documentação que declare isso explicitamente, de forma que permita-me repetir: escrita mas sem permissão de execução em um diretório não concede nada para ninguém. Suponha que você tenha permissão de busca (x), mas não permissão de leitura em um diretório. Agora você pode abrir arquivos em um diretório se acontecer de você saber o nome do arquivo. Você pode acessar o diretório [com cd]. E isso é tudo. Você não pode nem mesmo criar um arquivo novo. Adicionar permissão de escrita permitirá a você criar arquivos. E você pode então apagar arquivos se acontecer de você saber o nome deles.
Ligações Simbólicas São Especiais
As configurações de permissão em uma ligação simbólica são um pouco especiais também. Elas são completamente ignoradas. Muitas versões de Unix não tem um meio de mudá-las.
Os Bits Setuid e Setgid
Dá uma olhada nisto:
$ ls -l /etc/passwd /etc/shadow /usr/bin/passwd
- -r--r--r-- 1 root sys 14006 Jan 14 11:17 /etc/passwd
- -r-------- 1 root sys 8281 Jan 14 11:18 /etc/shadow
- -r-sr-sr-x 3 root sys 96244 Sep 5 2001 /usr/bin/passwd
O arquivo passwd é gravável apenas pelo root (lembre-se, root é especial. Ele pode gravar um arquivo que não tem permissões de escrita configuradas). O arquivo shadow, no qual senhas são armazenas, não pode nem mesmo ser lido por usuários comuns. Porém, joe deseja mudar a senha dele. Ele pode fazer isso executando /usr/bin/passwd. Perceba aquelas permissões r-s. O aplicativo passwd tem os bits suid e sgid configurados. Isso transforma os "x" em "s". Em octal, seria 6555. O aplicativo passwd é de propriedade do root. Quando joe o executa, ele não é executado como "joe". Ao invés disso, é executado como seu usuário que é o root. Assim, o aplicativo passwd pode mudar a senha de joe para ele. O bit sgid funciona da mesma maneira, exceto que ele faz com que o aplicativo passwd seja executado como grupo sys ao invés do grupo do joe. O suid e sgid não tem suas próprias posições no ls. Quando o bit suid está configurado, ls exibe um "s" no lugar de um "x" para a permissão de execução do proprietário. O que acontece se o bit suid estiver configurado, porém o bit de execução do proprietário estiver desligado? ls exibirá um "S" maiúsculo no caso. O bit sgid é exibido de uma maneira singular, exceto que ele interage com a permissão de execução do grupo. (O conceito do conjunto uid foi inventado por Dennis Ritchie quando ele estava desenvolvendo Unix).
Para expandir as coisas um pouco, enquanto que jos está executando o aplicativo suid-para-root passwd, "joe" é o uid real e "root" é o uid efetivo. O aplicativo passwd pode obter ambas dessas id's se ele desejar fazê-lo. Assim é como o aplicativo passwd sabe como permitir a joe mudar apenas a senha de joe.
O Bit Sticky
O padrão Posix diz que se o bit sticky estiver configurado para um diretório, a simples permissão de escrita no diretório não mais é suficiente para permitir que arquivos sejam removidos. Você deve adicionalmente ser dono do arquivo ou ser dono do diretório. root permanece sendo hábil para apagar de qualquer diretório independentemente das permissões. Antigamente esse bit servia a um outro propósito. Em alguns Sistemas Operacionais ele ainda serve. Eu completarei em um apêndice abaixo. O bit sticky afeta o bit de execução "outros" na exibição ls. Exceto pelo fato de que ele utiliza "t" e "T" no lugar de "s" e "S". Por exemplo:
drwxrwxrwt 5 root root 1024 Feb 11 20:43 /tmp
Naquele diretório /tmp acima, qualquer pessoa pode criar novos arquivos. Porém, por causa do bit sticky, um usuário não pode apagar os arquivos de um outro usuário.
Limitando Permissões de Arquivo com umask
Quando arquivos são criados, o aplicativo que os cria pode especificar a configuração inicial de permissão. Você pode sobrescrever isso com umask. O umask é um conjunto de bits de proibição. Existe um comando umask que te permite visualizar e mudar o umask. Por exemplo, "umask 022" proíbe escrita de grupo e escrita de outros em arquivos recém criados. Ou "umask 027" proíbe escrita de grupo e proíbe leitura, escrita e execução de outros. Você pode executar um "umask 0" para permitir que o aplicativo faça o que ele desejar a medida que ele cria aplicativos. Porém, você não pode ir mais além. Você não pode forçar um aplicativo a ligar um bit. A configuração de umask afeta arquivos, diretórios, pipes nomeados (também conhecidos como fifos), e arquivos especiais. Ele pode ou não pode afetar ligações simbólicas. Ele também afeta algumas formas de Comunicação Inter Processos (Inter Process Communication), mas isso está além do escopo deste artigo. E, acredite se quiser, sockets nomeados são imunes a umask. Essa imunidade é exigida por Posix.
Mudando Permissões de Arquivos com chmod
Apenas o proprietário de um arquivo pode mudar as permissões sobre um arquivo. Essa operação não é afetada de nenhuma maneira pela configuração de umask. Se você mudar as permissões sobre uma ligação simbólica, a ligação será seguida e você mudará o arquivo alvo. É possível que apenas o root tenha o poder de configurar um bit sticky de um arquivo. Como um exemplo, "chmod 700 algumarquivo" permitirá que o proprietário leia, escreva e execute o arquivo, enquanto que proíbe todo acesso a quaisquer outros usuários.
Utilizando Modo Simbólico com chmod e umask
Posix introduziu uma nova sintaxe para o comando chmod. A ideia foi que a nova sintaxe substituirá o uso de uma constante octal com o comando chmod. A constante octal ainda é válida e eu entendo que ela chegou para ficar. Porém, a nova sintaxe simbólica te permite mudar uns poucos bits sem o conhecimento do que os outros são. Por exemplo, digamos que eu deseje tornar um arquivo inacessível para outros, mas eu não desejo mudar o acesso para o usuário ou o grupo. Eu precisaria fazer:
ls -l arquivo
Olhar para o arquivo e descobrir as configurações atuais.
chmod 750 arquivo
Eu tive de determinar que os primeiros dois dígitos são atuais 7 e 5 antes que podesse executar meu comando chmod. Com a nova sintaxe, eu posso simplesmente fazer:
chmod o= arquivo
para desligar os 3 bits finais. Como um outro exemplo, "chmod u+x file" permitirá que o usuário execute o arquivo. Por outro lado, esses dois comandos são equivalentes:
chmod 750 arquivo
chmod u=rwx,g=rx,o= arquivo
e eu prefiro a primeira sintaxe.
O modo simbólico pode ser uma lista de especificações separada por vírgulas. Cada especificação tem três componentes: <quem><operação><bitlist>
A parte quem pode ser:
u (usuário)
g (grupo)
o (outros)
a (all - todos)
(o que seja permitido por umask (subconjunto de tudo))
A operação pode ser = ou - ou +
= (configura para bitlist)
- - (subtrai bitlist do bit atual
+ (adiciona bitllist aos bits atuais)
A bitlist pode ser uma das seguintes letras:
r (permissão de leitura - read)
w (permissão de escrita - write)
x (permissão de execução - execute)
X (permissão condicional de execução)
u (permissões atuais para o usuário)
g (permissões atuais para o grupo)
o (permissões atuais para outros)
s (configura uid ou configura gid)
t (sticky bit)
O "X" é o mesmo que "x" a menos que o arquivo seja um não-diretório e atualmente não tenha bits "x" configurados. O "s" (configura uid ou configura gid) pode apenas ser especificado para permissões de usuário ou de grupo. O "t" pode apenas ser especificado para permissões de usuário. Uns poucos exemplos com ajuda. Acima nós vimos que /usr/bin/passwd tinha 6555 (-r-sr-sr-x no ls). Aqui estão alguns caminhos para que aquilo seja alcançado:
chmod 6555 /usr/bin/passwd
chmod u=rxs,g=rxs,o=rx /usr/bin/passwd
chmod ug=rxs,o=rx /usr/bin/passwd
chmod a=rx,ug+s /usr/bin/passwd
E existem muitas outras maneiras de se fazer isso.
Para a maior parte, chmod é imune a umask em quaisquer daqueles bits que ele deseje configurar, não seja modificado por umask. Entretanto, sob uma condição, o comando chmod examinará a configuração atual de umask para determinar quais bits ele gostaria de configurar. Isso acontece quando você deixa o campo "quem" em branco. Como isso:
chmod =w algumarquivo
A diferença entre "a=w" and "=w" é sútil. Aqui está um exemplo que pode ajudar. Muitos aplicativos tentam criar arquivo com permissões 666 (-rw-rw-rw-). Porém, isso é modificado pelo umask. Suponha que você deseja configurar um arquivo para 666, porém modificado pelo umask atual. Nós poderíamos desligar todos os bits, então ligar os bits de leitura e escrita permitidos pelo umask atual:
chmod a=,=rw algumarquivo
E falando em umask, você pode utilizar argumentos simbólicos com o comando umask também. Entretanto, Posix, em sua sabedoria, decidiu que, nesse caso, a lógica seria reversa. Assim, se utilizar umask com um argumento octal, você especifica que os bits sejam proibidos. Porém, se você utiliza umask com um argumento simbólico, você especifica que os bits sejam permitidos. Então, esses são equivalentes:
umask 022
umask u=rwx,go=rx
Sumário
Neste ponto, você tem informação suficiente para entender a maior parte daqueles 12 bits de permissão. Existem vários casos especiais que eu ignorei ou camuflei. Nas postagens separadas abaixo, eu tratarei desses. A informação nesta primeira postagem é bastante universal. Um OS compatível com Posix deve suportar essas coisas. Isso cobre quase todas as versões de Unix lançadas nos últimos 10 anos. Os artigos seguintes discutem características que podem não serem universais.
Disponível em: <http://www.unix.com/tips-and-tutorials/19060-unix-file-permissions.html>. Acesso em: 01 set. 2014.
Jamenson Ferreira Espindula de Almeida Melo
Linux user nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJUBUtuAAoJECrgJcAIqGGAOSQIAILUDlkx0XJivgUEOh0newTr
DTxTWOOnHR2bf1NWUWWRzrFi/i3LJFH96IMOqfsSCQ5q/wopm4iN9Dvz5pnDd9nY
F24IJrSwiLQWQRSzmldRsCFaSfPth7s2cKMLdTYEIXkGCUmwFCnGDY43OCsoQVYC
Qz3sPXORXQCk3dsOvAJbJ75Zn3GeHa0LTRVLuQdn2slu3TvqyVXih5JqxkmHD0ld
D6ZtQBYfvk6z7Xug6GZFA52j7i8kZw+XBk3YgQuLTYpP8EkZlDsUDby/3SylDawU
6jpfTbU7c1es8EPqmEAjL/iC4LM9qJrnRcuTDqQyYCG5du+Y9UoBsm+FBros4Do=
=Gpfr
-----END PGP SIGNATURE-----
domingo, 31 de agosto de 2014
mtime, ctime, and atime (Perderabo, 31/07/2005)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jaboatão dos Guararapes, PE, 31 de agosto de 2014.
Tradução livre para a lingua portuguesa de texto postado por Perderabo (em 31/07/2005 - http://www.unix.com/tips-and-tutorials/20526-mtime-ctime-atime.html)
mtime, ctime, and atime (Perderabo, 31/07/2005)
O Unix mantém 3 marcas temporais para cada arquivo: mtime, ctime, e atime. A maioria das pessoas parece entender atime (access time), é quando o arquivo foi lido pela última vez. Parece existir alguma confusão entre mtime e ctime, no entanto. ctime é a hora de mudança do inode, enquanto que mtime é a hora de modificação do arquivo. "Mudança" e "modificação" são praticamente sinônimos. Não existe dica a saber ao se ponderar tais palavras. Ao invés disso, você precisa focar no que está sendo mudado. mtime muda quando você escreve no arquivo. Ele é a idade dos dados dentro do arquivo. Sempre que mtime muda, muda também ctime. Mas, ctime muda umas poucas vezes mais. Por exemplo, ele mudará se você mudar o proprietário ou as permissões sobre o arquivo.
Vamos dar uma olhada em um exemplo concreto. Nós executamos um pacote chamado Samba que permite acessos a arquivos de PC. Para mudar a configuração do Samba, eu simplesmente edito um arquivo chamado smb.conf. (Isso muda mtime e ctime). Eu não preciso adotar qualquer outra ação para instruir o Samba que eu mudei aquele arquivo. De vez em quando Samba examina o mtime no arquivo. Se o mtime mudou, Samba re-lê o arquivo. Mais tarde naquela noite nosso sistema de cópia de segurança executa. Ele utiliza ctime, o qual também mudou, de forma que ele produz uma cópia de segurança do arquivo. Porém, digamos que alguns dias depois eu perceba que as permissões de smb.conf são 666. Isso não é bom... qualquer pessoa pode editar o arquivo. Então eu faço um "chmod 644 smb.conf". Isso muda apenas ctime. O Samba não relerá o arquivo. Entretanto, mais tarde naquela noite, nosso aplicativo de cópia de segurança percebe que ctime tem mudanças, então ele produz uma cópia de segurança do arquivo. Dessa maneira, se nós perdermos o sistema e necessitarmos recarregar nossas cópias de segurança, nós obtemos a nova configuração de permissão melhorada.
Aqui está um segundo exemplo. Digamos que você tenha um arquivo de dados chamado employees.txt o qual é uma lista de empregados. E você tem um aplicativo para imprimi-lo. O aplicativo não apenas imprime os dados, mas ele obtém o mtime e o imprime também. Agora alguém solicitou uma lista de empregados do final do ano 2000 e você encontrou uma fita magnética de cópia de segurança que tem aquele arquivo. Muitos aplicativos de restauração restaurarão o mtime também. Quando você executar aquele aplicativo, ele imprimirá um mtime do final do ano 2000. Porém o ctime é hoje. Então, outra vez, nosso aplicativo de cópia de segurança verá o arquivo como necessário de ser copiado.
Suponha que o seu aplicativo de restauração não restaurou o mtime. Você não quer que o seu aplicativo imprima a data de hoje. Bem, sem problema. mtime está sob seu controle. Você pode configurá-lo para o que você quiser. Então, simplesmente faça:
$ touch -t 200012311800 employees.txt
Isso configurará o mtime de volta à data que você quer e ele configura ctime para agora. Você tem controle completo sobre mtime, porém o sistema permanece no controle do ctime. Então, mtime é um pouco como a data em uma carta, enquanto que ctime é como o carimbo de postagem no envelope.
Jamenson Ferreira Espindula de Almeida Melo
Linux user nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJUAqjzAAoJECrgJcAIqGGAwJ8H/1JFDWVd+Ix1jRVbCvhF+LkD
U6ee/QhR3yqHD4PsYiCrjWZzdOpC5ZQXYwAFaAhAwdIDJuyOsaZn57w5u1u/Hgkf
aBXljT1Bk6UKBkpVY0NiEwWABl2xjtBPuSLVTi0ml1g/UoraOIYPhUQTU4hlvvg7
ogmrTOyeFvDoPV7kxK90enNNtcZmHGiCwYdQQnZCSQHjBQvbDKYgOgZRwpBS7yne
Ol1NNdhw7dRlrdtvbO7skmC297T4Gt8Pc0UkV2utRJQigDbWh/pYNgWBpADZ1P+G
MnqCDNqA9ZDFxIdbO6JnRjO8ygbsSdzdnZ4stCs//MsVdJ+dFhPDV3KAMSpH0F8=
=1+7B
-----END PGP SIGNATURE-----
Hash: SHA1
Jaboatão dos Guararapes, PE, 31 de agosto de 2014.
Tradução livre para a lingua portuguesa de texto postado por Perderabo (em 31/07/2005 - http://www.unix.com/tips-and-tutorials/20526-mtime-ctime-atime.html)
mtime, ctime, and atime (Perderabo, 31/07/2005)
O Unix mantém 3 marcas temporais para cada arquivo: mtime, ctime, e atime. A maioria das pessoas parece entender atime (access time), é quando o arquivo foi lido pela última vez. Parece existir alguma confusão entre mtime e ctime, no entanto. ctime é a hora de mudança do inode, enquanto que mtime é a hora de modificação do arquivo. "Mudança" e "modificação" são praticamente sinônimos. Não existe dica a saber ao se ponderar tais palavras. Ao invés disso, você precisa focar no que está sendo mudado. mtime muda quando você escreve no arquivo. Ele é a idade dos dados dentro do arquivo. Sempre que mtime muda, muda também ctime. Mas, ctime muda umas poucas vezes mais. Por exemplo, ele mudará se você mudar o proprietário ou as permissões sobre o arquivo.
Vamos dar uma olhada em um exemplo concreto. Nós executamos um pacote chamado Samba que permite acessos a arquivos de PC. Para mudar a configuração do Samba, eu simplesmente edito um arquivo chamado smb.conf. (Isso muda mtime e ctime). Eu não preciso adotar qualquer outra ação para instruir o Samba que eu mudei aquele arquivo. De vez em quando Samba examina o mtime no arquivo. Se o mtime mudou, Samba re-lê o arquivo. Mais tarde naquela noite nosso sistema de cópia de segurança executa. Ele utiliza ctime, o qual também mudou, de forma que ele produz uma cópia de segurança do arquivo. Porém, digamos que alguns dias depois eu perceba que as permissões de smb.conf são 666. Isso não é bom... qualquer pessoa pode editar o arquivo. Então eu faço um "chmod 644 smb.conf". Isso muda apenas ctime. O Samba não relerá o arquivo. Entretanto, mais tarde naquela noite, nosso aplicativo de cópia de segurança percebe que ctime tem mudanças, então ele produz uma cópia de segurança do arquivo. Dessa maneira, se nós perdermos o sistema e necessitarmos recarregar nossas cópias de segurança, nós obtemos a nova configuração de permissão melhorada.
Aqui está um segundo exemplo. Digamos que você tenha um arquivo de dados chamado employees.txt o qual é uma lista de empregados. E você tem um aplicativo para imprimi-lo. O aplicativo não apenas imprime os dados, mas ele obtém o mtime e o imprime também. Agora alguém solicitou uma lista de empregados do final do ano 2000 e você encontrou uma fita magnética de cópia de segurança que tem aquele arquivo. Muitos aplicativos de restauração restaurarão o mtime também. Quando você executar aquele aplicativo, ele imprimirá um mtime do final do ano 2000. Porém o ctime é hoje. Então, outra vez, nosso aplicativo de cópia de segurança verá o arquivo como necessário de ser copiado.
Suponha que o seu aplicativo de restauração não restaurou o mtime. Você não quer que o seu aplicativo imprima a data de hoje. Bem, sem problema. mtime está sob seu controle. Você pode configurá-lo para o que você quiser. Então, simplesmente faça:
$ touch -t 200012311800 employees.txt
Isso configurará o mtime de volta à data que você quer e ele configura ctime para agora. Você tem controle completo sobre mtime, porém o sistema permanece no controle do ctime. Então, mtime é um pouco como a data em uma carta, enquanto que ctime é como o carimbo de postagem no envelope.
Disponível em: <http://www.unix.com/tips-and-tutorials/20526-mtime-ctime-atime.html>. Acesso em: 31 ago. 2014.
Jamenson Ferreira Espindula de Almeida Melo
Linux user nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJUAqjzAAoJECrgJcAIqGGAwJ8H/1JFDWVd+Ix1jRVbCvhF+LkD
U6ee/QhR3yqHD4PsYiCrjWZzdOpC5ZQXYwAFaAhAwdIDJuyOsaZn57w5u1u/Hgkf
aBXljT1Bk6UKBkpVY0NiEwWABl2xjtBPuSLVTi0ml1g/UoraOIYPhUQTU4hlvvg7
ogmrTOyeFvDoPV7kxK90enNNtcZmHGiCwYdQQnZCSQHjBQvbDKYgOgZRwpBS7yne
Ol1NNdhw7dRlrdtvbO7skmC297T4Gt8Pc0UkV2utRJQigDbWh/pYNgWBpADZ1P+G
MnqCDNqA9ZDFxIdbO6JnRjO8ygbsSdzdnZ4stCs//MsVdJ+dFhPDV3KAMSpH0F8=
=1+7B
-----END PGP SIGNATURE-----
segunda-feira, 25 de agosto de 2014
Teclado Zmax (Vendor 0x4d9 Product 0x1702) desconfigurado dentro do ambiente do Servidor X
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jaboatão dos Guararapes, PE, 25 de agosto de 2014.
Assunto: Teclado Zmax (Vendor 0x4d9 Product 0x1702) desconfigurado dentro do ambiente do Servidor X.
__________________________
Configuração correta [no arquivo /etc/X11/xorg.conf.d/90-zmax-keyboard.conf]:
Section "InputClass"
Identifier "teclado Zmax"
MatchIsKeyboard "on"
Option "XkbRules" "xorg"
Option "XkbModel" "abnt2"
Option "XkbLayout" "br"
Option "XkbVariant" "abnt2"
EndSection
________________________________
Saída do comando "cat /var/log/Xorg.0.log | egrep 40[3,4]":
[ 11408.403] (II) config/udev: Adding input device SIGMACHIP Usb Mouse (/dev/input/mouse0)
[ 11408.403] (II) No input driver specified, ignoring this device.
[ 11408.403] (II) This device may have been added with another device file.
[ 11408.403] (II) config/udev: Adding input device USB Keyboard (/dev/input/event6)
[ 11408.403] (**) USB Keyboard: Applying InputClass "evdev keyboard catchall"
[ 11408.403] (**) USB Keyboard: Applying InputClass "teclado Zmax"
[ 11408.403] (II) Using input driver 'evdev' for ' USB Keyboard'
[ 11408.403] (**) USB Keyboard: always reports core events
[ 11408.403] (**) evdev: USB Keyboard: Device: "/dev/input/event6"
[ 11408.403] (--) evdev: USB Keyboard: Vendor 0x4d9 Product 0x1702
[ 11408.403] (--) evdev: USB Keyboard: Found keys
[ 11408.403] (II) evdev: USB Keyboard: Configuring as keyboard
[ 11408.403] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.3/1-3.3:1.0/input/input9/event6"
[ 11408.403] (II) XINPUT: Adding extended input device " USB Keyboard" (type: KEYBOARD, id 11)
[ 11408.403] (**) Option "xkb_rules" "evdev"
[ 11408.404] (**) Option "xkb_model" "abnt2"
[ 11408.404] (**) Option "xkb_layout" "br"
[ 11408.404] (**) Option "xkb_variant" "abnt2"
[ 11408.404] (II) config/udev: Adding input device USB Keyboard (/dev/input/event7)
[ 11408.404] (**) USB Keyboard: Applying InputClass "evdev keyboard catchall"
[ 11408.404] (**) USB Keyboard: Applying InputClass "teclado Zmax"
[ 11408.404] (II) Using input driver 'evdev' for ' USB Keyboard'
[ 11408.404] (**) USB Keyboard: always reports core events
[ 11408.404] (**) evdev: USB Keyboard: Device: "/dev/input/event7"
[ 11408.404] (--) evdev: USB Keyboard: Vendor 0x4d9 Product 0x1702
[ 11408.404] (--) evdev: USB Keyboard: Found keys
[ 11408.404] (II) evdev: USB Keyboard: Configuring as keyboard
[ 11408.404] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.3/1-3.3:1.1/input/input10/event7"
[ 11408.404] (II) XINPUT: Adding extended input device " USB Keyboard" (type: KEYBOARD, id 12)
________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJT+seBAAoJECrgJcAIqGGAhG8H/06XgYsLdPbwGdezK3ofsJV6
WbhfqY0Qh/NC4xSB6UT51h649iwppMBZ2poGGRgGWAsBFC/X9l2Lti8IcOQlkPt1
6pTsJEAjv4YBhrHL46duGXVpkHrSTXTG8COg8GH7xSvBQwNsGO9qn+HqFXXGtIjo
fdu+D6dXqizhS7lFz568+VJorCH752JuHPqc+5YB/3PDSeTEHrOCVpE+JllBQMWe
YrjHqYxVWycAHd4YjwXCqL9PEaR6DS/4jcf4qErno2Y0grMx/yLQhCx9MmdrxjWK
ZsirjLJ1/lvzO/fHUpbAwZ6PnerC2mV07naIsYB1uOO968EuV3t8gsOjYBGLeXM=
=Wo56
-----END PGP SIGNATURE-----
Hash: SHA1
Jaboatão dos Guararapes, PE, 25 de agosto de 2014.
Assunto: Teclado Zmax (Vendor 0x4d9 Product 0x1702) desconfigurado dentro do ambiente do Servidor X.
__________________________
Configuração correta [no arquivo /etc/X11/xorg.conf.d/90-zmax-keyboard.conf]:
Section "InputClass"
Identifier "teclado Zmax"
MatchIsKeyboard "on"
Option "XkbRules" "xorg"
Option "XkbModel" "abnt2"
Option "XkbLayout" "br"
Option "XkbVariant" "abnt2"
EndSection
________________________________
Saída do comando "cat /var/log/Xorg.0.log | egrep 40[3,4]":
[ 11408.403] (II) config/udev: Adding input device SIGMACHIP Usb Mouse (/dev/input/mouse0)
[ 11408.403] (II) No input driver specified, ignoring this device.
[ 11408.403] (II) This device may have been added with another device file.
[ 11408.403] (II) config/udev: Adding input device USB Keyboard (/dev/input/event6)
[ 11408.403] (**) USB Keyboard: Applying InputClass "evdev keyboard catchall"
[ 11408.403] (**) USB Keyboard: Applying InputClass "teclado Zmax"
[ 11408.403] (II) Using input driver 'evdev' for ' USB Keyboard'
[ 11408.403] (**) USB Keyboard: always reports core events
[ 11408.403] (**) evdev: USB Keyboard: Device: "/dev/input/event6"
[ 11408.403] (--) evdev: USB Keyboard: Vendor 0x4d9 Product 0x1702
[ 11408.403] (--) evdev: USB Keyboard: Found keys
[ 11408.403] (II) evdev: USB Keyboard: Configuring as keyboard
[ 11408.403] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.3/1-3.3:1.0/input/input9/event6"
[ 11408.403] (II) XINPUT: Adding extended input device " USB Keyboard" (type: KEYBOARD, id 11)
[ 11408.403] (**) Option "xkb_rules" "evdev"
[ 11408.404] (**) Option "xkb_model" "abnt2"
[ 11408.404] (**) Option "xkb_layout" "br"
[ 11408.404] (**) Option "xkb_variant" "abnt2"
[ 11408.404] (II) config/udev: Adding input device USB Keyboard (/dev/input/event7)
[ 11408.404] (**) USB Keyboard: Applying InputClass "evdev keyboard catchall"
[ 11408.404] (**) USB Keyboard: Applying InputClass "teclado Zmax"
[ 11408.404] (II) Using input driver 'evdev' for ' USB Keyboard'
[ 11408.404] (**) USB Keyboard: always reports core events
[ 11408.404] (**) evdev: USB Keyboard: Device: "/dev/input/event7"
[ 11408.404] (--) evdev: USB Keyboard: Vendor 0x4d9 Product 0x1702
[ 11408.404] (--) evdev: USB Keyboard: Found keys
[ 11408.404] (II) evdev: USB Keyboard: Configuring as keyboard
[ 11408.404] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.3/1-3.3:1.1/input/input10/event7"
[ 11408.404] (II) XINPUT: Adding extended input device " USB Keyboard" (type: KEYBOARD, id 12)
________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJT+seBAAoJECrgJcAIqGGAhG8H/06XgYsLdPbwGdezK3ofsJV6
WbhfqY0Qh/NC4xSB6UT51h649iwppMBZ2poGGRgGWAsBFC/X9l2Lti8IcOQlkPt1
6pTsJEAjv4YBhrHL46duGXVpkHrSTXTG8COg8GH7xSvBQwNsGO9qn+HqFXXGtIjo
fdu+D6dXqizhS7lFz568+VJorCH752JuHPqc+5YB/3PDSeTEHrOCVpE+JllBQMWe
YrjHqYxVWycAHd4YjwXCqL9PEaR6DS/4jcf4qErno2Y0grMx/yLQhCx9MmdrxjWK
ZsirjLJ1/lvzO/fHUpbAwZ6PnerC2mV07naIsYB1uOO968EuV3t8gsOjYBGLeXM=
=Wo56
-----END PGP SIGNATURE-----
quinta-feira, 21 de agosto de 2014
Console no GNU/Linux
Jaboatão dos Guararapes, PE, 21 de agosto de 2014.
Eis uma tradução livre para a língua portuguesa (português brasileiro) do documento intitulado "console.txt", de autoria de Antonino Daplas. Esse documento está armazenado sob o diretório "Documentation/console" (linux/Documentation/console/).
Console Drivers
==========
O kernel do linux tem 2 tipos gerais de drivers de console. O
primeiro tipo é atribuído pelo kernel a todos os consoles virtuais
durante o processo de inicialização. Esse tipo será chamado 'driver
de sistema', e é permitido existir apenas um driver de sistema. O
driver de sistema é do tipo persistente e nunca pode ser descarregado,
apesar de eventualmente poder se tornar inativo.
O segundo tipo deve ser explicitamente carregado e descarregado. Esse
será chamado de 'driver modular' por este documento. Múltiplos drivers
modulares podem coexistir a qualquer tempo, cada qual compartilhando o
console com outros drivers, incluindo o driver de sistema. Entretanto,
drivers modulares não podem apossar-se de console que esteja atualmente
ocupado por algum outro driver modular. (Exceção: Drivers que chamarem
do_take_over_console() terão sucesso no apossamento independentemente do tipo do driver ocupando os consoles). Eles apenas podem apossar-se de
console que esteja ocupado por driver de sistema. Dentro do mesmo
símbolo, se o driver modular estiver liberado pelo console, o driver de
sistema se apossará.
Drivers modulares, do ponto de vista do desenvolvedor, tem de chamar:
do_take_over_console() - carrega e vincula o driver à camada de console
give_up_console() - descarrega driver, funcionará apenas se o
driver for desvinculado completamente
Em kernels mais novos, as seguintes também estão disponíveis:
do_register_con_driver()
do_unregister_con_driver()
Se sysfs estiver habilitado, o conteúdo de /sys/class/vtconsole pode ser
examinado. Isso mostra as infra-estruturas do console atualmente registrado pelo sistema, os quais são chamados vtcon<n>, onde <n> é um número inteiro de 0 até 15. Assim:
ls /sys/class/vtconsole
. .. vtcon0 vtcon1
Cada diretório em /sys/class/vtconsole tem 3 arquivos:
ls /sys/class/vtconsole/vtcon0
. .. bind name uevent
O que esses arquivos significam?
1. bind - este é um arquivo leitura/escrita. Ele mostra o estado
do driver se leitura, ou atua para vincular ou desvincular o
driver aos consoles virtuais quando escritos. Os valores
possíveis são:
0 - significa que o driver não está vinculado e se echo'ed,
ordena a desvinculação do driver
1 - significa que o driver está vinculado e se echo'ed, ordena a
vinculação do driver
2. name - arquivo somente-leitura. Mostra o nome do driver neste
formato:
cat /sys/class/vtconsole/vtcon0/name
(S) VGA+
'(S)' significa driver de (S)istema, isto é, não pode ser
diretamente comandado para vincular ou desvincular
'VGA+' é o nome do driver
cat /sys/class/vtconsole/vtcon1/name
(M) frame buffer device
Nesse caso, '(M)' significa um driver (M)odular, um que pode
ser diretamente comandado para vincular ou desvincular.
3. uevent - ignore este arquivo
Quando do desvinculamento, o driver modular primeiro é isolado, e então
o driver de sistema se apossa do console vago pelo driver.
Vinculamento, por outro lado, vinculará o driver aos consoles que estão
atualmente ocupados por um driver de sistema.
NOTA1: Vinculamento e desvinculamento devem ser selecionados em Kconfig. Isso é feito sob:
Device Drivers -> Character devices -> Support for binding and unbinding
console drivers
NOTA2: Se quaisquer dos consoles virtuais estiverem no modo KD_GRAPHICS, então o vinculamento e desvinculamento não ocorrerá. Um exemplo de uma aplicação que configura o console para KD_GRAPHICS é o servidor X.
O quão útil é esta característica? Isto é bastante útil para
desenvolvedores de drivers de console. Desvinculando o driver da camada
de console, uma pessoa pode descarregar o driver, produzir mudanças,
recompilar, recarregar e revincular o driver sem qualquer necessidade de
reinicializar o kernel. Para usuários comuns que desejarem alternar do
console framebuffer para o console VGA e vice versa, esta característica
também torna isso possível. (NOTA NOTA NOTA: Por favor, leia fbcon.txt
sob Documentation/fb para mais detalhes).
Notas para desenvolvedores:
==========================
do_take_over_console() está atualmente quebrado em:
do_register_con_driver()
do_bind_con_driver() - função privada
give_up_console() é uma embalagem para do_unregister_con_driver(), e um
driver deve ser completamente desvinculado para essa chamada ter
sucesso. con_is_bound() verificará se o driver está vinculado ou
não.
Orientações para escritores de drivers de console:
=================================================
Para que o vinculamento e desvinculamento de um console funcione
adequadamente, drivers de console devem seguir estas orientações:
1. Todos os drivers, exceto drivers de sistema, devem chamar ou
do_register_con_driver() ou do_take_over_console().
do_register_con_driver() apenas adicionará o driver à lista interna do
console. Ela não se apossa do console. do_take_over_console(), como
o nome implica, apenas se apossará (ou vínculo a) do console.
2. Todos os recursos alocados durante con->con_init() devem ser
liberados em con->con_deinit().
3. Todos os recursos alocados em con->con_startup() devem ser liberados
quando o driver, que foi previamente vinculado, se tornar desvinculado.
A camada de console não tem uma chamada complementar a con->con_startup(), de forma que compete completamente ao driver verificar quando for lícito liberar tais recursos. A chamada con_is_bound() em con->con_deinit() ajudará. Se a chamada retornou false(), então é seguro liberar os recursos. Tal balanço tem de ser feito pois con->con_startup() pode ser chamado novamente quando uma requisição para revincular o driver ao console chegar.
4. Quando da saída do driver, assegure-se de que o driver esteja
totalmente desvinculado. Se a condição estiver satisfeita, então o
driver deve chamar do_unregister_con_driver() ou give_up_console().
5. do_unregister_con_driver() também pode ser chamado em condições que
tornem impossível para o driver atender a requisições do console. Isso
pode acontecer com o console framebuffer que repentinamente perca todos
os seus drivers.
A safra atual de drivers de console ainda deveria funcionar corretamente,
porém o vinculamento e desvinculamento deles podem causar problemas.
Com ajustes mínimos, esses drivers podem funcionar corretamente.
==========================
Antonino Daplas <adaplas@pol.net>
quarta-feira, 23 de julho de 2014
Computador não inicializa [GNU GRUB 2.0]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jaboatão dos Guararapes, PE, 23 de julho de 2014.
Assunto: Computador não inicializa [GNU GRUB 2.0]
Problema: ao ligar o computador, apenas aparece o prompt do GNU GRUB 2.0.
Solução encontrada:
grub> linux (hd0,msdos3)/boot/vmlinuz-3.15.5-jfeam root=/dev/sda3 # Carrega o kernel Debian GNU/Linux 7.6
grub> initrd (hd0,msdos3)/boot/initrd.img-3.5.15-jfeam # Inicial RAM Disc para Debian
grub> boot
Já dentro do ambiente operacional:
update-grub
grub-install --recheck /dev/sda
______________________________________
Entendendo o solução aplicada:
A ideia era tentar instalar o GNU GRUB na partição sda4 (/dev/sda4) e, depois, tentar gerar um DVD inicializável, somente com os dados da mencionada partição.
A primeira tentativa de instalar o GRUB na partição sda4 foi assim:
saída do comando: ( grub-install --recheck /dev/sda4 2>&1 | tee grub-install-recheck-sda4.log && exit $PIPESTATUS )
/sbin/grub-bios-setup: warning: File system `ext2' doesn't support embedding.
/sbin/grub-bios-setup: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
/sbin/grub-bios-setup: error: will not proceed with blocklists.
__________________________
Então partiu-se para uma segunda tentativa (totalmente desastrada!):
saída do comando: ( grub-install --recheck /dev/sda 2>&1 | tee grub-install-recheck-sda.log && exit $PIPESTATUS )
Installation finished. No error reported.
Após esse comando, os problemas começaram. Quando a máquina foi reiniciada, somente aparecia o prompt do GNU GRUB 2.0 (aquele famoso "grub>").
Ocorre que a instalação de GRUB na partição sda4 _não_ está totalmente configurada, fato que ocasionou de o carregador _não_ reconhecer o local onde o kernel e a initrd da Debian estavam instaladas.
_______________________________
Passos para inicializar o sistema [copiado do Manual do GNU GRUB 2.0 - http://www.gnu.org/software/grub/manual/grub.html#Role-of-a-boot-loader]:
Passo 1: Carregar o kernel utilizando o comando "linux":
grub> linux (hd0,msdos3)/boot/vmlinuz-3.15.5-jfeam root=/dev/sda3 # Carrega o kernel Debian GNU/Linux 7.6
__________________________
Passo 2: caso se utilize um initrd, execute o comando "initrd" após o comando "linux":
grub> initrd (hd0,msdos3)/boot/initrd.img-3.5.15-jfeam # Inicial RAM Disc para Debian
_________________________
Passo 3: inicializar
Finalmente, execute o comando "boot".
_________________________
Passo 4: Já dentro do ambiente operacional
update-grub
grub-install --recheck /dev/sda
________________________
Com isso a máquina está de volta a inicializar como antes.
É isso.
Jamenson Ferreira Espindula de Almeida Melo
Linux user nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
iQEcBAEBAgAGBQJTz8xnAAoJECrgJcAIqGGAH2gH/0Ul0X/xTAkkusFZe+JMHUPn
fZQBkVAzxzsmqp8IawW00Tolw/7HL1E0vo8zp9H9Sccv6+NODOXrVQ0I6PT9CMm5
jZpi76kfZgRw3fVT6GY5wycugwzWTG2REo4Yt4wNap9aW9FzHGqm302yzzDhkFtc
YbfXd6hcZ14CfupxqntrWyGTLoiZdRhXOcJd388DPM5jj9MX+JQ2M1XsFjPxOHoV
59MTkSboCS0yWRMspuAhJyc2v67r1nQtTBXJ4py9mHn6Zqm2A4Wp21EFjyCvaUvW
oF4DUEhwYaUDpbIDaNigU2IBYyXvLdEOk0Y81G01b0+B9B/yjpOdMNYYPbgPBsY=
=T723
-----END PGP SIGNATURE-----
Hash: SHA1
Jaboatão dos Guararapes, PE, 23 de julho de 2014.
Assunto: Computador não inicializa [GNU GRUB 2.0]
Problema: ao ligar o computador, apenas aparece o prompt do GNU GRUB 2.0.
Solução encontrada:
grub> linux (hd0,msdos3)/boot/vmlinuz-3.15.5-jfeam root=/dev/sda3 # Carrega o kernel Debian GNU/Linux 7.6
grub> initrd (hd0,msdos3)/boot/initrd.img-3.5.15-jfeam # Inicial RAM Disc para Debian
grub> boot
Já dentro do ambiente operacional:
update-grub
grub-install --recheck /dev/sda
______________________________________
Entendendo o solução aplicada:
A ideia era tentar instalar o GNU GRUB na partição sda4 (/dev/sda4) e, depois, tentar gerar um DVD inicializável, somente com os dados da mencionada partição.
A primeira tentativa de instalar o GRUB na partição sda4 foi assim:
saída do comando: ( grub-install --recheck /dev/sda4 2>&1 | tee grub-install-recheck-sda4.log && exit $PIPESTATUS )
/sbin/grub-bios-setup: warning: File system `ext2' doesn't support embedding.
/sbin/grub-bios-setup: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
/sbin/grub-bios-setup: error: will not proceed with blocklists.
__________________________
Então partiu-se para uma segunda tentativa (totalmente desastrada!):
saída do comando: ( grub-install --recheck /dev/sda 2>&1 | tee grub-install-recheck-sda.log && exit $PIPESTATUS )
Installation finished. No error reported.
Após esse comando, os problemas começaram. Quando a máquina foi reiniciada, somente aparecia o prompt do GNU GRUB 2.0 (aquele famoso "grub>").
Ocorre que a instalação de GRUB na partição sda4 _não_ está totalmente configurada, fato que ocasionou de o carregador _não_ reconhecer o local onde o kernel e a initrd da Debian estavam instaladas.
_______________________________
Passos para inicializar o sistema [copiado do Manual do GNU GRUB 2.0 - http://www.gnu.org/software/grub/manual/grub.html#Role-of-a-boot-loader]:
Passo 1: Carregar o kernel utilizando o comando "linux":
grub> linux (hd0,msdos3)/boot/vmlinuz-3.15.5-jfeam root=/dev/sda3 # Carrega o kernel Debian GNU/Linux 7.6
__________________________
Passo 2: caso se utilize um initrd, execute o comando "initrd" após o comando "linux":
grub> initrd (hd0,msdos3)/boot/initrd.img-3.5.15-jfeam # Inicial RAM Disc para Debian
_________________________
Passo 3: inicializar
Finalmente, execute o comando "boot".
_________________________
Passo 4: Já dentro do ambiente operacional
update-grub
grub-install --recheck /dev/sda
________________________
Com isso a máquina está de volta a inicializar como antes.
É isso.
Jamenson Ferreira Espindula de Almeida Melo
Linux user nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
iQEcBAEBAgAGBQJTz8xnAAoJECrgJcAIqGGAH2gH/0Ul0X/xTAkkusFZe+JMHUPn
fZQBkVAzxzsmqp8IawW00Tolw/7HL1E0vo8zp9H9Sccv6+NODOXrVQ0I6PT9CMm5
jZpi76kfZgRw3fVT6GY5wycugwzWTG2REo4Yt4wNap9aW9FzHGqm302yzzDhkFtc
YbfXd6hcZ14CfupxqntrWyGTLoiZdRhXOcJd388DPM5jj9MX+JQ2M1XsFjPxOHoV
59MTkSboCS0yWRMspuAhJyc2v67r1nQtTBXJ4py9mHn6Zqm2A4Wp21EFjyCvaUvW
oF4DUEhwYaUDpbIDaNigU2IBYyXvLdEOk0Y81G01b0+B9B/yjpOdMNYYPbgPBsY=
=T723
-----END PGP SIGNATURE-----
Backup da base do Sistema Operacional Linux From Scratch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jaboatão dos Guararapes, PE, 23 de julho de 2014.
_____________________________
Backup da base do Sistema Operacional
Problema: criar uma cópia de segurança da base do Sistema Operacional e gravar em um _único_ DVD.
Solução encontrada: utilizar o GNU GRUB para copiar apenas os arquivos necessários.
____________________________
Comandos utilizados:
cd /home/usuario
mkdir iso
mount -v -t ext4 /dev/sda4 iso
grub-mkrescue -o backup.iso iso
____________________________
Conforme as instruções contidas no Manual do GNU GRUB 2.00 [http://www.gnu.org/software/grub/manual/grub.html#Making-a-GRUB-bootable-CD_002dROM]:
Isso produz um arquivo chamado backup.iso, o qual então pode ser gravado em um CD (ou um DVD), ou copiado para um dispositivo de armazenamento USB.
Com o procedimento mencionado, eu consegui copiar _exatamente_ a base do Sistema Operacional (todos os arquivos atualmente existentes na partição sda4), o que totalizou cerca de 1.4GB e coube inteiramente em um _único_ DVD-ROM, conforme o desejado.
É isso.
Obs.: Muito obrigado Djones Boni, P. J., Jacques Teixeira e Antonio Novaes pelas excelentes dicas!
Jamenson Ferreira Espindula de Almeida Melo
Usuário Linux nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
iQEcBAEBAgAGBQJTz5CnAAoJECrgJcAIqGGAlHEIAKNNzIAH7p3wOo2MvB62jCXv
7geXUA0+3e/0r92eM7UYITAHfGm9pMjWO355gDKrXpR5Tr261fwX3JG1VXUymJKf
cHVVSCxmr2W1xf2b6TC7CFNIkd0iBX2Iu17J3T7m3bIlU0rsTsQkbUiw2o/56h16
Yx1AMdgtdxrmJ32T1uV4YVsMn2UFLkOxReaC8ixu+KMiGiXmP+O9V3QEiPB2tzJl
5jXBaYt+zil8s9x7jO+bdXu4RIaMsHRfuhf9VclzxySmJ9arJb/t3rFHdGQlIpeP
T4KRoalXtg3HJKrgmPuDvfEDUs/2FDSvD9Pu25c/zjZDXCr41/gxkXGoAQkJuxM=
=h3mc
-----END PGP SIGNATURE-----
Hash: SHA1
Jaboatão dos Guararapes, PE, 23 de julho de 2014.
_____________________________
Backup da base do Sistema Operacional
Problema: criar uma cópia de segurança da base do Sistema Operacional e gravar em um _único_ DVD.
Solução encontrada: utilizar o GNU GRUB para copiar apenas os arquivos necessários.
____________________________
Comandos utilizados:
cd /home/usuario
mkdir iso
mount -v -t ext4 /dev/sda4 iso
grub-mkrescue -o backup.iso iso
____________________________
Conforme as instruções contidas no Manual do GNU GRUB 2.00 [http://www.gnu.org/software/grub/manual/grub.html#Making-a-GRUB-bootable-CD_002dROM]:
Isso produz um arquivo chamado backup.iso, o qual então pode ser gravado em um CD (ou um DVD), ou copiado para um dispositivo de armazenamento USB.
Com o procedimento mencionado, eu consegui copiar _exatamente_ a base do Sistema Operacional (todos os arquivos atualmente existentes na partição sda4), o que totalizou cerca de 1.4GB e coube inteiramente em um _único_ DVD-ROM, conforme o desejado.
É isso.
Obs.: Muito obrigado Djones Boni, P. J., Jacques Teixeira e Antonio Novaes pelas excelentes dicas!
Jamenson Ferreira Espindula de Almeida Melo
Usuário Linux nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
iQEcBAEBAgAGBQJTz5CnAAoJECrgJcAIqGGAlHEIAKNNzIAH7p3wOo2MvB62jCXv
7geXUA0+3e/0r92eM7UYITAHfGm9pMjWO355gDKrXpR5Tr261fwX3JG1VXUymJKf
cHVVSCxmr2W1xf2b6TC7CFNIkd0iBX2Iu17J3T7m3bIlU0rsTsQkbUiw2o/56h16
Yx1AMdgtdxrmJ32T1uV4YVsMn2UFLkOxReaC8ixu+KMiGiXmP+O9V3QEiPB2tzJl
5jXBaYt+zil8s9x7jO+bdXu4RIaMsHRfuhf9VclzxySmJ9arJb/t3rFHdGQlIpeP
T4KRoalXtg3HJKrgmPuDvfEDUs/2FDSvD9Pu25c/zjZDXCr41/gxkXGoAQkJuxM=
=h3mc
-----END PGP SIGNATURE-----
segunda-feira, 21 de julho de 2014
PIN-Entry-0.8.3 exige Xorg instalado?!
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
PIN-Entry-0.8.3 exige Xorg instalado?!
Jaboatão dos Guararapes, PE, Brasil, 20 de julho de 2014.
Problema: PIN Entry 8.0.3 não está sendo instalado (ambiente operacional: Linux From Scratch 7.5).
A solução encontrada: alterar (hack) o arquivo de configuração (o script configure) do pacote, comentando as três linhas responsáveis por impor o teste de verificação (linhas nº 10.026; 10.027; e 10.028), além de adicionar a opção de linha de comando [--with-x=no] ao tempo da execução do aludido script de configuração.
___________________________________________________
As explicações (entendendo o problema e a solução encontrada):
Eu finalizei recentemente a construção e instalação de um novo ambiente operacional Linux From Scratch em uma máquina. Eu não instalei qualquer software extra ainda. O primeiro que decidi instalar foi o GnuPG-2.0.22, o qual tem o PIN-Entry-0.8.3 como sendo Recomendado ("Exigência ao tempo da execução para a maioria das funcionalidades do pacote", escreveu Gerard Beekmans na versão 7.5 do livro Beyond Linux From Scratch [http://www.linuxfromscratch.org/blfs/view/stable/postlfs/gnupg.html]). Eis o registro (log) da configuração:
saída do comando [./configure --prefix=/usr]:
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking whether make sets $(MAKE)... (cached) yes
checking whether build environment is sane... yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking how to run the C preprocessor... gcc -E
checking for ranlib... ranlib
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether ln -s works... yes
checking for windres... no
checking for gitlog-to-changelog... no
checking if gcc supports -Wno-pointer-sign... yes
checking for ANSI C header files... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking termio.h usability... yes
checking termio.h presence... yes
checking for termio.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking for seteuid... yes
checking for stpcpy... yes
checking for mmap... yes
checking for mlock... yes
checking whether mlock is broken... no
checking for byte typedef... no
checking for ulong typedef... yes
checking for setcap... :
checking for cap_set_proc in -lcap... no
checking for initscr in -lncursesw... yes
checking for ncurses include dir... none
checking for glib-config... no
checking for GLIB - version >= 1.2.0... no
*** The glib-config script installed by GLIB could not be found
*** If GLIB was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the GLIB_CONFIG environment variable to the
*** full path to glib-config.
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking for iconv declaration...
extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
checking for pkg-config... /usr/bin/pkg-config
checking for gtk+-2... no
configure: WARNING: pkg-config could not find the module gtk+-2.0
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking whether g++ supports -fexceptions... yes
checking how to run the C++ preprocessor... g++ -E
checking for X... no
configure: error: Can't find X. Please check your installation and add the correct paths!
Conforme se pode constatar, o aplicativo está exigindo que o servidor X esteja instalado (tal dependência não está listada no livro e a promessa é a de que o PIN-Entry-0.8.3 pode ser instalado em um ambiente sem o servidor X instalado). Então, eu tentei um truque: desabilitar o servidor X na configuração do pacote, passando a opção [--without-x], conforme a própria ajuda contida no próprio arquivo de configuração [executar ./configure --help].
saída do comando [./configure --prefix=/usr --without-x]:
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking whether make sets $(MAKE)... (cached) yes
checking whether build environment is sane... yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking how to run the C preprocessor... gcc -E
checking for ranlib... ranlib
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether ln -s works... yes
checking for windres... no
checking for gitlog-to-changelog... no
checking if gcc supports -Wno-pointer-sign... yes
checking for ANSI C header files... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking termio.h usability... yes
checking termio.h presence... yes
checking for termio.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking for seteuid... yes
checking for stpcpy... yes
checking for mmap... yes
checking for mlock... yes
checking whether mlock is broken... no
checking for byte typedef... no
checking for ulong typedef... yes
checking for setcap... :
checking for cap_set_proc in -lcap... no
checking for initscr in -lncursesw... yes
checking for ncurses include dir... none
checking for glib-config... no
checking for GLIB - version >= 1.2.0... no
*** The glib-config script installed by GLIB could not be found
*** If GLIB was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the GLIB_CONFIG environment variable to the
*** full path to glib-config.
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking for iconv declaration...
extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
checking for pkg-config... /usr/bin/pkg-config
checking for gtk+-2... no
configure: WARNING: pkg-config could not find the module gtk+-2.0
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking whether g++ supports -fexceptions... yes
checking how to run the C++ preprocessor... g++ -E
checking for X... disabled
configure: error: Can't find X. Please check your installation and add the correct paths!
Não funcionou. Pesquisei a Internet buscando qualquer pista para solucionar esse problema, porém sem sucesso. Então, decidi escrever esta postagem. A propósito, esta mesma postagem já foi publicada no Fórum de Suporte a construtores de Linux From Scratch [http://linuxfromscratch.org/pipermail/blfs-support/2014-July/075296.html].
A solução encontrada também já foi descrita no Fórum acima mencionado [http://linuxfromscratch.org/pipermail/blfs-support/2014-July/075299.html]. Portanto, vou repetir aqui em lingua portuguesa.
Eis o truque que tentei e funcionou: alterar (hack) o arquivo de configuração (configure) do pacote, comentando as três linhas responsáveis por impor o teste de verificação (linhas nº 10.026; 10.027; e 10.028). Eis o texto das linhas mencionadas:
# if test "$no_x" = yes; then
# as_fn_error $? "Can't find X. Please check your installation and add the correct paths!" "$LINENO" 5
# fi
Entretanto, penso que a simples alteração é insuficiente. Então, decidi adicionar a opção de configuração [--with-x=no] (a qual explicitamente desabilita o X) à linha de comando exposta no livro BLFS 7.5:
saída do comando [./configure --prefix=/usr --with-x=no]:
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking whether make sets $(MAKE)... (cached) yes
checking whether build environment is sane... yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking how to run the C preprocessor... gcc -E
checking for ranlib... ranlib
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether ln -s works... yes
checking for windres... no
checking for gitlog-to-changelog... no
checking if gcc supports -Wno-pointer-sign... yes
checking for ANSI C header files... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking termio.h usability... yes
checking termio.h presence... yes
checking for termio.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking for seteuid... yes
checking for stpcpy... yes
checking for mmap... yes
checking for mlock... yes
checking whether mlock is broken... no
checking for byte typedef... no
checking for ulong typedef... yes
checking for setcap... :
checking for cap_set_proc in -lcap... no
checking for initscr in -lncursesw... yes
checking for ncurses include dir... none
checking for glib-config... no
checking for GLIB - version >= 1.2.0... no
*** The glib-config script installed by GLIB could not be found
*** If GLIB was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the GLIB_CONFIG environment variable to the
*** full path to glib-config.
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking for iconv declaration...
extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
checking for pkg-config... /usr/bin/pkg-config
checking for gtk+-2... no
configure: WARNING: pkg-config could not find the module gtk+-2.0
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking whether g++ supports -fexceptions... yes
checking how to run the C++ preprocessor... g++ -E
checking for X... disabled
checking for pthread_create in -lpthread... yes
checking for Qt... no
checking for moc... no
checking for rpath... yes
checking pkg-config is at least version 0.9.0... yes
checking for QT4_CORE... no
configure: creating ./config.status
config.status: creating assuan/Makefile
config.status: creating secmem/Makefile
config.status: creating pinentry/Makefile
config.status: creating curses/Makefile
config.status: creating gtk/Makefile
config.status: creating gtk+-2/Makefile
config.status: creating qt/Makefile
config.status: creating qt4/Makefile
config.status: creating w32/Makefile
config.status: creating doc/Makefile
config.status: creating Makefile
config.status: creating config.h
config.status: executing depfiles commands
configure:
Pinentry v0.8.3 has been configured as follows:
Revision: ce7f2e6 (52863)
Platform: x86_64-unknown-linux-gnu
Curses Pinentry ..: yes
GTK+ Pinentry ....: no
GTK+-2 Pinentry ..: no
Qt Pinentry ......: no
Qt4 Pinentry .....: no
W32 Pinentry .....: no
Fallback to Curses: yes
Default Pinentry .: pinentry-curses
Assim, o pacote PIN-Entry-0.8.3 foi devidamente configurado, compilado e instalado corretamente. Por sua vez, o GnuPG-2.0.22 também foi configurado, compilado e instalado corretamente (já testado!).
É isso.
Jamenson Ferreira Espindula de Almeida Melo
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
iQEcBAEBAgAGBQJTzMniAAoJECrgJcAIqGGAijEH/RRykBewwZrpR+SUfIgBqSon
QCe6Qww/0FFY448AeRIkdevBeF0vZJ+njJDB8XJ4MvHDnlS+IVRO9vwkzwGhvdm4
wCD+F0FKwH03nMOVcIFCzIV/XHABqaB1CSqijwpOcLklv4KcodcGfbwpkj+NRMlu
VpECESYZNcc79Fjq396OJmUcUqtx/mCtLY4dR0qVJO8uML4pwttQWRofcO0zV7Xi
Pxgg9P6HNzul5Ye2QdqLf6BeVEURPHY/SxZl2K1ubfE6G3zreFAAD0g0EkGBR7po
HmaI81+Iy5qqzWVtSKwazsDc/vAl0MmJNz86mE8xMYNYBUSj9oCIn72tXaaGaxw=
=+zGw
-----END PGP SIGNATURE-----
Hash: SHA1
PIN-Entry-0.8.3 exige Xorg instalado?!
Jaboatão dos Guararapes, PE, Brasil, 20 de julho de 2014.
Problema: PIN Entry 8.0.3 não está sendo instalado (ambiente operacional: Linux From Scratch 7.5).
A solução encontrada: alterar (hack) o arquivo de configuração (o script configure) do pacote, comentando as três linhas responsáveis por impor o teste de verificação (linhas nº 10.026; 10.027; e 10.028), além de adicionar a opção de linha de comando [--with-x=no] ao tempo da execução do aludido script de configuração.
___________________________________________________
As explicações (entendendo o problema e a solução encontrada):
Eu finalizei recentemente a construção e instalação de um novo ambiente operacional Linux From Scratch em uma máquina. Eu não instalei qualquer software extra ainda. O primeiro que decidi instalar foi o GnuPG-2.0.22, o qual tem o PIN-Entry-0.8.3 como sendo Recomendado ("Exigência ao tempo da execução para a maioria das funcionalidades do pacote", escreveu Gerard Beekmans na versão 7.5 do livro Beyond Linux From Scratch [http://www.linuxfromscratch.org/blfs/view/stable/postlfs/gnupg.html]). Eis o registro (log) da configuração:
saída do comando [./configure --prefix=/usr]:
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking whether make sets $(MAKE)... (cached) yes
checking whether build environment is sane... yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking how to run the C preprocessor... gcc -E
checking for ranlib... ranlib
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether ln -s works... yes
checking for windres... no
checking for gitlog-to-changelog... no
checking if gcc supports -Wno-pointer-sign... yes
checking for ANSI C header files... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking termio.h usability... yes
checking termio.h presence... yes
checking for termio.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking for seteuid... yes
checking for stpcpy... yes
checking for mmap... yes
checking for mlock... yes
checking whether mlock is broken... no
checking for byte typedef... no
checking for ulong typedef... yes
checking for setcap... :
checking for cap_set_proc in -lcap... no
checking for initscr in -lncursesw... yes
checking for ncurses include dir... none
checking for glib-config... no
checking for GLIB - version >= 1.2.0... no
*** The glib-config script installed by GLIB could not be found
*** If GLIB was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the GLIB_CONFIG environment variable to the
*** full path to glib-config.
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking for iconv declaration...
extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
checking for pkg-config... /usr/bin/pkg-config
checking for gtk+-2... no
configure: WARNING: pkg-config could not find the module gtk+-2.0
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking whether g++ supports -fexceptions... yes
checking how to run the C++ preprocessor... g++ -E
checking for X... no
configure: error: Can't find X. Please check your installation and add the correct paths!
Conforme se pode constatar, o aplicativo está exigindo que o servidor X esteja instalado (tal dependência não está listada no livro e a promessa é a de que o PIN-Entry-0.8.3 pode ser instalado em um ambiente sem o servidor X instalado). Então, eu tentei um truque: desabilitar o servidor X na configuração do pacote, passando a opção [--without-x], conforme a própria ajuda contida no próprio arquivo de configuração [executar ./configure --help].
saída do comando [./configure --prefix=/usr --without-x]:
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking whether make sets $(MAKE)... (cached) yes
checking whether build environment is sane... yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking how to run the C preprocessor... gcc -E
checking for ranlib... ranlib
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether ln -s works... yes
checking for windres... no
checking for gitlog-to-changelog... no
checking if gcc supports -Wno-pointer-sign... yes
checking for ANSI C header files... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking termio.h usability... yes
checking termio.h presence... yes
checking for termio.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking for seteuid... yes
checking for stpcpy... yes
checking for mmap... yes
checking for mlock... yes
checking whether mlock is broken... no
checking for byte typedef... no
checking for ulong typedef... yes
checking for setcap... :
checking for cap_set_proc in -lcap... no
checking for initscr in -lncursesw... yes
checking for ncurses include dir... none
checking for glib-config... no
checking for GLIB - version >= 1.2.0... no
*** The glib-config script installed by GLIB could not be found
*** If GLIB was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the GLIB_CONFIG environment variable to the
*** full path to glib-config.
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking for iconv declaration...
extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
checking for pkg-config... /usr/bin/pkg-config
checking for gtk+-2... no
configure: WARNING: pkg-config could not find the module gtk+-2.0
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking whether g++ supports -fexceptions... yes
checking how to run the C++ preprocessor... g++ -E
checking for X... disabled
configure: error: Can't find X. Please check your installation and add the correct paths!
Não funcionou. Pesquisei a Internet buscando qualquer pista para solucionar esse problema, porém sem sucesso. Então, decidi escrever esta postagem. A propósito, esta mesma postagem já foi publicada no Fórum de Suporte a construtores de Linux From Scratch [http://linuxfromscratch.org/pipermail/blfs-support/2014-July/075296.html].
A solução encontrada também já foi descrita no Fórum acima mencionado [http://linuxfromscratch.org/pipermail/blfs-support/2014-July/075299.html]. Portanto, vou repetir aqui em lingua portuguesa.
Eis o truque que tentei e funcionou: alterar (hack) o arquivo de configuração (configure) do pacote, comentando as três linhas responsáveis por impor o teste de verificação (linhas nº 10.026; 10.027; e 10.028). Eis o texto das linhas mencionadas:
# if test "$no_x" = yes; then
# as_fn_error $? "Can't find X. Please check your installation and add the correct paths!" "$LINENO" 5
# fi
Entretanto, penso que a simples alteração é insuficiente. Então, decidi adicionar a opção de configuração [--with-x=no] (a qual explicitamente desabilita o X) à linha de comando exposta no livro BLFS 7.5:
saída do comando [./configure --prefix=/usr --with-x=no]:
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking whether make sets $(MAKE)... (cached) yes
checking whether build environment is sane... yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking how to run the C preprocessor... gcc -E
checking for ranlib... ranlib
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether ln -s works... yes
checking for windres... no
checking for gitlog-to-changelog... no
checking if gcc supports -Wno-pointer-sign... yes
checking for ANSI C header files... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking termio.h usability... yes
checking termio.h presence... yes
checking for termio.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking for seteuid... yes
checking for stpcpy... yes
checking for mmap... yes
checking for mlock... yes
checking whether mlock is broken... no
checking for byte typedef... no
checking for ulong typedef... yes
checking for setcap... :
checking for cap_set_proc in -lcap... no
checking for initscr in -lncursesw... yes
checking for ncurses include dir... none
checking for glib-config... no
checking for GLIB - version >= 1.2.0... no
*** The glib-config script installed by GLIB could not be found
*** If GLIB was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the GLIB_CONFIG environment variable to the
*** full path to glib-config.
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking for iconv declaration...
extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
checking for pkg-config... /usr/bin/pkg-config
checking for gtk+-2... no
configure: WARNING: pkg-config could not find the module gtk+-2.0
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking whether g++ supports -fexceptions... yes
checking how to run the C++ preprocessor... g++ -E
checking for X... disabled
checking for pthread_create in -lpthread... yes
checking for Qt... no
checking for moc... no
checking for rpath... yes
checking pkg-config is at least version 0.9.0... yes
checking for QT4_CORE... no
configure: creating ./config.status
config.status: creating assuan/Makefile
config.status: creating secmem/Makefile
config.status: creating pinentry/Makefile
config.status: creating curses/Makefile
config.status: creating gtk/Makefile
config.status: creating gtk+-2/Makefile
config.status: creating qt/Makefile
config.status: creating qt4/Makefile
config.status: creating w32/Makefile
config.status: creating doc/Makefile
config.status: creating Makefile
config.status: creating config.h
config.status: executing depfiles commands
configure:
Pinentry v0.8.3 has been configured as follows:
Revision: ce7f2e6 (52863)
Platform: x86_64-unknown-linux-gnu
Curses Pinentry ..: yes
GTK+ Pinentry ....: no
GTK+-2 Pinentry ..: no
Qt Pinentry ......: no
Qt4 Pinentry .....: no
W32 Pinentry .....: no
Fallback to Curses: yes
Default Pinentry .: pinentry-curses
Assim, o pacote PIN-Entry-0.8.3 foi devidamente configurado, compilado e instalado corretamente. Por sua vez, o GnuPG-2.0.22 também foi configurado, compilado e instalado corretamente (já testado!).
É isso.
Jamenson Ferreira Espindula de Almeida Melo
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
iQEcBAEBAgAGBQJTzMniAAoJECrgJcAIqGGAijEH/RRykBewwZrpR+SUfIgBqSon
QCe6Qww/0FFY448AeRIkdevBeF0vZJ+njJDB8XJ4MvHDnlS+IVRO9vwkzwGhvdm4
wCD+F0FKwH03nMOVcIFCzIV/XHABqaB1CSqijwpOcLklv4KcodcGfbwpkj+NRMlu
VpECESYZNcc79Fjq396OJmUcUqtx/mCtLY4dR0qVJO8uML4pwttQWRofcO0zV7Xi
Pxgg9P6HNzul5Ye2QdqLf6BeVEURPHY/SxZl2K1ubfE6G3zreFAAD0g0EkGBR7po
HmaI81+Iy5qqzWVtSKwazsDc/vAl0MmJNz86mE8xMYNYBUSj9oCIn72tXaaGaxw=
=+zGw
-----END PGP SIGNATURE-----
Assinar:
Comentários (Atom)