Hi to all,
I am a new user of GRASS as well as Ubuntu. I faced troubles on understanding the guidelines from GRASS intrusion. Could any one help me? preferly step by step.
Many thanks for your help.
Best regards,
Tri Van
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
sudo apt-get install grass
Mark
On Oct 19, 2008, at 11:28 AM, Van PD Tri <vpdtri@ctu.edu.vn> wrote:
Hi to all,
I am a new user of GRASS as well as Ubuntu. I faced troubles on understanding the guidelines from GRASS intrusion. Could any one help me? preferly step by step.
Many thanks for your help.
Best regards,
Tri Van
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program._______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
sudo apt-get install grass
The offical Ubuntu repositories are a bit outdated. A more updated
repo is the one from Jachym: http://www.les-ejk.cz/ubuntu/
The Gutsy one has Grass 6.3.0, updated to May 2008.
If you want newer versions... you need to compile it. It's not a so
hard task, and we can give advices.
RE: [GRASS-user] How to install Grass into Ubuntu
sudo apt-get install grass
The offical Ubuntu repositories are a bit outdated. A more updated
repo is the one from Jachym: http://www.les-ejk.cz/ubuntu/
The Gutsy one has Grass 6.3.0, updated to May 2008.
Im working with Ubuntu 7.10 Gutsy and in this repositories
not is available the version 6.3.0, the laster version in this
repositories is 6.2.2 (http://www.les-ejk.cz/ubuntu/).
The people who working in Ubuntu and want to work with
other version have to compile it. It’s not a so hard task.
http://grass.osgeo.org/wiki/Compile_and_Install
If you want newer versions… you need to compile it. It’s not a so
hard task, and we can give advices.
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Ahora llévate lo mejor de MSN y Windows Live, en tu móvil
Hello list,
I’m using Grass on ubuntu 8.04. Weird thing is that unless I run it “sudo grass” I get a bunch of errors (and it’s unusable) related to grass not having the correct permissions to write to where I keep the data (ie the users home directory). It’s not a show stoppper at the moment and only slightly annoying. I’m not sure why this is but I have some ideas to hunt down when I get time. I used the standard ubuntu install and assume its something to do with the ubuntu setup script.
Matt
On Mon, Oct 20, 2008 at 7:10 PM, Jhon Ortiz <eljhonjhon@hotmail.com> wrote:
RE: [GRASS-user] How to install Grass into Ubuntu
sudo apt-get install grass
The offical Ubuntu repositories are a bit outdated. A more updated
repo is the one from Jachym: http://www.les-ejk.cz/ubuntu/
The Gutsy one has Grass 6.3.0, updated to May 2008.Im working with Ubuntu 7.10 Gutsy and in this repositories
not is available the version 6.3.0, the laster version in this
repositories is 6.2.2 (http://www.les-ejk.cz/ubuntu/).
The people who working in Ubuntu and want to work with
other version have to compile it. It’s not a so hard task.
http://grass.osgeo.org/wiki/Compile_and_InstallIf you want newer versions… you need to compile it. It’s not a so
hard task, and we can give advices.
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Ahora llévate lo mejor de MSN y Windows Live, en tu móvil
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Hi Matt,
it depeds who are these "users". If you run grass as "you", you can
manage mapsets in your home folders without having to run it with
sudo... If you want to work on others' homes you need the sudo
permissions, as any other operation.
2008/10/20 Matt B <mattslists@gmail.com>:
Hello list,
I'm using Grass on ubuntu 8.04. Weird thing is that unless I run it "sudo
grass" I get a bunch of errors (and it's unusable) related to grass not
having the correct permissions to write to where I keep the data (ie the
users home directory). It's not a show stoppper at the moment and only
slightly annoying. I'm not sure why this is but I have some ideas to hunt
down when I get time. I used the standard ubuntu install and assume its
something to do with the ubuntu setup script.Matt
On Mon, Oct 20, 2008 at 7:10 PM, Jhon Ortiz <eljhonjhon@hotmail.com> wrote:
RE: [GRASS-user] How to install Grass into Ubuntu
> > sudo apt-get install grass
>
> The offical Ubuntu repositories are a bit outdated. A more updated
> repo is the one from Jachym: http://www.les-ejk.cz/ubuntu/
> The Gutsy one has Grass 6.3.0, updated to May 2008.Im working with Ubuntu 7.10 Gutsy and in this repositories
not is available the version 6.3.0, the laster version in this
repositories is 6.2.2 (http://www.les-ejk.cz/ubuntu/).
The people who working in Ubuntu and want to work with
other version have to compile it. It's not a so hard task.
http://grass.osgeo.org/wiki/Compile_and_Install> If you want newer versions... you need to compile it. It's not a so
> hard task, and we can give advices.
> _______________________________________________
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user________________________________
Ahora llévate lo mejor de MSN y Windows Live, en tu móvil
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Matt B wrote:
I'm using Grass on ubuntu 8.04. Weird thing is that unless I run it "sudo
grass" I get a bunch of errors (and it's unusable) related to grass not
having the correct permissions to write to where I keep the data (ie the
users home directory). It's not a show stoppper at the moment and only
slightly annoying. I'm not sure why this is but I have some ideas to hunt
down when I get time. I used the standard ubuntu install and assume its
something to do with the ubuntu setup script.
Note that GRASS won't let you select a mapset as the current mapset
(where new files are stored) unless you own it. Write permission isn't
sufficient.
If you are creating a location which is to be shared by multiple
users, you either need to create a mapset directory for each user,
owned by the user, or grant all such users write permission on the
location directory so that they can create their own mapset directory
(which they will own).
--
Glynn Clements <glynn@gclements.plus.com>
On Mon, Oct 20, 2008 at 9:16 PM, Glynn Clements <glynn@gclements.plus.com> wrote:
Matt B wrote:
I’m using Grass on ubuntu 8.04. Weird thing is that unless I run it “sudo
grass” I get a bunch of errors (and it’s unusable) related to grass not
having the correct permissions to write to where I keep the data (ie the
users home directory). It’s not a show stoppper at the moment and only
slightly annoying. I’m not sure why this is but I have some ideas to hunt
down when I get time. I used the standard ubuntu install and assume its
something to do with the ubuntu setup script.Note that GRASS won’t let you select a mapset as the current mapset
(where new files are stored) unless you own it. Write permission isn’t
sufficient.If you are creating a location which is to be shared by multiple
users, you either need to create a mapset directory for each user,
owned by the user, or grant all such users write permission on the
location directory so that they can create their own mapset directory
(which they will own).–
Glynn Clements <glynn@gclements.plus.com>
Thanks for the heads up on this Glynn, my problem is that I’m on a dual boot system and I’m storing mapsets/data on an NTFS drive. It’s being automatically mounted with the owner set as root and read/write permission for everyone. If I put the data on the ext3 filesystem, it works. I’ll mess around with fstab and mount the data drive as the appropriate user. Having said that… it does seem to me that this sort of check is doubling up. File permissions are usually run by the file system/OS. While having a sanity check for “read/write” access is a good idea, checking for ownership seems a little over the top. .
Thanks
Matt
On 22/10/08 14:53, Matt B wrote:
On Mon, Oct 20, 2008 at 9:16 PM, Glynn Clements <glynn@gclements.plus.com <mailto:glynn@gclements.plus.com>> wrote:
Matt B wrote:
> I'm using Grass on ubuntu 8.04. Weird thing is that unless I run
it "sudo
> grass" I get a bunch of errors (and it's unusable) related to
grass not
> having the correct permissions to write to where I keep the data
(ie the
> users home directory). It's not a show stoppper at the moment and
only
> slightly annoying. I'm not sure why this is but I have some ideas
to hunt
> down when I get time. I used the standard ubuntu install and
assume its
> something to do with the ubuntu setup script.Note that GRASS won't let you select a mapset as the current mapset
(where new files are stored) unless you own it. Write permission isn't
sufficient.If you are creating a location which is to be shared by multiple
users, you either need to create a mapset directory for each user,
owned by the user, or grant all such users write permission on the
location directory so that they can create their own mapset directory
(which they will own).--
Glynn Clements <glynn@gclements.plus.com
<mailto:glynn@gclements.plus.com>>Thanks for the heads up on this Glynn, my problem is that I'm on a dual boot system and I'm storing mapsets/data on an NTFS drive. It's being automatically mounted with the owner set as root and read/write permission for everyone. If I put the data on the ext3 filesystem, it works. I'll mess around with fstab and mount the data drive as the appropriate user.
Also see this thread: http://lists.osgeo.org/pipermail/grass-windows/2008-October/001544.html
Especially:
"I solved the problem with setting uid=my_user_name in the
fstab-file."
Moritz
Matt B wrote:
> Note that GRASS won't let you select a mapset as the current mapset
> (where new files are stored) unless you own it. Write permission isn't
> sufficient.
>
> If you are creating a location which is to be shared by multiple
> users, you either need to create a mapset directory for each user,
> owned by the user, or grant all such users write permission on the
> location directory so that they can create their own mapset directory
> (which they will own).Thanks for the heads up on this Glynn, my problem is that I'm on a dual boot
system and I'm storing mapsets/data on an NTFS drive. It's being
automatically mounted with the owner set as root and read/write permission
for everyone. If I put the data on the ext3 filesystem, it works. I'll mess
around with fstab and mount the data drive as the appropriate user. Having
said that.... it does seem to me that this sort of check is doubling up.
File permissions are usually run by the file system/OS. While having a
sanity check for "read/write" access is a good idea, checking for ownership
seems a little over the top. <insert newby user disclaimer here>.
AFAICT, the check exists because otherwise people grant group-write
permission to mapset directories without fully understanding the
consequences. In particular, you can end up being unable to modify,
rename or remove files because they reside in a directory created by
another user and lacking group-write permission.
The possibility of "free-for-all" filesystems (i.e. where not only are
all files and directories world-writable, but where any new files and
directories will always be world-writable) has only arisen recently.
The native Windows builds skip the ownership check, but Unix builds
will perform it regardless of the filesystem type. Unfortunately, I
don't know of any (robust and portable) way to detect when a Windows
filesystem is being used on Unix.
--
Glynn Clements <glynn@gclements.plus.com>
On Thu, Oct 23, 2008 at 1:14 AM, Glynn Clements <glynn@gclements.plus.com> wrote:
Matt B wrote:
Note that GRASS won’t let you select a mapset as the current mapset
(where new files are stored) unless you own it. Write permission isn’t
sufficient.If you are creating a location which is to be shared by multiple
users, you either need to create a mapset directory for each user,
owned by the user, or grant all such users write permission on the
location directory so that they can create their own mapset directory
(which they will own).Thanks for the heads up on this Glynn, my problem is that I’m on a dual boot
system and I’m storing mapsets/data on an NTFS drive. It’s being
automatically mounted with the owner set as root and read/write permission
for everyone. If I put the data on the ext3 filesystem, it works. I’ll mess
around with fstab and mount the data drive as the appropriate user. Having
said that… it does seem to me that this sort of check is doubling up.
File permissions are usually run by the file system/OS. While having a
sanity check for “read/write” access is a good idea, checking for ownership
seems a little over the top. .AFAICT, the check exists because otherwise people grant group-write
permission to mapset directories without fully understanding the
consequences. In particular, you can end up being unable to modify,
rename or remove files because they reside in a directory created by
another user and lacking group-write permission.The possibility of “free-for-all” filesystems (i.e. where not only are
all files and directories world-writable, but where any new files and
directories will always be world-writable) has only arisen recently.The native Windows builds skip the ownership check, but Unix builds
will perform it regardless of the filesystem type. Unfortunately, I
don’t know of any (robust and portable) way to detect when a Windows
filesystem is being used on Unix.–
Glynn Clements <glynn@gclements.plus.com>
After banging my head against the ntfs wall for a little while here (for some reason the guys who write the ntfs stuff also have some ideas on who should be allowed to mount / own filesystems and block devices).
While writing software for the lowest common denominator isn’t necessarily a bad thing, including this sort of thing in the software to stop people overwriting others files does seem a little redundant and in my case annoying. I’ll add another disclaimer in case someone points out that theres an easy fix for this as I’m the guy who can’t get an ntfs partition mounted without it being owned by root (without recompiling stuff that would probably break on the next apt-get update).
I’ll be running this from my somewhat smaller ext3 partition for the time being unless someone can point me at a “don’t do this check” button (please, someone point me at that button).
Matt
Hi Matt,
I'm using Grass on a dual-boot Vista/Xubuntu 7.10 machine. It's mine, so my data live on the NTFS partition and I can mount it with me as the owner (and group). It took me a while to figure it out, and now I can't remember how I did it, but my fstab entry looks like this:
/dev/sda3 /media/OS ntfs-3g umask=0002,uid=mbessjs3,gid=mbessjs3,allow_other 0 0
Hopefully that works for you, too.
John
Matt B wrote:
On Thu, Oct 23, 2008 at 1:14 AM, Glynn Clements <glynn@gclements.plus.com <mailto:glynn@gclements.plus.com>> wrote:
Matt B wrote:
> > Note that GRASS won't let you select a mapset as the current
mapset
> > (where new files are stored) unless you own it. Write
permission isn't
> > sufficient.
> >
> > If you are creating a location which is to be shared by multiple
> > users, you either need to create a mapset directory for each user,
> > owned by the user, or grant all such users write permission on the
> > location directory so that they can create their own mapset
directory
> > (which they will own).
>
> Thanks for the heads up on this Glynn, my problem is that I'm on
a dual boot
> system and I'm storing mapsets/data on an NTFS drive. It's being
> automatically mounted with the owner set as root and read/write
permission
> for everyone. If I put the data on the ext3 filesystem, it
works. I'll mess
> around with fstab and mount the data drive as the appropriate
user. Having
> said that.... it does seem to me that this sort of check is
doubling up.
> File permissions are usually run by the file system/OS. While
having a
> sanity check for "read/write" access is a good idea, checking
for ownership
> seems a little over the top. <insert newby user disclaimer here>.AFAICT, the check exists because otherwise people grant group-write
permission to mapset directories without fully understanding the
consequences. In particular, you can end up being unable to modify,
rename or remove files because they reside in a directory created by
another user and lacking group-write permission.The possibility of "free-for-all" filesystems (i.e. where not only are
all files and directories world-writable, but where any new files and
directories will always be world-writable) has only arisen recently.The native Windows builds skip the ownership check, but Unix builds
will perform it regardless of the filesystem type. Unfortunately, I
don't know of any (robust and portable) way to detect when a Windows
filesystem is being used on Unix.--
Glynn Clements <glynn@gclements.plus.com
<mailto:glynn@gclements.plus.com>>After banging my head against the ntfs wall for a little while here (for some reason the guys who write the ntfs stuff also have some ideas on who should be allowed to mount / own filesystems and block devices).
While writing software for the lowest common denominator isn't necessarily a bad thing, including this sort of thing in the software to stop people overwriting others files does seem a little redundant and in my case annoying. I'll add another disclaimer in case someone points out that theres an easy fix for this as I'm the guy who can't get an ntfs partition mounted without it being owned by root (without recompiling stuff that would probably break on the next apt-get update).I'll be running this from my somewhat smaller ext3 partition for the time being unless someone can point me at a "don't do this check" button (please, someone point me at that button).
Matt
------------------------------------------------------------------------
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr John Stevenson
Postdoctoral Research Associate
School of Earth, Atmospheric and Environmental Sciences
Williamson Building (Room 2.42)
University of Manchester
Manchester M13 9PL, UK
tel. +44(0)161 306 6585; fax. +44(0)161 306 9361;
john.stevenson@manchester.ac.uk
Hi John,
a very big THANKS. First impressions is that it’s done the trick.
Matt
On Thu, Oct 23, 2008 at 10:56 PM, John Stevenson <john.stevenson@manchester.ac.uk> wrote:
Hi Matt,
I’m using Grass on a dual-boot Vista/Xubuntu 7.10 machine. It’s mine, so my data live on the NTFS partition and I can mount it with me as the owner (and group). It took me a while to figure it out, and now I can’t remember how I did it, but my fstab entry looks like this:
/dev/sda3 /media/OS ntfs-3g umask=0002,uid=mbessjs3,gid=mbessjs3,allow_other 0 0
Hopefully that works for you, too.
John
Matt B wrote:
On Thu, Oct 23, 2008 at 1:14 AM, Glynn Clements <glynn@gclements.plus.com mailto:[glynn@gclements.plus.com](mailto:glynn@gclements.plus.com)> wrote:
Matt B wrote:
Note that GRASS won’t let you select a mapset as the current
mapset
(where new files are stored) unless you own it. Write
permission isn’t
sufficient.If you are creating a location which is to be shared by multiple
users, you either need to create a mapset directory for each user,
owned by the user, or grant all such users write permission on the
location directory so that they can create their own mapset
directory
(which they will own).Thanks for the heads up on this Glynn, my problem is that I’m on
a dual boot
system and I’m storing mapsets/data on an NTFS drive. It’s being
automatically mounted with the owner set as root and read/write
permission
for everyone. If I put the data on the ext3 filesystem, it
works. I’ll mess
around with fstab and mount the data drive as the appropriate
user. Having
said that… it does seem to me that this sort of check is
doubling up.
File permissions are usually run by the file system/OS. While
having a
sanity check for “read/write” access is a good idea, checking
for ownership
seems a little over the top. .AFAICT, the check exists because otherwise people grant group-write
permission to mapset directories without fully understanding the
consequences. In particular, you can end up being unable to modify,
rename or remove files because they reside in a directory created by
another user and lacking group-write permission.The possibility of “free-for-all” filesystems (i.e. where not only are
all files and directories world-writable, but where any new files and
directories will always be world-writable) has only arisen recently.The native Windows builds skip the ownership check, but Unix builds
will perform it regardless of the filesystem type. Unfortunately, I
don’t know of any (robust and portable) way to detect when a Windows
filesystem is being used on Unix.–
Glynn Clements <glynn@gclements.plus.commailto:[glynn@gclements.plus.com](mailto:glynn@gclements.plus.com)>
After banging my head against the ntfs wall for a little while here (for some reason the guys who write the ntfs stuff also have some ideas on who should be allowed to mount / own filesystems and block devices).
While writing software for the lowest common denominator isn’t necessarily a bad thing, including this sort of thing in the software to stop people overwriting others files does seem a little redundant and in my case annoying. I’ll add another disclaimer in case someone points out that theres an easy fix for this as I’m the guy who can’t get an ntfs partition mounted without it being owned by root (without recompiling stuff that would probably break on the next apt-get update).I’ll be running this from my somewhat smaller ext3 partition for the time being unless someone can point me at a “don’t do this check” button (please, someone point me at that button).
Matt
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user–
Dr John Stevenson
Postdoctoral Research Associate
School of Earth, Atmospheric and Environmental Sciences
Williamson Building (Room 2.42)
University of Manchester
Manchester M13 9PL, UK
tel. +44(0)161 306 6585; fax. +44(0)161 306 9361;
john.stevenson@manchester.ac.uk