VectorLinux 7.0 CORE ALPHA 2

[GrannyGeek]

I haven't had problems with End or the arrow keys. I didn't go with the "no xorg.conf" option. I would not want to be without an xorg.conf file.
--GrannyGeek

[GrannyGeek]

Gslapt from the menu does not seem to work. I have to su to root in a terminal and type gslapt and then Gslapt loads. I can't get the VL7 testing repo added to the Gslapt sources. It says there is no such place. Also, in order to set up CUPS I had to start from a browser (http://localhost:631/printers); it didn't work from VASM.
--GrannyGeek

[Pita]

Why is the kernel of VL7.0-CORE-ALPHA-2.1 so much bigger than the one of
VL7.0-CORE-ALPHA-2 ? More than twice the size.

[M0E-lnx]

well, I still had the problem here... but then again, i'm in a VM... and my GUI is over VNC, so there is a possibility that the problem exists on another layer.

[toothandnail]

Gslapt from the menu does not seem to work. I have to su to root in a terminal and type gslapt and then Gslapt loads. I can't get the VL7 testing repo added to the Gslapt sources. It says there is no such place. Also, in order to set up CUPS I had to start from a browser (http://localhost:631/printers); it didn't work from VASM.
--GrannyGeek

Sorry, but there is no VL7.0 testing repo - it is simply a collection of files in roughly the same places as they would be under VL6.0. Trouble is, with the switch to .txz packages (which follows current Slackware practice), the repo tools are no longer functional. The original versions needed a specific version of tar to work with lzma compression, the new ones will need not only that, but also a copy of the xz package. Not sure what is needed to get that done.

As to Gslapt, there are two packages up there. If you download this one:

http://vectorlinux.osuosl.org/veclinux-7.0/testing/x-apps/gslapt-0.5.3c-i586-1vl70.txz

it has a corrected /usr/share/applications/gslapt.desktop. The original had the same problem that the original VL6.0 release of Gslapt had - the .desktop calls gslapt directly, which will not work, since it requires root access. My build simply fixes the .desktop file.

Also, the other build of slapt-get (http://vectorlinux.osuosl.org/veclinux-7.0/testing/base/slapt-get-0.10.2f-i586-1vl70.txz) has a hacked /etc/slatpt-get/slapt-getrc, which includes the VL6.0 repostitories.

Paul.

[Masta]

Thanks Paul.
 Would you please contact the packager of the gslapt with that information so that we don't have this show again in the future?

[stretchedthin]

@toothandnail.  I've uploaded a few packages into my vectorcontrib folder if you can find time to move them over to the vl70 area. 
Thanks, Ken

[toothandnail]

@toothandnail.  I've uploaded a few packages into my vectorcontrib folder if you can find time to move them over to the vl70 area. 
Thanks, Ken

No problem. Can you PM me a list with some brief descriptions? Otherwise I'm going to be spending a lot of time working out what area they need to go to....

Paul.

[toothandnail]

I'm having some strange permission problems in VL7.0. Maybe someone can tell me what is going on....

I have an Amahi server. It has been offline since my move, but I've finally got it back up and running. It provides a number of different services - DHCP, DNS and file/print sharing.

I'm having problems mounting shares from the Amahi box so that they can be written to by normal users. I use the following command to mount a share:

Code:

mount -t cifs //hda/music /mnt/amahi -o user=notme2%xxxxx

That mounts the share without problems, and entering 'mount' without arguments gives me the following:

Code:

//hda/music on /mnt/amahi type cifs (rw,mand)

What I have done in the past is use Thunar to change read/write permissions for the 'amahi' directory, and selected recursive when applying the permissions. However, if I do that under VL7.0, the permissions change straight back to read only for anyone other than root. I have no idea why the permissions won't change, and it means that I can only write to the share as root, which causes problems if I try and access the files from another machine. Problem didn't exist under VL6.0, but I've yet to find a way to fix it with VL7.0.

For general information, Amahi is based on Fedora 12, and the install I'm using is a full Fedora install with Amahi added during the install.

Hmm. I thought I might be able to get round the problem by adding the test share to /etc/fstab, with 'users' specified. Trouble is, it doesn't get that far. I get this error:

Code:

/sbin/mount.cifs: not installed setuid - "user" CIFS mounts not supported

I thought all the mount.xxx options should be setuid?

Paul.

[henryxcrudos]

Just to say I'm really excited about this. Once I'm finished with writing my MA thesis (in VL6 Light), I'll have enough time at hands to build this or that and contribute stupid questions . I hope there'll be a VL7 Light as well?

[prince]

Where is the 64-bit edition?

[nightflier]

/sbin/mount.cifs: not installed setuid - "user" CIFS mounts not supported

I noticed that after upgrading to samba 3.5.3, the vlsmbmnt utility stopped working. Looking at error messages I see this:

Code:

This mount.cifs program has been built with the ability to run as a setuid root program disabled.
mount.cifs has not been well audited for security holes. Therefore the Samba team does not recommend
installing it as a setuid root program.

Obviously this is a security concern and they chose to close that door.

I found this command to work:

Code:

mount -t cifs -o username=something -o users //ip_address/share /path/to/mount

Of course, this requires root access. Some of the options available to regular users are fusesmb or smbnetfs. I have not tried these, as I prefer KDE's built-in samba handling.

[toothandnail]

/sbin/mount.cifs: not installed setuid - "user" CIFS mounts not supported

I noticed that after upgrading to samba 3.5.3, the vlsmbmnt utility stopped working. Looking at error messages I see this:

Code:

This mount.cifs program has been built with the ability to run as a setuid root program disabled.
mount.cifs has not been well audited for security holes. Therefore the Samba team does not recommend
installing it as a setuid root program.

Obviously this is a security concern and they chose to close that door.

I found this command to work:

Code:

mount -t cifs -o username=something -o users //ip_address/share /path/to/mount

Of course, this requires root access. Some of the options available to regular users are fusesmb or smbnetfs. I have not tried these, as I prefer KDE's built-in samba handling.

Hmm. Well, I added the following to /etc/fstab in VL6.0:

Code:

//hda/movies /home/tooth/smb cifs noauto,users,rw,user=xxxx,password=yyyy 0 0

( username and password have been changed....). Under VL6.0, that works fine, though, as you say, root access is needed to perform the mount command.

In VL7.0, I used a minor variant of the same command in fstab:

Code:

//hda/movies /home/notme2/Music cifs noauto,users,rw,user=xxxx,password=yyyy 0 0

With root access, the command completes sucessfully, and the share is mounted. However, I still have no write access to the share as a normal user. As root, I can write to it, but, even with the 'users' specified (and even though an identical command works in VL6.0), under VL7.0, no joy....

I don't know what the problem is, but there certainly seems to be a problem.....

I also like the KDE handling of Samba shares. Trouble is, I hate KDE. I've also been forced to give up using fusesmb - I was having time out problems on large files, though that may be related to the horrible performance of my Icy Box NAS - I may try it again with the Amahi box, see if it works any better.

Paul.

[M0E-lnx]

probably a typo, but you do you know that '//hda/' doesn't look right.

[toothandnail]

probably a typo, but you do you know that '//hda/' doesn't look right.

No, sorry, I don't know that it doesn't look right. In what way?

This is a dump from smbtree, showing the resources involved:

Code:

\\HDA            ibmpeers.net
\\HDA\HL-5050-series Brother HL-5050 series
\\HDA\print$         
\\HDA\Books          Books
\\HDA\Pictures        Pictures
\\HDA\Movies          Movies
\\HDA\Music          Music
\\HDA\Docs            Docs
\\HDA\IPC$            IPC Service (ibmpeers.net)

And, as I said, the first sample, run under VL6.0 works correctly, and gives the normal user read/write access to the share. When mount is executed under VL7.0, it mouts correctly, but the normal user doesn't have write access, only read access. Root does have read/write access. Which is very strange....

Paul.