I am planning on running a Virtual Private Network from my Fedora
firewall out to a UML virtual colo (running RH9) at another site.
That site will be the place I present services to the world;
httpd, ssh, sftp, smtp. This is to comply with the "no servers"
and dynamic ip restrictions on my Comcast connection to the net;
if my firewall always drives an outbound connection to the
colocation site, I am not worried about changes of ip address,
and I am not opening any inbound ports.
There are a number of options for the VPN - the most attractive
are cipe ( http://sites.inka.de/sites/bigred/devel/cipe.html )
and FreeSwan ( http://www.freeswan.org/ ), though I am told that
one can do all this through an ssh tunnel. I would rather have
simple and secure than super-duper; I have plenty of bandwidth,
and will send outbound http and smtp from the firewall, so the
main bandwidth user will be incoming spam/b/b/b/b mail.
Anyone have some experiences to share about setting up VPN? Is
there anything about either cipe or FreeSwan that is likely to
break with FC1 or FC2?
Keith Lofstrom keithl(a)ieee.org Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs
Because Anaconda doesn't support my usual partitioning scheme (root on Btrfs in LVM in LUKS in LVM in GPT, /boot on Btrfs, etc.), I created the entire layout manually and tried to install Fedora using dnf. The same layout works perfectly fine in ArchLinux.
I basically followed this howto, with adjustments for s/yum/dnf/ and for EFI/GPT: http://dustymabe.com/2014/05/29/manual-linux-installs-with-funky-storage-...
The initial filesystem installation (dnf install -y --releasever=23 --installroot=/mnt/sysimage filesystem) already got a few glitches of this form:
Non-fatal POSTIN scriptlet failure in rpm package filesystem
This^^^ happened to roughly half of the installed packages. I tried to proceed with the rest (i.e., to install @core @standard kernel grub2 grub2-efi sihm grub2-tools), but it failed with scriptlet errors that prevented a few key packages from getting installed at all:
error: %prein(selinux-policy-targeted-3.13.1-157.fc23.noarch) scriptlet failed, exit status 126
Error in PREIN scriptlet in rpm package selinux-policy-targeted
Packages with those errors are reported as failed after the verify step. What I tried next:
* setenforce 0
* upgrading the installation environment and/or the sysimage with dnf and rpm from rawhide
* --releasever=22 instead of 23
* ...and checking for a few other common points with this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1270663
* a plain sysimage directory with no predefined Btrfs subvolumes in it
* unmounting, remounting, checking that everything has seclabel on, no weirdness in dmesg, etc.
Well, nothing of the above helped; the error is still the same.
How can I diagnose this? Where can I dig out the exact reason why the scriptlets are failing?
Provided that Anaconda actually does some steps that I'm missing and can carry out the installation correctly, is there a way to *force* it to just accept whatever is mounted into /mnt/sysimage at the moment, without trying to make sense of it? I'm pretty sure dracut can handle my partition layout just fine, so the entire issue here is about getting the basic installation done somehow.
Theoretically I could create a simple-and-stupid layout that Anaconda can handle, proceed with the installation and reshuffle the partitions afterwards, but that's sooo cumbersome that I thought I'd first ask whether someone knows a workaround to the scriptlet problems.
my computer boot only in emergency mode ...
Looking the journalctl (command journalctl -xb), I found (in thejournalctl
) these lines in red color :
ATA2:00: link is slow to respond....
ATA200: SRST failed (erro 16)
That seem indicate that it is a problem to access the HDs..
I found a possible solution to the problem in this post:
There is wrote that :...the problem can depend by the physic set up of the
HD (as "master", "slave", "single drive", ...): this set up can be done by
changing the position of a jumper on the HD...
I know that, in the past time, the HDs had to be set physically in this
way.., but recently I never heart anymore that the modern HD need this
So actually I don't care anymore of the configuration of the HDs
(my HD is Toshiba 1 TB that I bought few mounts ago).
I would like to have a confirmation that what I read in the post is only an
obsolete information and, in any case, I would like to know also what I can
do to go around in my problem..
>From the command line: ls /dev/sd* I get:
give me this input :
/dev/sda /dev/sda1 /dev/sda2 /dev/sda5 /dev/sdb /dev/sdb1
I used to use netcat to check if a particular host is up or if I have
internet connection before I run a few scripts. I would use the -z
option in particular. But now I see that has been removed:
$ nc -z imap.gmail.com 993 && sync-my-email.sh
ncat: invalid option -- 'z'
Here is the excerpt from the old manual page:
-z Specifies that nc should just scan for listening daemons, without
sending any data to them. It is an error to use this option in
conjunction with the -l option.
Any ideas what happened to it? What can I use as replacement?
Thanks for any ideas.
Open source is the future. It sets us free.
The popular theme font size changer Firefox plugin,
longer supports Linux.
The default Firefox font size is too small for people with poor eyesight. As
far as I can tell, the only thing that official "Firefox themes" do is set a
background image for the UI. As Benny Hill would say, biiiiiiiiiiiiig …deal.
The top-ranked comment on that extension page suggests hacking "userChrome-
example.css" in ~/.mozilla/firefox.
$ find ~/.mozilla/firefox -name userChrome-example.css -print
There goes that idea.
Googling around the only other suggestion I found was to hack
layout.css.devPixelsPerPx setting in about:config. All that did, apparently,
was making the Firefox UI elements themselves bigger, but their font size –
the menu and the URL bar – remained exactly the same.
Anyone has other suggestions?
Most messages received from this fedora list are labelled junk by
Thunderbird. This is even though I whitelisted "From" =
"users-request(a)lists.fedoraproject.org". Actually, I have this problem
both in my Fedora-21 and my windows-7 systems. Any ideas? Surely
messages from this list are not junk!
This suggests installation using vnc over ipv6 is supported:
But when I use inst.vnc boot option, I get an text screen that says to
connect to an ipv4 address, an ipv6 address isn't listed. When I go to
a shell and use 'ip addr' there is a global ipv6 address, but no
formatting for tigervnc I've come up with will connect, it won't
vncviewer.desktop: CConn: unable connect to socket:
Invalid argument (22)
If I boot Fedora 23 Server on this same hardware, the 'ip addr'
address can be used successfully to ssh into the server, and also
point a browser to https://[ipv6]:9090 to reach the Cockpit interface
root 1744 0.0 0.9 251060 36468 pts/0 Sl+ 03:29 0:00 Xvnc
:1 -depth 16 -br IdleTimeout=0 -auth /dev/null -once
DisconnectClients=false desktop=Fedora rawhide installation on host
10.0.0.15 SecurityTypes=None rfbauth=0
I can't tell if -InTransports needs to explicitly specify ipv6 for it
to work. But at this point I'm stumped and can't tell if it's user
error or a bug. And netstat isn't on non-live media apparently so I
don't have access to that while xvnc is running to see if it's
listening over something other than just an ipv4 address.
For a long time now, the smplayer (from RPMFusion) volume control is
vertical, instead of horizontal, with a negligible height, so it's
essentially useless. This is still true with the latest version
smplayer-16.1.0-1.fc23, and even after deleting ~/.config/smplayer. Do all
Fedora users see this, and can it be fixed?
We're at the last stages of preparing the first major owncloud update in a
The current version of owncloud in Fedora is the fairly old stable 8.0
release (presently 8.0.10) which we want to bring back in line with the
current owncloud upstream release of 8.2.2.
Unfortunately it's not possible to migrate directly from 8.0.x to 8.2.x as
upstream only supports jumping in increments with no skipping of major
In order for a smooth transition to 8.2.x (and after that 9.0.x when it's
released) we'll be releasing 8.1.5 to F23 and F22 within the next couple of
We plan to leave this in updates-testing for a slightly longer period than
usual to allow for a wider test base for a major version jump. Please
remember your backups prior to the upgrade!
Once 8.1.5 is pushed to updates 8.2.2 will be pushed to updates-testing for
a similar extended period. It's imperative that the 8.1.5 update is applied
before the 8.2.2 update is pushed to updates.
If you want to assist in the testing and provide feedback or bug reports
please use the usual channels of bodhi and bugzilla - both easily
accessible from pkgdb: