Installing Synce On 10.2 And 10.3

just a lil something i did over the last few days. i have written some bash scripts for it to automate the isntall process a lil becuase the only rpms i can find aren't official and i don't trust them (anything that isn't official arouses my suspicions)

anyway here's the link: http://en.opensuse.org/synce

have fun. Any comments please post here or you can find my e-mail address in the synce_dlbs.sh script

Thanks for that, I have tried many hours to get synce working with my t-mobile dash but without success. Soon as I have time, I will try it again using your scripts and post results...

ty. it will be nice to see if they work. i didn't get time to test them today

i got board so i did some more work on the wiki page. The 3 scripts have now become 2 - one for 10.2 and one for 10.3 - The script now downloads all the synce sources needed, usb-rndis-lite and the default kernel sources for your version of suse.

i have also added a lil something on starting up the connection to the device from the pc.

one last thing (that i need a lil help with) is i want the scripts to reduce down to one. for that i will have to write an If, Then, Else statement into the script and i don't know how. i! also want to greatly reduce the amount of time you get asked to give you root password by making the script ask you to input it at the start and then have it stored in a variable. That way i could have the password fed to su when it needs it.

lil update. i got time to debug the script for the how to so now it actually works!!!!.

Jop added a version checking if construct and some typo's in the echo commands was cleaned up.

still need to figure out how to get it to "remember" the root password tho. you have to enter it almost 15 times iirc. lil too much i think

Why don't you replace them and just in using instructions tell them to run as root.

I'd be dubious about adding it as a variable, I had a brief look but I got a feeling any variable you run via a bash script may be catchable. I'm not 100% sure just had feeling I read something along those lines.

Ok it's not a majorly exploitable but if(Big IF) its catchable from a local exploit, and it's possible to peek on the variable via a user exploit, they now have the password.

Edit
One other thing wouldn't you be better using a zypper command in case they aren't UK based for kernel source?

Why don't you replace them and just in using instructions tell them to run as root.

I'd be dubious about adding it as a variable, I had a brief look but I got a feeling any variable you run via a bash script may be catchable. I'm not 100% sure just had feeling I read something along those lines.

Ok it's not a majorly exploitable but if(Big IF) its catchable from a local exploit, and it's possible to peek on the variable via a user exploit, they now have the password.

Edit
One other thing wouldn't you be better using a zypper command in case they aren't UK based for kernel source? [/b]

ok firstly, i want the root password as a variable simply becuase running the script as root could cause problems later on when trying to remove the dowloaded files. A normal user that has used this script probably wouldn't understand that the files are locked becuase they are owned by root and i would get the blame.

with regard the kernel source package, myself and jop decided that using rpm was better for speed and simplicity. Reason being the kernel source rpm has one dependancy. The kernel default rpm. and that's installed so zypper is surplus to requirements becuase we don;t need the dependacny checking and if there download location is not a good one for a specific user it can be changed as the script is provided in compliance with the GPLv2

I really would look at catching a bash variable I'm sure its world seeable.

If I said running your script had made my root password accessible to another local user would you be concerned? I think it's either seeable in proc tmp or maybe even ps. But the point is the variable will be owned by the user.

In regards to rpm I accept you're point but if I'm in Australia using a UK mirror will kill it, where as if you use zypper then at least you will use there mirror/repo.

As for removing not sure too many would expect to remove a package as user, of course they'll be a few but I doubt many.

Edit:
I am unsure about catching a variable but I'm sure I've read something along those lines and do accept it is only a small window of opportunity.

I also completely disagree with even being able to echo the password into su, to which there is a bug report open so this may not even work in the future.

Ok I come bearing an example

Now this takes some catching its not easy but its possible which is my point.

In one
konsole tab
sleep 10 && mysql -uroot -pblabla

In another ps ax | grep mysql(Be easier with a loop and a script to dump file) lots of times if and when you catch you'll notice, this
mysql -uroot -px xxxx

So in this instance its fine, I was just making you aware of it.

I personally think hardcoding the password is opening more opportunities not to mention echoing a password is wrong. Plus I suspect at the moment you echo it in it maybe viewable in plaintext

cheers for pointing out that artefact in the code. It was something i tried but as you correct pointed out doesn't work. i thought i had removed them all (you will notice if you look at the code that "&& print $pass" was invalid coz the variable "pass" was never specified).

your reasons for running the script as root do not justify running it as root. it doesn't matter if the user knows how to remove it. What matters is they can, and easily.

With regards your point on repository choice. If you live in Australia you can change it to an Australian one. if you think it's that much of an issue you are welcome to make a fork of the script that use's zypper (hell i'll link it up and host it on the wiki). You could compile a list of mirrors for the oss repo. Either way your gonna have to do something about it yourself instead of trying tos tart an argument about it with me. not my style and all i care about is how simple and fast the script is