Rails funciono en FreeBSD con Sqlite3 ,solamente problemas con node.js

$ rails -v
Rails 4.0.2
$ ruby -v
ruby 1.9.3p484 (2013-11-22 revision 43786) [amd64-freebsd10]
$

despues de crear uno nuevo project en rails al ejecutar el server sale el siguiente mensaje :

/usr/local/lib/ruby/gems/1.9/gems/railties-4.0.2/lib/rails/app_rails_loader.rb:37: warning: Insecure world writable dir /usr in PATH, mode 040777
/usr/local/lib/ruby/gems/1.9/gems/bundler-1.5.2/lib/bundler/runtime.rb:220: warning: Insecure world writable dir /usr in PATH, mode 040777

pero aparecio un error que decia java runtime , problems node.js luego haces como root ;

cd /usr/ports/www/node/ && make install clean

====> Compressing man pages (compress-man)
===>  Installing for node-0.10.25
===>   Registering installation for node-0.10.25
Installing node-0.10.25... done
===> SECURITY REPORT:
This port has installed the following files which ma act as network
servers and may therefore pose a remote security ris to the system.
/usr/local/bin/node

If there are vulnerabilities in these programs there may be a security
risk to the system. FreeBSD makes no guarantee about the security of
ports included in the Ports Collection. Please type 'make deinstall'
to deinstall the port if this is a concern.

For more information, and contact details about the security
status of this software, see the following webpage:
http://nodejs.org/
===>  Cleaning for node-0.10.25
root@freebsd:/usr/ports/www/node 

despues de esto deberia funcionar rails …

$ rails s
=> Booting WEBrick
=> Rails 4.0.2 application starting in development on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
[2014-02-21 22:22:30] INFO  WEBrick 1.3.1
[2014-02-21 22:22:30] INFO  ruby 1.9.3 (2013-11-22) [amd64-freebsd10]
[2014-02-21 22:22:30] INFO  WEBrick::HTTPServer#start: pid=45626 port=3000

ahora deberia corregir el ultimo error :

warning: Insecure world writable dir /usr in PATH, mode 040777

Cambiar el hostname de FreeBSD por BSD

se me dio por cambiar el hostname de FreeBSD por BSD , solamente con sudo hostname BSD y cuando reinicio el equipo al otro día , me tiraba un error , y había un conflicto por eso se reiniciaba automáticamente … a todo esto el conflicto de hostname permanecía , lo que me llevo a entrar en modo single user , consola cuando inicias el sistema y apretas la opción 2 boot single user y pasamos al modo consola

como no tenemos montado el file system y esta en modo read-only luego montamos de la siguiente manera

 
# sudo su
#mount -urw /

para volver a montar el sistema de archivos raíz en modo de lectura / escritura. También puede ser necesario para ejecutar

mount-a-t ufs 

para montar el sistema de archivos donde se define su editor favorito. Si su editor favorito es en un sistema de archivos de red, tendrá que o bien configurar la red manualmente antes de poder montar los sistemas de archivos de red o utiliza un editor que reside en un sistema de archivos local…

mas info esta en https://www.FreeBSD Handbook/

FILE SYSTEM MARKED CLEAN

Ufs de FreeBSD por lo general hace un trabajo excelente en la prevención de la corrupción del sistema de archivos. Pero incluso el mejor sistema pasa a desordenar de vez en cuando .

Una cosa que podes finalmente tropezar al otro lado son los llamados entradas destrozadas , que por lo general no son corregibles con fsck y dan lugar a errores de kernel en el acceso .

Estos son por lo general un signo de la corrupción del sistema de archivos grave , a menudo causada por fallas de hardware, como módulos de memoria defectuosos , un controlador de disco defectuoso o incluso un disco duro defectuoso.

Considera la posibilidad de revisar y reemplazar el hardware si encuentras entradas destrozadas en una ocasión frecuente y recurrente.
Usted puede realmente tener éxito en él se fijan siguiendo los pasos que se indican a continuación , sin embargo, es muy probable que esto suceda de nuevo si tiene hardware defectuoso. Así que al final va a terminar la curación de los efectos secundarios y no la razón real, que a su vez puede conducir a otros problemas, aún más críticos.

Por otro lado, si le sucede que tiene un sistema de archivos dañado como este muy, muy rara vez (como en ” alrededor de una vez en una década ” , pasó a mí mismo sólo tres veces en 10 años que he trabajado en unos 200 – 300 servidores en total) que pueden correr el riesgo de su fijación por medio del depurador del sistema de archivos.

Defino esto como una “corrupción menor” a la que se aplica lo siguiente por lo general :

Cuando ocurre el error
Un mensaje de error típico lanzado en usted en este caso puede tener este aspecto (una salida omitida):

/mnt/ada0p2: bad dir ino 16392 AT OFFSET 512: MANGLED ENTRY
panic: ufs_dirbad: bad dir

El mensaje proporciona información esencial sobre el sistema de archivos de que se trate (el punto de montaje real, no el propio nombre del dispositivo) amd el inodo del directorio o archivo.

Primeros pasos en la recuperación
Así que la siguiente mejor cosa que hacer en esta situación es reiniciar en modo monousuario.
A partir de ahí fsck se inspeccione el dispositivo.

# fsck -y /dev/ada0p2
** /dev/ada0p2
** Last Mounted on /mnt/ada0p2
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counters
** Phase 5 - Check Cyl groups
60040 files, 464657 used, 423186 free (43252 frags, 47493 blocks, 4.9% fragmentation)

***** FILE SYSTEM MARKED CLEAN *****

Ahora bien, como las entradas de mutilados generalmente no se fijan por fsck, el término “sistema de archivo marcado LIMPIO” no se debe confiar…

Es posible que el riesgo de que su sistema de copia de seguridad sin ningún trabajo adicional, sin embargo, si entra en pánico de nuevo con el mismo mensaje (el número de inodo), es probable que tenga irreparable mediante fsck la corrupción.

luego ejecutamos el siguiente comendo y reincida el sistema y listo ” todo funcionando de nuevo”

#reboot