- This topic has 35 replies, 9 voices, and was last updated Jul 18-4:19 am by Robin.
May 8, 2021 at 9:26 am #58909MemberPPC
Robin – just my own personal opinion- regular users won’t like having to enter their password in order to eject a usb drive… I can already see the complaints if antiX implements that…
So, if I were you I would have 2 separate versions that the user can choose from- this new 0.82b that fixes that bug BUT requires users to enter the password and the older version, with that bug (I’ve been using antiX for years on several computers successively, with several pendrives and was luck enough to never notice that bug).
Very nice work, you are the kind of people that helped antiX grow up to be a light OS but extremely feature rich!
P.May 8, 2021 at 9:35 am #58910MemberXecure
Should we create a separate .deb project for unplugdrive, in a mount-contribs (or some other better name) with a small collection fo scripts and move unplugdrive away from antix-goodies?
We could include the cloud-mounting script that PPC created, even if not related to real device mounting.
I am thinking we could also add a fstab manager script, to add/remove/edit fstab entries in a more intuitive manner (with GUI), so that we can circumvent exfat and ntfs problems when mounting devices (to make it easy for read/write permissions for user account, manage automounting for these specific drives, etc.)
antiX Live system enthusiast.
General Live Boot Parameters for antiX.May 8, 2021 at 9:55 am #58913MemberRobin
regular users won’t like having to enter their password in order to eject a usb drive
I’m aware of this, and I see it exactly the same way. But simply I can’t take care of two seperate version trees of unplugdrive.
When dealing with spinning down of rotational devices sudo will get involved anyway. And we can’t leave the default in antiX to endanger people to mess up their rotationals by telling them it was safe to unplug, knowing this was not true.
So we’ll have to find another way to overcome the need of entering sudo password when using unplugdrive, for the use of mount command as well as for hdparm from within this script. By now I have no Idea which approach to achieve this would work best. Any suggestions — also from antiX developers — appreciated.
Edit: Probably most easy way would be if antiX developers could add the line
%users ALL=(root) NOPASSWD: /usr/local/bin/unplugdrive.sh
to /etc/sudoers.d/antixers file and prepend “sudo” to all occurences in antiX system files where it is called.
So users will not get asked for passwords when using the bugfixed 0.82b version.
Please let me know whether this solution would have to be considered an incalculable risk, and whether I should take precautions to run all other commands within this script which don’t need root privileges in context of normal user then, such as prepending each other command in script by “sudo -u <current user > <command>”, to make it safe. (See appended version 0.82c)
was luck enough to never notice that bug
Congratulations! You are one of the (perhaps many) lucky ones… But I feel we can’t leave it that bugged per default.
- This reply was modified 5 months, 1 week ago by Robin. Reason: added possible solution
Attachments:May 16, 2021 at 12:15 am #59484MemberRobin
OK, since nobody objected to my questions posed in last posting, version 0.82c is now on gitlab.
There are some minor adaptions to be applied to some antiX system files allowing user to run this version as well as all successional versions without any noticeable difference in handling compared to earlier versions:
1.) unplugdrive needs to be added to /etc/sudoers.d e.g. as an additional entry in antixers file with the “NOPASSWORD” option set.
A readymade replacement file for antiX 19.3 containing this line can be found on gitlab. Replace this file in /etc/sudoers.d system folder.
2.) System settings referring to unplugdrive need to get supplemented by “sudo” preceding “unplugdrive”. If etc/sudoers.d/antixers is modified at the same time, user won’t notice any difference of operation compared to previous versions. The template files in english language can be found on gitlab also, for icewm toolbar and jwm tray . You will find the system files in the language subfolders of
and also in
but be aware these files are language spcific always and you may want rather to keep your translated files probably, simply adding the missing sudo in front of each occurance of unplugdrive found in them.
3.) You may want to add a permanent alias like “alias unplugdrive=’sudo unplugdrive.sh'” and/or “alias unplugdrive.sh=’sudo unplugdrive.sh'” to your system, so you will be able to start the process of securely unmounting a pluggable USB storage device by entering simply “unplugdrive” in commandline, without the need of entering the preceding sudo, just as in all versions before.
Please consider, there is no way to overcome the bugs found in earlier versions of unplugdrive without introducing the need of sudo. This is not only true for the recent bugfix of 0.82b/c versions, but also for the following fixes intended for 0.83 and successional versions. This is simply caused by the shortcommings of some linux tools employed for the tasks to be done in original unplugdrive and cant’t get fixed when sticking to these. All proven functional replacements do ask for sudo.
The recent ver. 0.82c of unplugdrive script is internally hardened that way, it will execute each external command in normal user context only even if the script is called by sudo. Therefore it won’t would you allow to run it from a true root account. Also it will refuse to work without being sudoed. Given you apply the three proposed minor modifications from above to your system, you will not notice any difference to what we’ve had before, but now unplugdrive will work much more reliable already.
compiled .mo translation files are ready for this version featuring the languages
Belgian French (fr_BE)
Brasilian Portuguese (pt_BR)
these files go to /usr/share/locale/<ll[_CC]>/LC_MESSAGES/unplugdrive.sh.mo
@antiX developers: please let me know if you’d prefer another solution dealing with this sudo problem. I’m carefully listening when you explain this is to be done in another way. Right now I’m working on the following bugfix version, dealing with the problem of not spinning down rotational USB storage devices and need to know whether 0.82c is accepted for further proceeding, since as I described above, some changes to basic antiX settings files are required.
@all: it would be great if you could apply hard testing on the recent unplugdrive version on any kind of equipment you can lay hands on. I’ve done this with any equipment in my reach already. Please keep in mind, the blank-character-in-mountpoint-path bug and the true-rotationals-dont-spin-down bug are not fixed by now and so there is no need of reports referring to these two. Marcelo has recently seen the former in the wild, and was able to confirm this bug actually prevents some types of USB sticks from getting safely unplugged, so I’m not the only one person concerned.
RobinMay 16, 2021 at 1:13 am #59488Memberskidoo
May 16, 2021 at 12:05 pm #59514MemberRobin
- This reply was modified 5 months ago by skidoo. Reason: removing my controversial, strongly opinionated, post
This reply was modified 8 hours, 19 minutes ago by skidoo. Reason: removing my controversial, strongly opinionated, post
Hmm. Obviously I came to late to read. Well, I believe we all meet in this place to learn about what are others peoples opinions, and, not at least, to learn what controversial aspects should be taken into account.
In case this was about the basic policy of allowing people to plug their USB sticks getting mounted automatically without need of a system administrators root permission: Yes, this is to be considered a security risk always. But as long system allows people to plug their devices and mount them without any circumstances, we need to give them a way to unplug them as easily and what is more important: unplug them in a safe way, without facing danger of data loss.
The single point I can see we have to decide is: Would we rather want to allow them to do it without entering their sudo password, as most people would probably expect, or should we rather stick to administrative policies and ask user for password each time he wants to remove some of his pluggable storage devices. In the latter case user should be asked for password when plugging them in also, I believe.
So I would be glad to read more about what your concerns are after all, skidoo.May 23, 2021 at 6:34 am #59896MemberWallon
With Antix 19.3 64bits FULL, this does not work for me. I don’t have the French translations.
1) I downloaded the file unplugdrive.sh.mo on https://gitlab.com/Robin-antiX/antix-goodies/-/raw/master/locale/fr_BE/LC_MESSAGES/unplugdrive.sh.mo.
I have copied this file into the directory; /usr/share/locale/fr_BE/LC_MESSAGES
2) With nano, I have opened the file /etc/sudoers.d/antixers and added your sentence with NOPASSWORD.
# sudoers file. %users ALL=(root) NOPASSWD: /sbin/halt %users ALL=(root) NOPASSWD: /sbin/poweroff %users ALL=(root) NOPASSWD: /sbin/reboot %users ALL=(root) NOPASSWD: /sbin/blkid %users ALL=(root) NOPASSWD: /sbin/fdisk.distrib %users ALL=(root) NOPASSWD: /usr/bin/ceni %users ALL=(root) NOPASSWD: /usr/local/bin/persist-config %users ALL=(root) NOPASSWD: /usr/local/bin/persist-save %users ALL=(root) NOPASSWD: /usr/sbin/minstall %users ALL=(root) NOPASSWD: /usr/local/bin/connectshares.sh %users ALL=(root) NOPASSWD: /usr/local/bin/disconnectshares.sh %users ALL=(root) NOPASSWD: /bin/chvt %users ALL=(root) NOPASSWD: /usr/local/bin/menu_manager.sh %users ALL=(root) NOPASSWD: /usr/sbin/pm-hibernate %users ALL=(root) NOPASSWD: /usr/sbin/pm-suspend %users ALL=(root) NOPASSWD: /usr/local/bin/unplugdrive.sh Defaults!/usr/local/bin/menu_manager.sh env_keep += "HOME" Defaults !requiretty Defaults !tty_tickets
3) In LXTerminal, I use this command; sudo unplugdrive.sh
All is in English.
I have noticed that all my *.mo files are in the folder /usr/share/locale/fr/LC_MESSAGES.
There is only 1 *.mo file in the folder /usr/share/locale/fr_FR/LC_MESSAGES.
I will do the same test with your fr_BE *.mo file in the folder /usr/share/locale/fr/LC_MESSAGES.
- This reply was modified 4 months, 3 weeks ago by Brian Masinick. Reason: Replace blob with raw
Attachments:May 23, 2021 at 6:47 am #59898MemberWallon
My second test with the directory /usr/share/locale/fr/LC_MESSAGES does not work.
WallonMay 23, 2021 at 5:39 pm #59951MemberRobin
I have just checked this. The files itself on gitlab are fine. This is obviously a kind of bug on gitlab site: Browsers claim to store the file unplugdrive.sh.mo on your PC when right clicking on the files from within directories, but gitlab does actually deliver a html file instead equally named. To verify, please open your downloaded .mo files you’ve got from gitlab using a text editor like geany or leafpad, and check their first lines. If it runs
this is an html file they have sent you without notice instead of real unplugdrive.sh.mo
Please confirm, whether your findings are the same as mine. No idea why they are doing this. I’ll check.
With Antix 19.3 64bits FULL, this does not work for me.
— Does only the localisation fail, or does the script itself fail to work?
EDIT: The same download problem of silently delivering a html file instead of the true file content happens when downloading the script unplugdrive.sh itself from gitlab. So this will not run also, when downloading from gitlab. I’ll check how this can be helped.
In LXTerminal, I use this command; sudo unplugdrive.sh
All is in English.
— The debug output in terminal (when using -g option) will always be in English language on purpose, otherwise I couldn’t make anything of its output, when it comes to translations to languages other than the few existing ones, while people asking here in forum for advice.
So only all the messages in GUI (and the terminal help display) get translated, regardless of the way the script is called.
— after editing your IceWM toolbar file you will need to restart icewm by pressing ctrl-alt-del and chose from menu “restart IceWM” for the change of settings to take effect. (Don’t mix up with other “restart” entries also present there). After this the toolbar icon will also work again. It simply needs to know of the additional “sudo”.
May 23, 2021 at 6:16 pm #59958MemberRobin
- This reply was modified 4 months, 3 weeks ago by Robin.
Found a workaround (probably).
@moderators: Please, could you replace the string blob by the string raw in all incidences of gitlab links within the above posting? For some reason gitlab will deliver files with correct filename but wrong content when blob is found within the URL. What the heck…
Could you please check whether these links save files now as expected or do you get html still when downloading?May 24, 2021 at 4:28 am #59986MemberWallon
@Wallon: try this meanwhile: unplugdrive 0.82c fr locale (.mo) fr_BE locale (.mo) IceWM toolbar file template (en) Could you please check whether these links save files now as expected or do you get html still when downloading?
You are right.
I can’t open *.mo files from Gitlab with Geany or Leafpad.
I also can’t open *.mo files downloaded from your new links with Geany or Leafpad.
Geany says they are not “text” files and the page is blank.
WallonMay 24, 2021 at 1:08 pm #60013MemberRobin
This is what I once have meant by saying: „Gitlab is a nightmare.” You simply seem never to get from that page what you’d expect, and never find something (e.g. a button or a link) in a place somebody not very well trained in working on it would ever expect it.
But I have just checked again. The links I gave you work fine (at least for me, who knows what that site does behind my back when you try to download 😉 ) The downloaded files work fine here and are byte identical to the uploaded ones.
I also can’t open *.mo files downloaded from your new links with Geany or Leafpad.
Geany says they are not “text” files and the page is blank.
This sounds good, since .mo files are binary file type. These files have been compiled directly from the .po files downloadable from transifex. If you would have been able to open them with a texteditor (or poedit) something would have gone wrong. This is not true for the script file itself, this should open with a text editor, but NOT read
in the first line, but
For me the download with the new links works fine.
So simply try to use the files.
You might want to compare the sha-256 checksums beforehand:
7be189b84634f282550f2688dc9b65c5638a0772e9fe8aee5a32867d8a56c22b unplugdrive.sh dedd5bc07590dd9d77cb9498d0ebbacf4fe3cee063ed2d19222d3936c4132e85 fr/unplugdrive.sh.mo d87e9d4331f6df359a71d98eed0bacb3f30feabd9bdc6c1a8bd160d6f76bd139 fr_BE/unplugdrive.sh.mo da5401b149a4fe5fb277635c80821b04906cb794eb774129772d7fa31ca711f8 de/unplugdrive.sh.mo a79d9aa4619a7599e651f5818f2c28b41dd159211a55b45ad6deee67e522ebab pt_BR/unplugdrive.sh.mo e6f5eaf79b2efbe854807cb0f8f221598be9fc43ecda51e081709395f679ea2f pt/unplugdrive.sh.mo 6412d938c9b5cbae7ee442a1ce843e5c2fdfcb27a8db3beda58cebd0e5bf3a3a ru/unplugdrive.sh.mo 1db31dd9df54b9f85e32c56dccce729715b08acb4e2ece0dc271589e58b076ef en/jwm/tray 395deb55a70e341bb2b78cf4725925258bd99dcdd5c9be98350a4c66a5e3e3c8 en/jwm/tray-numix-bevel 462ef08c002ba4888170a11de4f150f83cbe77415509e191995ffc47ae4304c8 en/jwm/tray-numix-square a1349dd45ce25af5460a58b5d224122d0f4f578408972bc1b2af4e77d4dd61e4 en/jwm/tray-papirus 8e052321bb8bdb5fe53bead1c370df7790c61fc16e60da6cb3d6d46b7db8132e en/icewm/toolbar 888d8f9ae2f74e299983f1e3e9344659d72dda6d982af25cdab05cc169ccefad en/icewm/toolbar-numix-bevel 853fc0502af97171da1966fc1d7cc682add656a82b0798b5594931e9c50fa8f6 en/icewm/toolbar-numix-square 8e052321bb8bdb5fe53bead1c370df7790c61fc16e60da6cb3d6d46b7db8132e en/icewm/toolbar-papirus 555b0d24c5fef361657e9b9e6ff93a9d9b0cc1f1d075af72e2827432bb48d8a0 etc/sudoers.d/antixers
You may simply compare the above letter and number shambles (how to translate „Buchstaben- und Zahlensalat“?) by typing e.g.
shasum -a 256 unplugdrive.sh shasum -a 256 unplugdrive.sh.mo
in a terminal window for any file you want to be sure to be byte identical.
Please let me know, whether gitlab still fools about with us, and still sends wrong content under correct filenames to you when downloading.
@mods: Please, update the before mentioned posting by replacing blob by raw in the gitlab-links! I can’t do this myself, since the posting in question doesn’t have an edit button anymore for me. This is important since users will get html files instead without notice under the true filename(!) when expecting the true content from gitlab.June 3, 2021 at 7:49 pm #60896MemberWallon
I have done some big translation corrections to fr_FR and fr_BE at Transifex for Antix and MX Linux.
I had not understood that expressions like “\topen” could be translated into French as “\touvrir”.
I understood this by reading the German translations. The German translator is more intelligent than I am.
June 3, 2021 at 10:20 pm #60903MemberRobin
- This reply was modified 4 months, 2 weeks ago by Wallon.
this is not about being more or less intelligent, but this is simply about having come across the code in use once before. Firstly I have fixed the code of this very script myself, thus I did know already what these strange looking expressions actually mean. Their precise explanation can be found (along with some more of them) by typing „man echo“ in a terminal window in antiX. These are so called „backslash escapes” used by bash „echo” command (and others). Secondly: I admit, we should write even some more so called “developer instructions” and “string instructions” on transifex. This is to come soon, we are working on it and just learning how to do this correctly. First of these can be found in some resources of antix-contribs already. And thirdly, I’m peeking into other languages myself (even in those I don’t speak or understand) quite frequently to get an idea of what a string to be translated could mean that leaves me at a loss. You yourself helped me out of a jam with some of your French translations you had written before, while I was struggling with getting the precise meaning of the source strings still. Only reading your French version rendered things clear to me.
It’s me who has to apologise having missed to give more detailed hints in the comments of this resource.
So I’ll write a small text next days, covering some basic findings of pitfalls in string translation on transifex I stumbled upon in the past myself. It’ll be meant to be complemented by everybody who feels something is missing in it.
RobinJune 3, 2021 at 11:42 pm #60913Membermarcelocripe
Hello dear Wallon and Robin,
The “\topen” is an excellent example of the pitfalls that translators run into on the transifex site. It took me a while to understand that the word after the “\t” could be translated this is something that causes confusion with internet translators who try to translate “topen” instead of “open”.
What Robin said he did, reading the French texts to be able to reuse and adapt them to German, is perfectly healthy, I always try to do the same in European Portuguese (pt-PT) and I believe that mine can help PPC and Zeh, eventually, even if it’s just a line or word (laughs).
Translating Robin’s programs, always with the help of internet translators, I compared the results of translations of texts in German with the results in English and the final verification was of the results in French. In other words, even though Robin himself wrote the texts in the three languages (German, English and French) I had three different results with different intentions for the same explanation. When none of the results of the three versions were sufficiently understandable in Brazilian Portuguese (pt-BR), then the challenge begins, trying to understand each sentence of each of the results and building a “Frankenstein” version from the three texts. Sometimes, the translation from Robin’s native language was much more understandable, other sentences were from English and several times they were the result of French, which gave me greater security when building and adapting the text to pt-BR .
The changes made this week at https://www.transifex.com/antix-linux-community-contributions/antix-contribs/ will be an important step in making it easier for programmers to be able to write code and text in their own language and if concentrate on the code in the program, instead of trying to guess how the texts should be constructed for a language that is not their native language, in this case, the English language. I really liked this idea, because I’ll be able to insert the programmer’s native language text in the internet translators and have results much closer to the original intention, if I need it, I’ll still have the option of “Pirate English” results, en@pirate.
And that communication between people and peoples occurs in the best possible way for the good of antiX (GNU/Linux).
(Original text in Brazilian Portuguese)
Olá caros Wallon e Robin,
O “\topen” é um excelente exemplo das armadilhas que os tradutores acabam se deparando no sítio transifex. Levou um tempo para eu entender que poderia ser traduzido a palavra que vem depois do “\t” isso é algo que causa confusão com os tradutores da internet que tentam traduzir “topen” ao invés de “open”.
O que o Robin disse que fez de ler os textos franceses para poder reaproveitar e adaptar para o alemão, é perfeitamente saudável, eu procuro sempre que possível fazer o mesmo em português Europeu (pt-PT) e acredito que os meus possam ajudar o PPC e o Zeh, eventualmente, mesmo que seja apenas uma linha ou palavra (risos).
Traduzindo os programas do Robin, sempre com o auxílio dos tradutores da internet, eu comparava os resultados das traduções dos textos em idioma alemão, com os resultados em inglês e a verificação final eram dos resultados em francês. Ou seja, mesmo sendo o próprio Robin que escreveu os textos nos três idiomas (alemão, inglês e francês) eu tinha três resultados diferentes com intenções diferentes de uma mesma explicação. Quando nenhum dos resultados das três versões eram suficientemente compreensíveis em português do Brasil (pt-BR), aí é que começa o desafio, tentar entender cada frase de cada um dos resultados e construir um versão “Frankenstein” a partir dos três textos. Por vezes, a tradução a partir o idioma nativo do Robin era muito mais compreensível, outras frases eram a partir do inglês e em várias vezes eram o resultado do francês que me dava maior segurança na hora de construir e adaptar o texto para pt-BR.
As alterações feitas esta semana no https://www.transifex.com/antix-linux-community-contributions/antix-contribs/ serão um passo importante para facilitar para os programadores poderem escrever o código e os textos em seu próprio idioma e se concentrarem no código no programa, ao invés de ficar tentando adivinhar como deveria ser construído os textos para um idioma que não é o seu nativo, no caso, o idioma inglês. Eu gostei muito desta ideia, porque eu vou poder inserir nos tradutores da internet o texto do idioma nativo do programador e ter resultados muito mais próximos da intenção original, caso eu precise, ainda terei a opção dos resultados do “Pirate English”, en@pirate.
E que a comunicação entre as pessoas e os povos ocorram da melhor forma possível para o bem do antiX (GNU/Linux).
(Texto original em Português do Brasil)
- You must be logged in to reply to this topic.