Is there any way to make an etherpad site read-only?
I know I can disable new pads creation in the settings.json file ("editOnly" : true), but this doesn't seem to limit users from altering existing contents. I just want to decommission the site from active use but leave it online for lookups to legacy entries - but no modifications on these.
Platform: CentOS 6, proxy: HAProxy; MySQL back-end.
Thanks!
I built openssh 7.5p1 on a CentOS 7.3 system, after removing the originally installed package openssh which is (currently) 6.6.1p1.
All seemed good until I found out that openssh removed support for the tcp_wrappers/libwrap at version 6.7.
I guess this would mean that my old / trusted ACL via /etc/hosts.allow and /hosts/deny is now useless? (I have no way to test at this moment, unless using a spoofing tool).
If this holds true, what would be a replacement for this until now so convenient and easy way to control access for a public ssh server?
At some point, I deployed ipa-server on a CentOS 6 machine. Being asked to better move it into a VM, I used ipa-replica-prepare / ipa-replica-install . This resulted as wanted, and I got a working IPA-server prototype on the VM.
The original server was then disconnected to keep it as a fallback resource, but this eventually meant that actual production data was fed only to the replica server.
Now I have a full 100+ users operation based on the replica alone, not a healthy proposition. There is no disaster recovery here.
The initial server remains disconnected, but clients (e.g. ipa user-status) regard it as still being a master, and I am quite fearful of reconnecting it and have some unexpected outcome (such as my production databases being overwritten by the almost empty ones that are on the original server). Who has the authority do say which records are true?
Actually, to work around this, I want my current replica to become the master, forget about the old master, an eventually produce a new replica that would work as a backup of the current production environment. Creating a replica of the replica fails with "A replica can only be created on an IPA server installed with ipa-server-install (the first server)."
Instructions for promoting a replica into master are hard to find: The only relevant and somewhat old how-to for freeipa (Fedora) points to files that I don't find in my environment.
So my question boils to: How can I promote my replica to master? Can this be done live ? (Or with minimum downtime & risk ?)
Thanks
I'm doing the pilot for deploying Fedora 20, and despite having external firewall protection, regulations here say I need to have the individual firewalls on every host active.
Now comes that firewalld is the new king here, so I'm learning its ways.
Now I have a cleaned-up list of ports, after declaring a (non-public) default zone and some typical services, plus a specific service it seems to run fine.
However, when applying any change (--permanent mode), and reloading the firewall with:
# firewall-cmd --reload
it takes too much time, in the order of 10+ minutes to finish the command - which ends merrily with "success". The computer is basically unusable during all this time, as there is loss of connectivity.
But after that, it just runs as expected.
Logs are not helpful so far...
Starting/stopping the service works just fine, done within 1~2 seconds, what one could expect.
Is there anything I can be missing/omitting ? How could this annoying behavior be troubleshooted ?
Thanks
My 70+ hosts network (mixed CentOS, Fedora) uses NIS/YP. If networking is working OK, then no major issues occur, normally a trouble-less operation.
If connectivity is lost, either by a simple loose cable, or a major problem outside my reach, login operations depending on the NIS domain server hang - as expected.
But what I don't expect is that even login locally as root - it may produce a login prompt, but never get to the password prompt, hanging for ever. I get that way totally excluded from operating the machine even for simple troubleshooting. Only restoring connectivity brings back root and regular users.
My /etc/nsswitch file has the following order:
passwd: files nis
shadow: files nis
group: files nis
hosts: files nis dns
so I would expect that the local /etc/passwd and shadow files (where the correct credentials for the local root are OK) should be interpreted.
But it seems to keep looking outside for root's credentials - which are not to be found.
What am I missing here ?
Thanks!
As proof of concept before migrating a production machine, I created a small VM & put a minimal Linux install on it. This machine works well, as accessed from the virt-manager. Its 80 GB virtual disk is file-based.
Now I want to migrate it to the target server. WHile the VM is up & running, the Migrate option in virt-manager on the source host is enabled so I click on it. The following error pops up:
Unable to migrate guest:
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/migrate.py", line 449, in _async_migrate
vm.migrate(dstconn, migrate_uri, rate, live, secure)
File "/usr/share/virt-manager/virtManager/domain.py", line 1445, in migrate
self.vm.migrate(destconn.vmm, flags, newname, interface, rate)
File "/usr/lib64/python2.4/site-packages/libvirt.py", line 518, in migrate
if ret is None:raise libvirtError('virDomainMigrate() failed', dom=self)
libvirtError: cannot open file '/export/kvm/v_holmestest/vholmes': No such file or directory
I am positive that the "vholmes" file is there, and has (all its path) read/execute permissions for world:
[root@centos5server /export/kvm/v_holmestest]$ l
total 8200020
4 drwxr-xr-x 2 root root 4096 Sep 30 17:51 .
4 drwxr-xr-x 3 root root 4096 Sep 30 17:49 ..
8200012 -rwxr-xr-x 1 root root 8388608000 Sep 30 17:52 vholmes
What can be going on here ?
Thanks
faulters:
Despite much troubleshooting in my NIS/YP setup, rebooting systems, restarting & debugging ypbind, putting nscd to run, a group of newly purchased systems regularly spam my email with:
do_ypcall: clnt_call: RPC: Timed out
do_ypcall: clnt_call: RPC: Timed out
do_ypcall: clnt_call: RPC: Timed out
However, the users are (apparently) not affected by this - they can access network resources. Otherwise I would have a line of users in front of my door complaining... :). This has been mostly an annoyance by now, but how can I get rid of it ?
Machines of other hardware specs (older, quad cores, duo cores) having exactly the same managed configuration just do well - almost never showing this kind of behavior.
I am on Fedora 17/64 on (pretty recent) Dell Optiplex 9010 machines with good RAM, disk etc. The NIS/YP server is on CentOS, and other critical network resources that rely on it do just fine.
Any hints ? Thanks.
There are other similar questions related to mine (e.g. VNC viewer issue - showing black screen ) - my case seems a little bit different: I start vncserver on my CentOS 5.8 host, which acts as a VMware Workstation 8.0 host, and use TigerVNC to open a desktop window from my Fedora box.
I get the twm desktop as expected (have several similar setups), and start vmware (relevant here, I think).
All seems to work like a charm, i.e. I operate on the VMware WS GUI, able to start/stop, or enter/exit each VM console etc.
But if I leave it inactive for a while, the VNC window goes suddenly black... and the whole VMware environment that was running is killed... all the VM instances are gone ! (vmrun list count is 0 !). A most undesirable situation - as I must then hurry to restart them via ssh.
Closing the TigerVNC client doesn't help - when opening it again, the black screen continues showing. Only killing vncserver (vncserver -kill :1) fixes this... until the next occurrence...
The vncserver configs are the default ones.. and as said other machines that I have are stable (can leave the VNC client desktop open for days at once).
Any hint ?
Thanks in advance!
My problem: cfengine3 policies are manually created/updated on the server (policy hub), and the clients regularly (every ~ 5 minutes) pull those from the server:/var/cfengine/masterfiles to their respective someclient:/var/cfengine/inputs (as they should).
But this behaves inconsistently some times. An updated file in the server may not be reflected in the clients until a good while later. It can be > 30 minutes or more until it suddenly "sees" the update. This happens especially if what I have created/updated is in a subdirectory under ./masterfiles.
I have checked with tcpdump that each client is in fact communicating with the master server via the cfengine port (5308) every 5 minutes.
I cannot see the reason why the policy files are not updated then.
Any one has experienced the same or has a suggestion ? Thanks.
(Just upgraded to cfengine 3.3.1, mixed CentOS/Fedora isolated environment - the rest of the network runs happily on cf2).
I have MediaWiki 1.16.2 on a the following LAMP platform, which performs quite good for other apps on a 16 GB RAM dual processor machine: CentOS 5.7 (64-bit) Apache 2.2.3 MySQL 5.0.77 PHP 5.1.6
It seems to depend somewhat on the used browser, but very frequently saving edited pages is too slow - not rare to wait 10 or 20 seconds for it even more for a very simple change.
Rendering the pages works pretty fast, but it's the saving after editing which is killing the user experience. I have detected some improvement when editing from a client running Opera than on Firefox (on a Fedora Linux platform).
Any hints about where can I tune up the server to make it better ?
Benchmarks of Apache run on the machine are impressive, BTW.
I want/need to start my VM instances from the command line, or as part of the host boot sequence. Also, as part of a script manually launched on the host at will.
The obvious command for such case would be vmrun start with the nogui option, but this fails consistently in my 3 hosts running VMware Workstation 7.1.4 under CentOS 5.6 (64 bit):
[root@japeto ~/vmware/juno]$ vmrun start juno.vmx nogui
Error: The virtual machine needs to be powered on
If I open the vmware GUI and use the point+click method everything works fine. In fact, once a VM instance has been started this way, then the vmrun start ... nogui works at it should for other VM instances residing in the same host.
But this doesn't help for a headless operation where I can only access the host via ssh.
Any hints ? Thanks.