freenx installation
by Sandeep Gupta
Hi,
I am sharing the recipe for getting freenx server working. There is too
many irrelevant commands, all over the place, that confuse things.
1) su
2) yum install nx freenx-server
3) add "AllowUsers nx root <users>" to
/var/lib/nxserver/home/.ssh/sshd_config (not sure if this step is
necessary. Restart ssh ofcourse.)
4) turn on "ENABLE_SSH_AUTHETICATION=1" in /etc/nxserver/node.conf
5) export PATH=$PATH:$HOME/bin:/usr/libexec/nx
6) setenforce 0
6) nxsetup --install --setup-nomachine-key (this will setup nx user etc
but won't create client.id_dsa.key and so on. Also don't user --purge
--clean option in the command. It destroys home/.ssh/known_hosts files.)
7) nxserver --start (this will create client.id_dsa.key and other related
keys)
8) connect using nxclient from no machine. qtnx has problems apparently.
You don't need nxkeygen or copy client.id_dsa.key left, right, and, centre
as mentioned in top google search links for freenx configuration.
Hope this helps. Just switched from ubuntu and is fedora seems much more
stable, so thanks for that..
-Sandeep
10 years, 10 months
Comics strip reader
by Mickey
Fedora use to have a App. that could download the Comics Strips and
read, does anyone know the name and or still exist?
10 years, 10 months
F19: ipv6disable=1 as boot-param ignored
by Reindl Harald
"ipv6disable=1" in F19 is ignored
i get tired every few months research how IPv6 to disable
because it permanently changes, maybe it is F19/systemd
maybe it is the F20 3.10.0-1.fc20.x86_64 because it is
the only 3.10 build currently, however the kernel-line
is clear
on pure ipv4 networks there is no need for
"inet6 fe80::20c:29ff:fe30:82b9" period
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.196.18 netmask 255.255.255.0 broadcast 192.168.196.255
inet6 fe80::20c:29ff:fe30:82b9 prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:30:82:b9 txqueuelen 1000 (Ethernet)
RX packets 755 bytes 71786 (70.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 594 bytes 162204 (158.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
10 years, 10 months
Procedure for changing ethernet controllers
by Alex
Hi,
I have an fc17 system in which I've had to change the ethernet
controller from an e1000e card to what I believe is an rtl81391`2. I
recall changing the 70-persistent-net udev config file, but that
appears to no longer exist on my fc17 system.
What is the proper procedure for detecting, initializing, and
reconfiguring the system to use my new card?
I believe I'll also had to use dracut to recreate the initrd. I will
also need to detect for sure which driver the new ethernet controller
uses.
Thanks,
Alex
10 years, 10 months
nfs issues in fedora 19
by Amadeus W.M.
I normally have an nfs server running on one of my machines. Now nfs
itself and the portmapper start on fixed ports, but the rpc services
start on random ports so they need to be assigned fixed ports in
/etc/sysconfig/nfs like so:
LOCKD_TCPPORT=4000
STATD_PORT=4002
RQUOTAD_PORT=4003
LOCKD_UDPPORT=4000
MOUNTD_PORT=4001
then open up the corresponding ports in the firewall.
That was as of Fedora 14 which I had running before upgrading to Fedora
19. Now in F19 I did the same thing, but the rpc services seem to start
on ports other than the ones I specified:
60) root:~> rpcinfo -p
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 37527 status
100024 1 tcp 42571 status
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 2 tcp 2049 nfs_acl
100227 3 tcp 2049 nfs_acl
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100227 2 udp 2049 nfs_acl
100227 3 udp 2049 nfs_acl
100021 1 udp 4000 nlockmgr
100021 3 udp 4000 nlockmgr
100021 4 udp 4000 nlockmgr
100021 1 tcp 4000 nlockmgr
100021 3 tcp 4000 nlockmgr
100021 4 tcp 4000 nlockmgr
100011 1 udp 875 rquotad
100011 2 udp 875 rquotad
100011 1 tcp 875 rquotad
100011 2 tcp 875 rquotad
100005 1 udp 20048 mountd
100005 1 tcp 20048 mountd
100005 2 udp 20048 mountd
100005 2 tcp 20048 mountd
100005 3 udp 20048 mountd
100005 3 tcp 20048 mountd
So nlockmgr does get assigned port 4000 as specified by me. The other
ones seem to start on the ports defined in /etc/services. For instance,
62) root:~> grep mountd /etc/services
mountd 20048/tcp # NFS mount protocol
mountd 20048/udp # NFS mount protocol
Does anyone what's going on?
Are the rpc services now (i.e. in F19) being started on fixed ports?
Because if that's the case I can open up those ports in the firewall and
I'm all set.
If I wanted to change what ports they run on, what would I do? I mean,
even if IANA specifies 20048 for mountd, shouldn't I be able to run it on
a different port if I wanted to?
Sorry, I'm probably a few versions behind.
10 years, 10 months
F19: GRUB and Plymouth issues
by Marco Guazzone
Hello,
I've just installed F19 x86_64 from DVD.
The first issue is that the GRUB boot screen
* is only text-based (white text with a black background),
* and uses an inadequate text encoding since it shows question marks in
place of the umlauted "o" (i.e., the o vowel with two dots on top of it) in
the Schrodinger word
The second issue is related to plymouth.
The service plymouth-quit-wait is marked as failed:
plymouth-quit-wait.service - Wait for Plymouth Boot Screen to Quit
Loaded: loaded (/usr/lib/systemd/system/plymouth-quit-wait.service;
disabled)
Active: failed (Result: timeout) since Sun 2013-07-07 12:55:22 CEST; 5h
30min ago
Main PID: 396
CGroup: name=systemd:/system/plymouth-quit-wait.service
Any idea?
Thank you very much
Best,
-- Marco
10 years, 10 months
Fedora 18 -> 19 Upgrade
by Dave Cross
I've been running Fedora on both laptops and desktops since Fedora Core 1.
Before that I used Red Hat Linux. I've been used to my six-monthly upgrades
entailing a variable (but non-zero) amount of hassle.
Over the weekend I upgraded both my laptop and my desktop from Fedora 18 to
Fedora 19. For the first time ever the transition was completely seamless.
Both PCs are now running Fedora 19 with no problems whatsoever.
I've been quick to complain about problems in the past, so I wanted to take
the time to thank the Fedora team for making this upgrade so painless.
Cheers,
Dave...
--
Dave Cross :: dave(a)dave.org.uk
http://dave.org.uk/
@davorg
10 years, 10 months
rant of the day: installing fedora
by François Patte
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bonjour,
Once upon a time, install fedora was easy: you had to choose between an
automatic installation and a customised installation.
Now, I get a stupid screen which allows to choose an environment (gnome,
xfce,....) bravo! And *I can only choose (so there is no choice!!!) an
automatic partionnement of the disk.*
I want to re-use the previous partition of my disk and there is nothing
showing that this option is possible. I don't want to erase my /home
partition, I want to be free to make all mistakes I want... I don't want
that some stupid persons think for me.
What can I do? Use another distro?
Thank for suggestions
- --
François Patte
UFR de mathématiques et informatique
Laboratoire MAP5 --- UMR CNRS 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)1 8394 5849
http://www.math-info.univ-paris5.fr/~patte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAlHaahsACgkQdE6C2dhV2JVskgCfafTXGV/7/nuB5kBzW9xhr2OH
SoQAn1IDWLC5gGcmKS6iW4qFeF7zFhdC
=EL08
-----END PGP SIGNATURE-----
10 years, 10 months
Instability in F19 with KVM?
by Martin Jackson
Hello,
I seem to be having stability problems with F19 as of kernel 3.9.8-301.
The problems have persisted in 3.9.9 and in the 3.10 kernel I tried from
the bleeding edge repo.
The symptom is that the system, and and VMs it's running (I have KVM
running, with VLANs and traditional bridges) will simply hang - become
unresponsive. No response to network traffic, no response to
keyboard/mouse input, and the system has to be hard rebooted. There are
two network cards in the system, the build-in Intel and an add-on cheapo
r8169 that *might* be the problem.
abrt does not detect the problem and there is nothing in syslog.
Typically the system will run around 36 hours before hanging. There is
multicast, as I have routers (they are VMs running quagga and keepalived).
I'm not sure what to look at. I kinda suspect the change to r8169 that
went into 3.9.8, but it's hard to be sure. Anyone see something
similar? Is there something helpful I could post?
Thanks,
Marty
10 years, 10 months